10

I recently found the following HTTP headers on a site that could at the very least be described as a high value target:

Access-Control-Allow-Origin: http://localhost:8888
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: [some custom non-standard headers]

This looks weird to me, or at least not compliant with the CORS RFC:

The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, "*", or "null" in the response.

The returned value is obviously not my Origin request header (or * or null). So, my questions are:

  • Is there any good reason for sending these headers? To me it seems like something used in testing that have accidentally leaked into production.
  • Is it possible to exploit this in any way? Seems unlikely to me, since only a tiny minority of users will have anything running on that port, plus an attacker would not be able to control it anyway. But maybe I am overlooking something.
  • Is this something that warrants contacting the site in question to inform them about the issue?
Improve this question
7
  • If not a testing hangover, does the web app have a local option? Maybe a local service that can integrate? It does seem odd though and if the browser considers it valid, it does open a small possibility of local malware intercepting what should be server traffic. Hard to say without understanding the application.
    – Julian Knight
    Dec 28, 2016 at 17:29
  • @JulianKnight No, no local option and no local service integration, at least not that they advertise to the customers.
    – Anders
    Dec 28, 2016 at 19:02
  • @JulianKnight Besides, if there was anything like that it should only send that in the header if you actually make a request from that origin.
    – Anders
    Dec 28, 2016 at 19:18
  • 1
    True enough, just a thought.
    – Julian Knight
    Dec 28, 2016 at 23:15
  • 2
    See my answer here. Very very unlikely that the site would be compromised in such a manner, but technically a risk. This is somewhat mitigated in your case because it does not allow credentialed requests to return responses.
    – SilverlightFox
    Jan 7, 2017 at 17:53

2 Answers 2

Reset to default
2

For an attacker to make use of this CORS header, he must run Javascript on localhost:8888. Inspired by your question, I looked for a service that runs on localhost:8888 and allows an attacker to run Javascript. I found one:

MAMP is a webstack that runs on port 8888 by default, and comes with the vulnerable SQLiteManager. SQLiteManager has several vulnerabilities, one of which is XSS using CSRF, so an attacker could trigger Javascript remotely to run in the context of localhost:8888. It would then be able to read data from your high value target.

This attack is not really probable, since it would only work for users that are both visitors of your site and users of MAMP. Furthermore, MAMP also has a remote code execution vulnerability, so the attacker does not need the CORS header to read HTTP responses.

Improve this answer
1

I believe this should be exploitable in a typical MiTM scenario, especially if you don't use HSTS headers (also no need to downgrade as it's in HTTP anyways) -- a typical DNS spoofing attack can make a victim's IP of the same local network as localhost:8888 navigation leading to believe it's you and responding with the CORS response. -- I really don't see why you need a site with this kind of CORS response header

Improve this answer
1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .