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.
