> 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 > <mailto: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 <https://pragmaticwebsecurity.com/> >>
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
