Can a website make an HTTP request to "localhost"? How does it get around the cross-domain policy?

Question

I found this website which talks about fixing a Redis vulnerability by exploiting that same vulnerability.

The website in question has a "patch me" button, and if you have a password-less Redis server running on your machine, it will patch it.

In other words, the website itself connects to the Redis Server in your computer and executes some commands.

If you look into the website code you find, predictably, this:

    var text = "the code to run";
    var bad = "EVAL "  + JSON.stringify(text) + " 0\r\n";
    var x = new XMLHttpRequest();
    x.open("POST", "http://localhost:6379");
    x.send(bad);

To my surprise, this works!

I thought the Cross-Domain Policy would stop this from running, but it doesn't.

Why does this work, and how can I now not be paranoid that every website I go into is reading the entire contents of my Redis server?

It is because it's only writing but not reading? Still, any website in the world could empty my local Redis server / write to anything else listening to a port in my machine without authentication.

Am I missing anything here?

Answer 1

Was pointed out due to incorrect assumptions about the issue that this answer below is wrong. If I get a chance I will revisit, or just delete this answer. Sorry!

To answer the question: Yes a website can make an HTTP request to localhost. It will not break cross domain policy, because the request will not cross domains. It will stay local. One way to avoid cross domain policies, is to get the target victim to make the HTTP request themselves. Thus the request never crosses domains.

To help you understand the issue you described:

The attack is not sending any data out, nor is it making a connection to anywhere other than the local Redis machine. It's not the website itself connecting to your Redis machine. It's you connecting to your Redis machine, executing client side code/scripts that you ran by clicking the link. Basically: You click link > Link downloaded and executes some code -> code generates an http request -> http request goes from your machine, to your machine.

The vulnerability of the Redis server in this situation is Cross Site Request Forgery. The attacker leverages the victims (in this case, the owner of the server) authentication to execute the attack.

The attacker doesn't have full control over the process. They rely on the owner of the Redis server to execute the code. Only the owner (or someone else local to the Redis server) has the visibility (and perhaps the permission and trust relationship) to access 127.0.0.1 (Localhost)

All that the code can do is execute commands that the local user can execute, but it's not the attacker that executes them, it's the owner, and so no Cross Domain Policies are violated.

The only people affected by links like that would be people running Redis servers. If you don't have one, the link won't do anything. Also, it will only run on the local Redis server. The attacker can't really choose where the exploit will happen.

Look up Cross Site Request Forgery. https://en.wikipedia.org/wiki/Cross-site_request_forgery

Answer 2

Im surprised nobody has pointed out that the accepted answer (by meltdownmonk) is wrong.

"It will not break cross domain policy, because the request will not cross domains. It will stay local. One way to avoid cross domain policies, is to get the target victim to make the HTTP request themselves. Thus the request never crosses domains."

"It's not the website itself connecting to your Redis machine. It's you connecting to your Redis machine, executing client side code/scripts that you ran by clicking the link"

"The attacker doesn't have full control over the process. They rely on the owner of the Redis server to execute the code."

"...it's not the attacker that executes them, it's the owner, and so no Cross Domain Policies are violated."

This is not how the Same-Origin-Policy (SOP) and Cross Origin Resource Sharing (CORS) work. Of course the request will cross domains when a website tries to connect to localhost. Also it is the website itself trying to connect to your redis and not the user - the attacker does not have to rely on the user. There is no difference whether the code runs automatically in the background or if the user clicks a button.

A website is basically able to send requests to localhost on different ports and can thereby even run a port scan. The browser's CORS implementation will ensure that data cannot be read by javascript. Therefore, the attacker cannot steal data from localhost and send it to a server. This is only true of course as long as your services on localhost do not explicitly allow CORS requests to be made (when they sent allow-origin headers, the attacker can steal data).

Apart from this, requests are still possible and therefore CSRF attacks are also possible. Such a CSRF attack could be triggered with a simple javascript HTTP-request (which does not require a CORS preflight check), but also HTML form data sent via GET/POST and websockets can be used to establish a connection to local services.

So to sum it up, if you visit a website, this website will be able to send requests to your local services on your computer on different ports. Reading data from your local services is normally not possible.