Repository navigation
Conversation
The DevTools server (`server_api.dart` now has a `_validateRequest` function that performs a variety of checks to prevent cross-site request forgery and DNS rebinding: * Prevents external websites from triggering local operations through cross-origin `GET` requests. Requests to the DevTools server are now required to be `POST` or `OPTIONS`. Web browsers will allow cross-origin `GET` requests through `img` tags or the `fetch()` API. Malicious websites could call `api/notifyForVmServiceConnection` and connect to a remote VM service, which could lead to CSRF attacks where DTD authentication tokens are read through `/api/getDtdUri`. * Prevents DNS rebinding attacks by validating that the `host` header is within an allowlist of loopback addresses (`localhost`, `127.0.0.1`, etc) and is not malformed to mitigate DNS rebinding. * Rejects requests where the `Sec-Fetch-Site` header is set to `cross-site` unless the `Origin` header is a valid loopback address. Otherwise, only `same-origin`, `same-site`, or `none` are allowed.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request enhances the security of the DevTools server APIs by requiring POST (or OPTIONS CORS preflight) requests and validating Host, Origin, and Sec-Fetch-Site headers in ServerApi.handle to mitigate CSRF, DNS rebinding, and cross-origin attacks. It introduces a custom X-DevTools-Request header to force CORS preflight requests in browsers, updates client-side requests to include this header, and adds comprehensive test coverage for the new validation logic. There are no review comments to assess, and I have no additional feedback to provide.
srawlins
left a comment
srawlins
left a comment
There was a problem hiding this comment.
LGTM, nice new tests. I hate CORS stuff, but good to get right.
bkonyi
left a comment
bkonyi
left a comment
There was a problem hiding this comment.
Thanks @johnpryan! Overall direction makes sense, especially requiring POST so plain-HTTP non-loopback binds aren't exposed to no-CORS GET requests where browsers omit Sec-Fetch-Site.
Two main issues we need to address before landing:
ServerApi.handleneeds parameters for disabling origin checks and passing additional allowed origins/hosts so we don't break--disable-service-origin-checkand--host <non-loopback>inpackage:dds/package:dart_runtime_service._validateRequestdoesn't actually check forX-DevTools-RequestonPOSTrequests, so cross-origin simplePOSTrequests (<form>/fetchwithmode: 'no-cors') can still bypass CORS preflight.
(Note: This review was posted by an AI agent on behalf of @bkonyi.)
Enforce `X-DevTools-Request` on `POST` requests, require `http`/`https` origins without a path or query, disallow `Sec-Fetch-Site: same-site` when `Origin` is absent, and return an `Allow` header on `405` responses. Also add `disableOriginCheck` and `allowedOrigins` parameters to `ServerApi.handle` for SDK flag parity and update the server tests.
The DevTools server (
server_api.dart) now has a_validateRequestfunction that performs a variety of checks to prevent cross-site request forgery, DNS rebinding, and cross-origin attacks:GETrequests. Requests to the DevTools server are now required to bePOSTorOPTIONS. Web browsers will allow cross-originGETrequests throughimgtags or thefetch()API. Malicious websites could callapi/notifyForVmServiceConnectionand connect to a remote VM service, which could lead to CSRF attacks where DTD authentication tokens are read through/api/getDtdUri.hostheader is within an allowlist of loopback addresses (localhost,127.0.0.1, etc) and is not malformed to mitigate DNS rebinding.Sec-Fetch-Siteheader is set tocross-siteunless theOriginheader is a valid loopback address. Otherwise, onlysame-origin,same-site, ornoneare allowed.This makes progress towards: