Nonsense, mayhem, browser security, CSRF, and CORS - Part 2

<h1>Introduction</h1> In the <a href="https://kernelpanic.cryptid.fr/en/blog/nonsense-mayhem-samesite-cors-and-csrf">last blog post</a>, we detailed the various conditions necessary to perform a successful CSRF attack, considering today's browser security. I mentioned that it was mostly written out of frustration, as I received numerous erroneous pentest reports regarding CSRF... Well, it seems that CORS (Cross-Origin Resource Sharing) mechanisms are also a widely misunderstood by some pentesters. Let us dive in the wonderful world of CORS misconfigurations. <h2>SOP (Same Origin Policy)</h2> Once again, let's go back to the basics. CORS cannot be explained without SOP (Same Origin Policy). The Same Origin Policy is a security mechanism that is implemented in all web browsers, and serves as a corner stone of web security. Basically, the SOP says that scripts that were loaded from a given page can only interact with another page if they share the same origin. Let us consider that the script loaded by your browser is located at the following URL: <blockquote> https://mysite.com:8443/flop.js </blockquote> The origin of the document is defined by the combination of three parameters. If one of them differs from the script's origin, the script's interaction will be denied. <ul> <li>Protocol - https A XHR call to http://mysite.com:8443/flop.js would be forbidden as protocols do not match;</li> <li>Host - mysite.com: A XHR call to any other host - test.mysite.com, cryptid.fr or mysite.net would be forbidden as host names do not match;</li> <li>Port - 8443: A XHR call to https://mysite.com would default to port 443, which does not match 8443, thus would be forbidden</li> </ul> CORS was designed to bypass the SOP policy, in order to allow the browser to interact from a given origin to another. This is a more and more common need, because of the rise of stateless APIs, which are often not hosted on the same domain than frontend JS web applications. However, these misconfigurations may have quite important consequences. <h2>Wildcard Origin misconfiguration</h2> The following sections assume that you already know how CORS works, and the functions of the main headers. We will not go over the details of preflighted requests, feel free to consult <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS">Mozilla's documentation</a> regarding this matter! Let us consider the following CORS Policy: <blockquote> Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true </blockquote> Most of the reports I received were stating that it was possible to leak the user's data, and perform actions with the logged-in user privilege. This is simply false. When the wildcard character is used in conjunction with Access-Control-Allow-Credentials: true, the browser will not send any cookies automatically, as the configuration is considered as insecure. This has been designed to prevent lazy people from just whitelisting any origin easily (good call), which is a major vulnerability as you all know. In this situation, the consequences are not as critical as only unauthenticated requests are possible but a few scenarios can be imagined, such as indirect bruteforce attacks: let us assume that an attacker has found an XSS vulnerability in a high profile website with a lot of traffic. The attacker can craft a specific playload in order to attempt to bruteforce a login form through the visitors browsers, not even needing to interact with the target system! I found many blog posts that were misleading about this wilcard configuration, but the browser will not allow you to set Access-Control-Allow-Credential to true in this case. Don't belive me? PoC it! <h2>Reflected Origin misconfiguration</h2> This scenario is more problematic as it completely breaks the SOP policy. This happens when the Origin provided by the client is reflected in the server's response, and not checked against a known whitelist of authorized origins (this also works with the null origin): <blockquote> Access-Control-Allow-Origin: attackers-website.com Access-Control-Allow-Credentials: true </blockquote> In this case, the attacker can host a malicious web page on a domain he controls (or use a third party website where he has exploited an XSS vulnerability). The risk is that the cookie should be forwarded automatically as the configuration allows it, which results in data leaks as the attacker's website can query the APIs with the user's privileges, or perform CSRF-like attacks, by performing specific modifications that would only be allowed to the targeted user. However the success of this attack is conditioned by other factors, remember our previous article? <ul> <li>The session token should be stored as a cookie, or standard authentication headers (Basic, Digest, NTLM...),</li> <li>If the session token is a cookie, the SameSite parameter should be set to None, or it will not be sent cross domain, with the exception of cookies defaulting to Lax, which shall be allowed to be sent cross domain if they are less than two minutes old.</li> </ul> If these conditions are not met, the impacts are much less important, as they will be similar to the previous case, the "Wildcard Origin misconfiguration". <h2>Closing words (PoC, or it didn't happen - again)</h2> Once again, if you are unsure if a given exploit works, try to write a proof of concept for it. As stated in the previous article, BurpSuite includes a tool to generate CSRF and CORS attack PoCs, just right-click on the targeted request, choose engagement tools, CSRF PoC, then Cross-Domain XHR (modern browsers only) in the Options menu. Stayed tuned for more security-related articles! Need offensive security services, or application security support? <a href="https://cryptid.fr">CryptID has got you covered</a>