-1

I fail to understand certain things that I'd like to ask.

Scenario 1: I create a HTML/JavaScript website, in which I use AJAX to obtain HTML of Google.com, I'm met with infamous Cross-Domain issue (No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.)

Scenario 2: I enter www.google.com, I select Source Code in my context menu and I get the enter code.

Here are the questions:

  1. What purpose does this message (and it's implications) have? How is Google protected from my devilish evil script whilst I can request the same website through browser? Isn't the request identical?

  2. How are there origin differences between Scenario 1 and Scenario 2 when the source is browser, my laptop, my router, my ISP, the internet and then Google in both cases.

  3. Why and who invented the way to discriminate against local scripts against browser itself, what purpose does it serve? If request would be malicious it would be equally malicious in both scenario's.

  4. How does Google know what origin it comes from and how is it any different than me requesting their website through address bar? Once again, same exact origin.

J. Doe
  • 3
  • 1
  • I had this same question before and I can't remember all of the answers (the guy was talking over my head), but one thing I remembered was that if you could use AJAX outside of your domain, then you potentially access the users files by sending requests to "file:///Users/...". I guess I still don't understand why that couldn't be prevented without preventing access to other websites. – RyanDay Jan 20 '18 at 22:20
  • I wasted 3 days on this.Those where 3 very bad days. I enabled cors and everything. I think when using localhost it causes this. – Mohamoud Mohamed Jan 20 '18 at 22:27
  • Yes, but `file:///Users/` instantly indicates *person themself*. If you request `file:///` you definitely don't request foreign websites. You try to access your own file system. So it still makes no sense to me. – J. Doe Jan 20 '18 at 22:27
  • Possible duplicate of [Why does my JavaScript get a "No 'Access-Control-Allow-Origin' header is present on the requested resource" error when Postman does not?](https://stackoverflow.com/questions/20035101/why-does-my-javascript-get-a-no-access-control-allow-origin-header-is-present) – German Lashevich Jan 20 '18 at 22:29
  • @J.Doe, if you get someone to open an html document on their own system and it can make requests to your file system, then do something with them or send them/the data in them to another URL. That could dangerous. But again, I would assume the browsers would be able to discern requests to a file system vs. another website. – RyanDay Jan 20 '18 at 22:31
  • @RyanDay Equally bad would be getting someone to open an HTML document on their own system and it making malicious requests to another website, like their bank's website that they happen to be logged into. Even if their bank uses CSRF tokens that just means the HTML document needs to make two requests to steal all their money instead of one. – Paul Jan 20 '18 at 22:47
  • Gotcha, yeah it's making sense now. – RyanDay Jan 20 '18 at 22:50

2 Answers2

3

Origin has nothing to do with your browser, laptop, router, ISP, etc. Origin is about the domain which is making the request. So if a script https://evil.com/devious.js is making an XHR request to http://google.com, the origin for the request is evil.com. Google never knows this. The user's browser checks the access control headers (the Access-Control-Allow-Origin you mentioned) and verifies that that script is permitted to make that request.

The purpose of all of this is to prevent a malicious script from (unbeknownst to a user) making requests to Google on their behalf. Think about this in the context of a bank. You wouldn't want any script from any other website being able to make requests to the bank (from your browser on your behalf). The bank can prevent this by disabling cross domain requests.

And to (1): When you open console on a google.com page, any requests you make have the origin google.com, which is why you are able to make these requests. This is different than the case I just mentioned, because the user would have to make a conscious effort to copy some malicious javascript, go to their bank's website, open up the console, and paste and run it (which many users would be suspicious of).

Bailey Parker
  • 15,599
  • 5
  • 53
  • 91
  • Isn't script from `evil.com/devious.js` downloaded by me during `evil.com` request and isn't my browser making the request to `google.com`? What's the difference between that? – J. Doe Jan 20 '18 at 22:23
  • What do you mean by "during `evil.com` request"? Yes your browser requests `https://evil.com/devious.js`. But any request that that script makes is flagged with the origin `evil.com`. So if it tries to request `google.com` (via AJAX for example), the browser knows it's coming from `evil.com`. The browser will perform a HEAD request and determine if CORS is set (and that this request obeys by the CORS header). – Bailey Parker Jan 20 '18 at 22:25
  • Couldn't this be easily spoofed and my browser to simply lie it comes from domain it doesn't? Wouldn't it render this entire operation useless? – J. Doe Jan 20 '18 at 22:28
  • Nevermind, I get it. It's to prevent local scripts to interacting without my will. Now I get it. It's my protection, not theirs and they help with it, by blocking these requests. – J. Doe Jan 20 '18 at 22:29
  • Yes but the attacker doesn't have control of the browser. The browser is trying to protect the user. Of course, yes if the browser was compromised or malicious CORS would be useless. But assuming it isn't, the browser wants to protect the user so it will deny requests that disobey CORS. – Bailey Parker Jan 20 '18 at 22:30
3

Websites are not typically stateless, they often store information on your machine, such as a session cookie that identifies the account you're logged into. If your browser didn't block cross origin requests that aren't explicitly allowed, you could be logged into gMail and then got to randomguysblog.org and a script on randomguysblog.org could make a POST request to gMail using your browser. Since you are logged in he could send emails on your behalf. Perhaps you're also logged in to your bank and randomguy decides to initiate a transfer for all your money to his account, or just look around and see how much money you have.

To respond to your questions individually:

What purpose does this message (and it's implications) have? How is Google protected from my devilish evil script whilst I can request the same website through browser? Isn't the request identical?

It's not Google directly who is protected, it's the users of your website who are also logged into Google. The request is identical, but the users browser won't even send the request assuming the server supports pre-flight, if the server doesn't support pre-flight requests, then it will send the request but won't allow the script that initiated it to see the response. There are other ways to send requests without seeing the response that don't use Ajax, such as by submitting a hidden form, which is why CSRF tokens are also needed. A CSRF token makes an action require two requests and a token in the response from the first request is needed to make the second one.

How are there origin differences between Scenario 1 and Scenario 2 when the source is browser, my laptop, my router, my ISP, the internet and then Google in both cases.

In scenario 2 the user is making both requests themselves so they must intend to make both request. In scenario 1 the user is only trying to access your website and your website is making the request to Google using their browser which they might not want your website to do.

Why and who invented the way to discriminate against local scripts against browser itself, what purpose does it serve? If request would be malicious it would be equally malicious in both scenario's.

The purpose is to protect browser users against malicious scripts. The malicious script can't access the response from Google in scenario 1. The user can, but it's not intended to protect users from attacking themselves.

How does Google know what origin it comes from and how is it any different than me requesting their website through address bar? Once again, same exact origin.

Google can could check the referrer header, but they don't actually need to know where the request is from. Google only needs to tell the browser where requests are allowed to come from and the user's browser decides whether or not to send the request to Google.

Paul
  • 139,544
  • 27
  • 275
  • 264