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
