This is a short post about a vulnerability I had found in Microsoft Edge.
Edge failed to recognize HTTP Authentication information (i.e. Authorization Header) as credential information when sending
fetchrequests. So, if an application uses Basic or NTLM auth, Edge would send Authorization header in all fetch requests despite specifying not to include credentials.
If you noticed, I explicitly specified not to include credentials. Yet, it was sent despite me specifying not to and you can see the response in console.
fetch was a freshly implemented function, Microsoft's team might have forgotten about Basic or NTML auth. Whereas with XHR, everything was as per the spec.
Is it exploitable at all?
Yes, given a site has been configured with Basic or NTLM auth and that, in case of cross-domain requests, it responds with
Access-Control-Allow-Origin: * (ACAO) which implicitly denies access to responses for authenticated requests. This, in fact, is a very common practice for public API endpoints and is fairly safe against cross-domain data thefts. However, with Edge, anyone could read authenticated resources and steal data which are supposedly private. This, in most circumstances, can also lead to account takeover as attackers can then craft CSRF attacks.
It should be noted that-
Using * in ACAO header is really common and poses no risk (except in few circumstances). For example, a quick Censys Search, at that moment, showed 16,216 hosts using "ACAO: *" with Basic or NTLM auth. The number was somewhat similar in Shodan:
These are some platforms/frameworks using HTTP Auth:
– Apache Jackrabbit
– Microsoft Sharepoint
– Django Administration
– Tomcat Administration and many WebDav frameworks
So, essentially, if a website uses Basic or NTML auth and ACAO: *, then an attacker can bypass authentication- allowing him/her access to authenticated resources. This is NOT possible in anyway in other browsers. And, aside from cross-domain reads, it also enables CSRF with custom headers on sites using Basic or NTLM auth in certain circumstances, similar to HackerOne CSRF.
This was patched in early November, 2017 and was also assigned a CVE i.e. CVE-2017-11872, details of which can be found at https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-11872.