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
