Thanks Philippe!

That's very helpful.

I wonder if there is a way to somehow capture some of this explanation in
the document to make sure implementers are clear on this issue?
Otherwise, I am fine with your explanation.

Regards,
 Rifaat



On Tue, Dec 17, 2024 at 11:22 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:

> On 17 Dec 2024, at 14:58, Rifaat Shekh-Yusef <rifaat.s.i...@gmail.com>
> wrote:
>
> Thanks Philippe!
>
> Just to make sure I understand, with regards to the following statement:
>
>> When the attacker manages to send such a malicious request without a
>> preflight, the server would process it,...
>
>
> The server will process it because of a bug on the server? or will it
> always process such requests?
>
>
> It’s a bit weird. Since a request like this (CORS Safelisted) has always
> been possible using HTML elements (e.g., a form), the server should not be
> surprised to see it and processing it should not cause any harm. That’s why
> the CORS spec simply prescribes not adding response headers, as that would
> get the same type of browser behavior.
>
> Today, with CORS being widely used and implemented, it would make perfect
> sense to reject a request with an origin header which is known to be
> unacceptable. Some frameworks do this, but others do not. For example, the
> cors middleware for NodeJS does process a request and adds no CORS response
> headers.
>
> So it’s not a bug perse (and it is prescribed in the somewhat older CORS
> spec), but it also makes little sense in the modern web (rejecting would
> make more sense).
>
> Philippe
>
>
>
> Regards,
>  Rifaat
>
> On Tue, Dec 17, 2024 at 2:07 AM Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> wrote:
>
>> Hi Rifaat,
>>
>> Thank you for the detailed review comments. It took me a while to find
>> some space in my schedule, but I’ve gone through them and addressed most of
>> them in the document. There is one comment that I wanted to follow up here …
>>
>>
>> Section 6.1.3.3.2
>> I might be missing something here:
>> “For such requests, named "CORS-safelisted Requests", the browser will
>> simply send the request and prevent access to the response if the server
>> did not send the proper CORS headers.”
>> The above statement indicates that for these requests, the browser
>> ignores the response if it did not get a proper CORS from the server.
>>
>> “The consequence of this behavior is that certain endpoints of the
>> resource server could become vulnerable to CSRF, even with CORS enabled as
>> a defense. For example, if the resource server is an API that exposes an
>> endpoint to a body-less POST request, there will be no preflight request
>> and no CSRF defense.”
>> This implies that just because there is no preflight request, that the
>> server is vulnerable; would not the browser just ignore the response as
>> indicated in the previous statement?
>>
>>
>>
>> Your interpretation is correct, and I’ll try to clarify.
>>
>> In a CSRF attack, the attacker triggers a state-changing operation on the
>> server in the name of the user. When the attacker manages to send such a
>> malicious request without a preflight, the server would process it, and
>> then send a response without proper CORS headers in the response. The
>> browser would ignore this response, as you stated, but at that point, the
>> damage (i.e., a state changing operation) has already been done.
>>
>> This type of attack is possible with a body-less POST, or on an API
>> endpoint that accepts JSON with a text/plain Content-Type header (e.g.,
>> https://portswigger.net/daily-swig/vulnerability-in-dating-site-okcupid-could-be-used-to-trick-users-into-liking-or-messaging-other-profiles
>> ).
>>
>> By forcing every request to be non-safelisted, the browser will always
>> send a preflight first, which the server will not agree to. As a result,
>> the browser does not send the actual malicious request.
>>
>> The approach in the spec to make every request non-safelisted is
>> requiring a custom request header. This always works, and it does not
>> affect same-origin requests in any way, so it is straightforward to
>> implement. Additionally, it does not require a developer to carefully
>> scrutinize each API endpoint to determine if it may be reachable with a
>> safelisted request (which is very nuanced and painstakingly hard to get
>> right).
>>
>>
>> I hope this helps. If you feel that there’s an update needed in the spec,
>> feel free to let me know.
>>
>> Kind regards
>>
>> Philippe
>>
>> —
>> *Pragmatic Web Security*
>> *Security for developers*
>> https://pragmaticwebsecurity.com
>>
>>
>
_______________________________________________
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org

Reply via email to