1

I asked this question: What would happen if some random webpage made an Ajax request for http://127.0.0.1/private.txt?

The answers/comments confuse me. Am I right in interpreting them like this?

"Even though Ajax requests to 127.0.0.1 will apparently be blocked if they are made from any other domain/IP address, 192.168.1.1 will not have that protection."

Is that correct? If so, why is that? I'm very confused about how "casually" this is mentioned and how cryptically it's described. It seems like the most important point to focus on, unless I completely misunderstand something.

Why would 192.168.1.1 (and supposedly other IP addresses beginning with 192.) Ajax requests be allowed from www.evilmalwaresite.ru?

(Or in the src for an <img>, for that matter.)

1
  • Sorry for the confusion! Hopefully @Ghedipunk has given a more clear answer than I did. I also updated my answer on your original question to (hopefully) be more clear. Nov 23 '19 at 2:47
2

They're not being treated differently.

As explained in the answers to the original question, if a malicious site had a script that requested //127.0.0.1/private.txt, they would not be able to read that file. However, what was glossed over is that your browser would still make the request to your local web server.

The only protection that Cross-Origin Resource Sharing (CORS) provides, in the context that you're asking, is the malicious script will not be able to read the data in your file.

In the answers on the original question, we are warned that even though the malicious site could not get the data from that file, they can still cause side effects. The example that we are given, where a router's admin panel was exploited in order to give external access, was simply an arbitrary example where someone can cause damage within the secure parts of a home network, even if they can not get data from that.

In the example, if (instead of simply trying to read sensitive information) the malicious site caused you to load //127.0.0.1/deletePrivate_txt.php, your browser will make that request to your local web server. They won't be able to read the results of that request, but the request will still happen, and whatever side-effects that this script has (such as deleting every diary entry since 1958) will happen as well.

CORS protects sites from reading sensitive information, regardless of the IP address of the web server. However, CORS does not (and is not designed to) protect against Cross-Site Request Forgery (CSRF).

1
  • SOP (Same-Origin Policy) thwarts cross-origin response reading, not CORS; CORS enables cross-origin reads. To OP, the behaviors shouldn't be different.
    – Poppy
    Oct 17 at 18:48

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.