10

I run a localhost-only webserver (PHP's built-in one) for all my admin panels and whatnot on my machine. I'm worried that, if any random webpage has a JavaScript snippet which makes an Ajax call to http://127.0.0.1/private.txt , and I visit that webpage, it will make my browser (Firefox) fetch whatever data is returned from that URL and be able to use it, for example to send it back to their own server in another Ajax request.

Let's assume that http://127.0.0.1/private.txt returns my entire diary since 1958. Or anything equally sensitive. I definitely don't ever want it to interact with anything other than my Firefox browser, but from what I can reckon, this could be a massive privacy/security issue. I hope I'm wrong about my assumption that this request would be allowed. I hope that it has some kind of "cross-domain policy" blocking it or something. Especially since it's from 127.0.0.1, which should be some kind of special case.

What would stop it from doing this? What am I missing in my reasoning?

1
  • 4
    Don't worry, I just checked that website 127.0.0.1/private.txt and it didn't contain your diary. Only some old passwords of mine.
    – ig-dev
    Nov 23 '19 at 8:16
12

Reading

Cross-Origin Resource Sharing CORS and the Same Origin Policy SOP are your friends here. Since the javascript in question is not hosted by http://127.0.0.1, it will run afoul of the SOP and default rules for CORS in browsers will prevent the javascript from reading the response. That covers your immediate question - you are protected by default.

Writing

However, that "reading" part is key. The browser will in all circumstances make the request to the server. The only thing CORS does is block the JavaScript from receiving the response. As such, CORS stops an attacker from reading data from elsewhere, but doesn't stop it from sending data elsewhere.

As a result if your application were to make important state changes due to receiving a request, you may end up with issues. Helpfully, CSRF tokens would protect you against such attacks. To be clear, JavaScript is not even required for an attacker to send a request elsewhere (h/t mti2935) - an img tag embedded on a page you visit can trigger a GET request to any server, making it especially easy for attackers to trigger undesired actions if your server takes actions as the result of a GET request.

Therefore if your application makes state changes without CSRF protection, and the attacker knows about the endpoint, you may be in trouble. For a real life example insecure and commonly used routers have been exploited like this. Consider this hypothetical URL in the web application hosted by a home router:

http://admin:admin@192.168.1.1/enable_remote_admin_access

It enables remote admin access (aka adjusts config so that people can login to the admin section of the router from the internet), it has a well known URL, it requires basic authentication, and the router ships with a well known default username and password (admin:admin). As a result an attacker creates a webpage that makes a simple GET request to the above URL. The attacker won't get a response from the router (because of CORS) but the router still receives the request and if vulnerable, is now ready to accept admin connections from the internet. The malicious script then phones home with the victims IP address and another quick script checks their IP address to see if there is now an accessible router. If so, then the attacker has silently gained full control over the victim's home network simply because they visited the wrong page and were using a common, vulnerable router.

Arithmetic

Of course a custom application is much harder to take advantage of like this because it is a blind attack. Without information about what they are attacking, it's nearly impossible to have any success. As a result the practical risk level is likely low since the attack surface is so tiny. Still, here are some caveats to keep in mind:

  1. All bets are off in the event of a targeted attack. If the attacker knows you run some software locally that has a vulnerability, they just need you to visit the wrong link.
  2. CORS config is important. If your local app uses an overly permissive CORS configuration then an attacker could read the results and "browse" your application.
  3. Depending on how the network is configured, some basic port scanning may be possible.
  4. DNS rebinding (h/t EdC) may allow an attacker to circumvent the SOP and CORS. There can be obstacles to such an attack, but a determined attacker may improve their odds of success by using it.
7
  • Great answer, Might also want to mention DNS rebinding which allows an attacker to put local addresses in the same origin so remove the protection of SOP en.m.wikipedia.org/wiki/DNS_rebinding
    – EdC
    Nov 22 '19 at 9:05
  • Excellent answer by Conor, as usual. I wonder what (if anything) would stop the router attack described in this answer, if the URL was used in an img tag , like so: <img src=http://admin:admin@192.168.1.1/enable_remote_admin_access>, being that same-origin policy does not apply to img tags.
    – mti2935
    Nov 22 '19 at 15:10
  • 1
    @mti2935 it would make the request just the same, but the response wouldn't be accessible to javascript on the page. In general javascript has no way of fetching the actual image behind an img tag. It's also quite possible that since the response won't be an actual image, the browser will throw it away anyway. You could attempt to read it using the FileReader API or a canvas tag, but then you start running into CORS issues again. Nov 22 '19 at 15:16
  • Right, I realize that the attacker would have no way of reading the response. But, to the point that you made in your answer - the response is really not important to the attacker in this scenario. The attacker would be able to compromise the router simply making the GET request to the URL (by way of the img tag), no response needed. And, same-origin policy will do nothing to prevent this.
    – mti2935
    Nov 22 '19 at 15:27
  • 1
    Right, I completely agree. I made the point of using an <img> tag, because <img> tags are often easier for an attacker to embed in a web page, than javascript. For example, eBay allow users to create listings in HTML format, with <img> tags that reference images at other domains, but I don't think they allow users to include javascript in the HTML. It's incredible that there are routers that are so vulnerable to something that can be exploited so easily.
    – mti2935
    Nov 22 '19 at 15:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.