DNR cannot handle POST payloads (use case: anti-XSS/CSRF protections)

[hackademix]

An important component of NoScript, preventing "untrusted" sites from abusing "trusted" ones to execute scripts through reflective XSS, is its anti-XSS filter called "InjectionChecker".

This InjectionChecker doesn't scan just the URL, but also form data extracted from POST payloads, looking for suspect HTML/JavaScript patterns which may be reflected by the requested page in a cross-site scripting attack.

Furthermore, pattern matching happens on several transformations of URL / POST payload fragments (e.g. base64 decoding, entity unescaping, decodeURIComponent() and others which may be applied by the victim website before reflection).

This complex and potentially CPU intensive (depending on the actual payload) task is currently performed in a WebWorker called from an asynchronous blocking webRequest.onBeforeRequest listener.

The declarativeNetRequest API is currently useless for this use case, not supporting POST content processing nor transformation before pattern matching.

For these reasons, NoScript's XSS filter (and any use case requiring POST payload processing, like the SitePolicy or ABE) at this moment have a future only on Firefox, which is committed to keep (asynchronous) blocking webRequest.

Are there any suggested alternatives, or ways to modify DNR in a suitable way, in order to support this use case on Chromium/MV3?

[tophf]

https://crbug.com/1241397 describes an implementation idea for MV3 and claims it "would cover 100% of all theoretically possible use cases for webRequestBlocking". In short, declarativeNetRequest should allow the page in extensionPath to be intercepted by the extension's SW fetch event handler, and DNR should add the original request info to the FetchEvent.request object, so that the service worker can redirect the URL from "to something external based on some complex asynchronously evaluated logic" - apparently by using event.respondWith(asyncProcess(event.request)) which would construct a new Response or use Response.redirect.

[Rob--W]

@tophf The crbug that you're linking to suggests to replace the response with a redirect. That wouldn't work for the use case described here, as the use case here is asking for a way to block requests until an extension has processed a request body, and allow a request to get through in unmodified form if permitted by the extension.

I'll also post on the crbug to reference a Firefox bug with some background information.

[tophf]

AFAICT it should work because the idea there seems equivalent to Firefox's asynchronous webRequestBlocking i.e. the original request is redirected to extensionPath, which in turn is handled by the extension's SW so the request is effectively blocked until it's resolved because this is how SW fetch event works by design.