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:
...").

>
> --
> --
> 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

-- 
-- 
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_NCUFQSCSs1Wi5FwE77CduN49GiiykBpEm2bFGKt46aq6w%3DQ%40mail.gmail.com.

Reply via email to