In last post about CORS i explained the cases where and how we can detect the presence of CORS misconfiguration, so this post will cover the one of specific case from them.
So last week while testing one of web application for CORS misconfiguration, i came across a scenario and this is how it looks like:
Request 1#
GET /settings HTTP/1.1 Host: www.site.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Accept: */* Accept-Language: en-US,en;q=0.5 Referer: <Redacted> Origin: https://www.attacker.com Cookie: <Redacted> Connection: close
Response 1#
HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH Access-Control-Allow-Origin: https://www.site.com Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Type: text/html; charset=utf-8 Date: Sat, 10 Jun 2017 00:27:22 GMT Expires: Fri, 01 Jan 1990 00:00:00 GMT .... [data]
Request 2#
GET /settings HTTP/1.1 Host: www.site.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Accept: */* Accept-Language: en-US,en;q=0.5 Referer: <Redacted> Origin: http://www.site.com Cookie: <Redacted> Connection: close
Response 2#
HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH Access-Control-Allow-Origin: https://www.site.com Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Type: text/html; charset=utf-8 Date: Sat, 10 Jun 2017 00:27:22 GMT Expires: Fri, 01 Jan 1990 00:00:00 GMT .... [data]
Request 3#
GET /settings HTTP/1.1 Host: www.site.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Accept: */* Accept-Language: en-US,en;q=0.5 Referer: <Redacted> Origin: https://test.site.com Cookie: <Redacted> Connection: close
Response 3#
HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH Access-Control-Allow-Origin: https://www.site.com Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Type: text/html; charset=utf-8 Date: Sat, 10 Jun 2017 00:27:22 GMT Expires: Fri, 01 Jan 1990 00:00:00 GMT .... [data]
Request 4#
GET /settings HTTP/1.1 Host: www.site.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:53.0) Gecko/20100101 Firefox/53.0 Accept: */* Accept-Language: en-US,en;q=0.5 Referer: <Redacted> Origin: https://www.site.com.attacker.com Cookie: <Redacted> Connection: close
Response 4#
HTTP/1.1 200 OK Access-Control-Allow-Credentials: true Access-Control-Allow-Headers: User-Agent,Keep-Alive,Content-Type Access-Control-Allow-Methods: GET, POST, OPTIONS, DELETE, PUT, HEAD, PATCH Access-Control-Allow-Origin: https://www.site.com.attacker.com Cache-Control: no-cache, no-store, max-age=0, must-revalidate Content-Type: text/html; charset=utf-8 Date: Sat, 10 Jun 2017 00:27:22 GMT Expires: Fri, 01 Jan 1990 00:00:00 GMT .... [data]
so from request 1-3 we can see, the ACAO is properly set no matter from what Origin its requested, but in case 4 we can see the anything after domain name site.com is getting reflected back to ACAO header.
So i thought to exploit it, and after bit of confusion and quick tip from James cleared my doubts. so i enabled the wildcard entry for my domain geekboy.ninja.
And idea is of wildcard will work like this, now if i request anything in this manner: https://site.com.geekboy.ninja/exploit.html, it will valid request and exploit.html will be served from domain geekboy.ninja/exploit.html and other side, Origin will be set as: https://site.com.geekboy.ninja which is the requirement of this case.
And this is how a small misconfiguration allows attacker to bypass the SOP of website.
Takeaways for hackers: check for every variations of Origin header, for dev: use predefined ACAO dynamically.
do let me know if you have any question in comment section.
Nice post it expand my knowledge on exploiting CORS configuration 🙂 Thank
Awesome post, Last post helped me alot…. and Now this one 👌 Can u share any tut on Enabling wildcard entry on my domain 🙂 Thanks
Sorry , i didnt get ” so i enabled the wildcard entry for my domain geekboy.ninja. ” want to do any setup on attackers domain?
Yes, you need to enable wildcard entry for your domain, you can google about it or use any free service.
how can i get this domain from internet? can you help me to get any cheap domain. where i can create any folder , html file etc.
i created in wordpress, there i am not able to.
” so i enabled the wildcard entry for my domain geekboy.ninja. ”
how to do ? it is important!
Hey, make subdomain name as “*”
Cleared my doubt of exploiting CORS!! Thanks alot!
Hi need one help sir,
what if the 3rd request reflected back in response. Can we exploit it ?
Hey, the 3rd case is about allowed any subdomain of the target application, you can exploit it if you XSS on 1 on the subdomain on the target application otherwise NOT.
Hey,
Nice post. I came across one application which makes use of CORS. I am able to get the origin header set in the request in the response of Allow-Origin header. Its similar for request and response 2 & 3 as highlighted in the post. Is it still an issue and should be reported?
You should.
Hi,
Can you share the code which is used for retrieving CSRF token?
What if the server checking the origin header like ‘*.domain.net’ so if i set origin header To ‘[Link deleted]it will work or not.
No, it means the site is whitelisted the subdomain of the target website, you need to have XSS on any subdomain to perform CORS request.
What if you would have received “Access-Control-Allow-Origin: [Link deleted]for request header “Origin: [Link deleted]Notice the scheme in the response header. Would this be exploitable ?
great post . sir if all http methods are allowed in response and credential is true and origin is third party domain is reflected of any user info url of any domain and when we exploit this cors then it is clearly showing third party domain is accessing this user info detail of this domain. then is it possible for third party domain to use put post or delete method do some manipulation in this url .if yes then how? .its urgent pls reply me I have submitted report. thanks
Hey, please keep in mind sometimes this is enabled by the design, for showing security impact of the report, you need to find an endpoint which leaks or allows to make changes in users settings.