chrome.webRequest response body reading/editing proposal

[Rob Wu]

Hi all,

I have written a proposal for what I think is a sane way to implement read/write of response bodies in the webRequest API.

The API change is not very big (just a new return type and an event property), but I want to get a review on the intended implementation details before going to code.

https://docs.google.com/document/d/1iE6M-YSmPtMOsec7pR-ILWveQie8JQQXTm15JKEcUT8/edit

I haven't added a link to the proposal at the Chrome API tracking master document (which is what the "API Proposals (New APIs Start Here)" document recommends) because that doc was read-only to me.

Suggestions are welcome!

Kind regards,

 Rob

[Benjamin Kalman]

Modifying the body makes me nervous. We don't have a way of spoofing responses at such a low level in extensions. Reading the body seems less crazy but webRequest is still a pretty big hammer to be applying here.

I'd really value some input from security people here.

[Matt Perry]

Is modifying the body all that different from redirecting a request to a different URL, in terms of security risk?

[Jeffrey Yasskin]

I believe it makes it easier/cheaper to keep up with the correct
appearance of the victim website while still stealing the target data,
but I don't think it extends what an attacker with lots of resources
can do.

[Benjamin Kalman]

Yeah it's kind of like content script++. It's more powerful than simple redirection because that's to a different origin.

[Mustafa Emre Acer]

> Yeah it's kind of like content script++. It's more powerful than simple redirection because that's to a different origin.

You can still redirect cross origin scripts and they'll run within the same origin though, so simple redirection is still bad.

One thing that'll change by allowing reading/modifying response body is that the extension will be able to access the page's JavaScript world which it can't do with content scripts now.

[Scott Fujan]

On Wed, Mar 19, 2014 at 6:58 PM, Mustafa Emre Acer <mea...@chromium.org> wrote:

> Yeah it's kind of like content script++. It's more powerful than simple redirection because that's to a different origin.

You can still redirect cross origin scripts and they'll run within the same origin though, so simple redirection is still bad.

One thing that'll change by allowing reading/modifying response body is that the extension will be able to access the page's JavaScript world which it can't do with content scripts now.

 

Content scripts can definitely access the page's javascript world

 

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Rob Wu]

The current proposal focuses on getting read-access to the response body.

Once the response body-reading API is ready, AND the Streams API (https://dvcs.w3.org/hg/streams-api/raw-file/tip/Overview.htm) is implemented, developers could edit the response body as follows: https://gist.github.com/Rob--W/9654450. As you can see from the example, the URL is not preserved, and the origin is different (some blob:-URL with an unique origin, practically useless for phishing).
We probably don't want to keep the URL for a modified response body. Or at the very least, add a scary permission (on the other hand, malicious extension developers can already do worse things with content scripts, without requiring direct access to the response body, so adding more permissions is not going to help much).

@meacer

Extensions can easily access the JavaScript world of web pages, see e.g. http://stackoverflow.com/a/9517879/938089. Currently, if a user installs a malicious extension, then they are screwed. This is even more true for Firefox and IE.

[Benjamin Kalman]

Good point re redirecting remote scripts, and yes, you can still execute JS in the page's context using a content script. However, we'd lose some control here. With <script> injection we can at least [make an attempt to] track those elements. We can track remote script redirection to some degree. With direct response body modification we have no idea what's going on.

And yes, malicious extensions can always be malicious with the sort of privileges they need to run webRequest. Modifying response bodies is more subtle though.

I think that read-mode is ok from this perspective though?

[Mustafa Emre Acer]

+Joel

Yes, I think read mode sounds OK. Were any specific reasons to not add the capability to read response body in the initial webRequest implementation? Also, is the only way to read response bodies today to use content scripts and/or XHR?

[Matt Perry]

The reason we didn't add read mode for the response body was technical complexity. The network stack doesn't keep a copy of the response body, so we'd need to either copy it to the renderer (expensive), or add complex lifetime management so it stays around until we know extensions don't want to read it anymore (hard).

[Rob Wu]

I think that lots of the existing code from the streamsPrivate API can be re-used for implementing this feature, in particular the response body interception at the network layer, the conversion to a blob: URL and the lifetime management of the stream.

The existing implementation is not 100% correct (http://crbug.com/348464), but any fix will likely apply to this proposed API and the existing streamsPrivate API.

cc zork and raymes because this proposal and discussion is also relevant to them, especially in the light of http://crbug.com/350755, a feature which duplicates functionality from the webRequest API.

[Jet Rico Bañas]

I was linked here from crbug.com/487422

I don't know how the current system works, but I have these idea that might be of help:

The idea is an "onResponseBodyReceived" listener. Give the response bodies to those listening to event, no need for lifetime management, no need to keep the data for those who will ask it later on. The data can be discarded as soon as it is sent to listener functions.

Hope this can lighten the obstacles in implementing the read mechanism.

[jacks]

Hi all,

We are developing an extension and reading body of http response is very critical for the success of our extension.

Do you guys plan to make this api available in near future?

I see that it is possible to read the body of the http response in Firefox, for example:

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/NsITraceableChannel 

https://developer.mozilla.org/en-US/docs/Setting_HTTP_request_headers 

I would really appreciate if this api becomes available in near future.

Thanks

[Dominic Battre]

Hi.

I don't think that anybody is working on this at the moment.

Best regards,

Dominic

[Dominic Battre]

+Matt Menke for taking a look from a network stack perspective (I think the current CL would not work with the network service)

+rdevlin...@chromium.org who leads the extensions team

I haven't worked on the Web Request API for a long time.

Best regards,

Dominic

On Wed, Apr 3, 2019 at 2:36 AM <artem....@blazemeter.com> wrote:

Hi all,

FYI https://github.com/chromium/chromium/pull/18/ 
It's a PR that allow extensions to read response body

пятница, 14 марта 2014 г., 21:10:49 UTC+3 пользователь Rob Wu написал:

-- 

Google Germany GmbH - Erika-Mann-Str. 33 - 80636 München - Germany

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado

[Matt Menke]

The CL certainly won't work with the network process enabled, since ChromeNetworkDelegate isn't used in that case.  If we want to implement the API, we should probably implement forwarding of the response body in the renderer (Or possibly the browser process), not the network service.  I think there's already some mechanism to force network requests to roundtrip through the browser process instead of going to the network process (For offline pages?  devtools?  Not sure), so I'd either look for that logic and copy it, or go with a renderer-based approach.

I also think we should have a clearly understood behavior in the case of ServiceWorker (Are we above them?  Below them?  Both?) and with respect to downloads (Can we inject arbitrary stuff in the body of a download)?  With tests for both.

[Matt Menke]

[-mpcomplete], to avoid further email bounces.