Thinking out loud: One idea could be to have a separate sandboxed compiler process in which we compile incoming JS code. That could reject the source if it doesn't compile; or compile it to a script that just throws with no additional info about the actual source.
That process could implement streaming compilation; so we don't block streaming until later, we don't double parse, we still have a sandbox (not in the network process). There might even be benefits for caching as a compromised renderer cannot look at the compilation artefacts until it receives them. If we fully compile and create a code cache from the compilation result we don't need a new API on the V8 side, but do additional serialization/deserialization work. That should be faster than reparsing though. The upper limit of the cost would essentially be the cost of serializing / deserializing a code cache for each script. On Fri, Aug 13, 2021 at 12:26 AM 'Łukasz Anforowicz' via v8-dev < [email protected]> wrote: > On Thu, Aug 12, 2021 at 3:18 PM Łukasz Anforowicz <[email protected]> > wrote: > >> >> >> On Thu, Aug 12, 2021 at 3:11 PM Jakob Kummerow <[email protected]> >> wrote: >> >>> ORB-with-html/json/xml-sniffing shows that some security benefits of ORB >>>> may be realized without full-fidelity JS sniffing/parsing. >>>> >>>> >>> You may call it a security benefit to block "obvious" parser breakers >>> like )]}', but in general, any "when in doubt, don't block it" strategy >>> won't be much of an obstacle to intentional attacks. For instance, once Mr. >>> Bad Guy has learned that the sniffer only looks at the first 1024 >>> characters, they can send a response whose first 1024 characters lead to a >>> "well, it *might* be valid JS" judgement (such as a JS comment, or long >>> string, or whatever). OTOH any "when in doubt, block it" strategy runs the >>> risk of breaking existing websites in those doubtful cases. >>> >> >> In CORB threat model the attacker does *not* control the responses - CORB >> tries to prevent https://attacker.com (with either Spectre or a >> compromised renderer) from being able to read no-cors responses from >> https://victim.com. >> >>> >>> >>>> (Although the JSON object syntax is exactly Javascript's >>>> object-initializer syntax, a Javascript object-initializer expression is >>>> not valid as a standalone Javascript statement.) >>> >>> >>> There is (at least) one subtlety here: JS is more permissive than the >>> official JSON spec. The latter requires quotes around property names, the >>> former doesn't. I.e. {"foo": is indeed never valid JS, but {foo: is >>> (the brace opens a code block, and foo is a label). Also, the colon is >>> essential for rejecting the former snippet, because {"foo"; is valid JS >>> (code block plus ignored string á la "use strict";), so this is a >>> concrete example where the 1024-char prefix issue is relevant. >>> >>> >>>> When the sniffer sees: >>>> [ 123, 456, “long string taking X bytes”, >>>> then it should block the response when the Content-Type is a JSON MIME >>>> type >>> >>> >>> I don't follow. When the Content-Type is JSON, and the actual contents >>> are valid JSON, why should that be blocked? >>> >> >> Correct. There is no way to read cross-origin JSON via a "no-cors" >> fetch. The only way to read cross-origin JSON is via CORS-mediated fetch >> (where the victim has to opt-in by responding with >> "Access-Control-Allow-Origin: ..."). >> > > Maybe another way to look at it is: > > - Only Javascript (and images/audio/video/stylesheets) can be sent in > no-cors mode (e.g. without CORS). Non-Javascript (and > non-image/video/etc), no-cors, cross-origin responses can be blocked. > - If the response sniffs as JSON (Content-Type=JSON and > First1024bytes=JSON) then it is *not* Javascript. Therefore we can block > the response (and prevent disclosing https://victim.com/secret.json to > a no-cors fetch from https://attacker.com). > > > >> >>> -- >>> -- >>> v8-dev mailing list >>> [email protected] >>> http://groups.google.com/group/v8-dev >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "v8-dev" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/v8-dev/NGGCw9OjatI/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/v8-dev/CAKSzg3TNvd1jd3yH8xyD767ZhbCqhEZJMFmm7nQ%2BtcQcXfjt_g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/v8-dev/CAKSzg3TNvd1jd3yH8xyD767ZhbCqhEZJMFmm7nQ%2BtcQcXfjt_g%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> Thanks, >> >> Lukasz >> > > > -- > Thanks, > > Lukasz > > -- > -- > v8-dev mailing list > [email protected] > http://groups.google.com/group/v8-dev > --- > You received this message because you are subscribed to the Google Groups > "v8-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/v8-dev/CAA_NCUHWD5G2G9aHe%3DnM6k-hSZY2ufqx7GwEhmKYSfPN9b%3D9WA%40mail.gmail.com > <https://groups.google.com/d/msgid/v8-dev/CAA_NCUHWD5G2G9aHe%3DnM6k-hSZY2ufqx7GwEhmKYSfPN9b%3D9WA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- -- v8-dev mailing list [email protected] http://groups.google.com/group/v8-dev --- You received this message because you are subscribed to the Google Groups "v8-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/CANS-YRqhC5Z_XeNuN0-4VNMgOV-bJ6LHd1e%3Daw%2Bn82pjxWJx1Q%40mail.gmail.com.
