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