Start with “Same Origin Policy”

SOP, (Same Origin Policy), is a critical security mechanism that restricts how a document or script loaded from one origin can interact with a resource from another origin. It helps isolate potentially malicious documents, reducing possible attack vectors. — from Mozilla (Same-origin policy)

Define “same origin”

Two URLs have the same origin if the protocol, port(if specified), and host are the same.

What is and Why we need SOP?

SOP restricts document , JavaScript and Cookies can only be accessed, manipulated and executed within the same origin. Sometimes, AJAX loads JavaScript from different origin, but never execute it.

When loading src attribute in such <script> , <img>tags, browser allows current origin to load and execute from another origin, so SOP only focuses on the page who loads the script, not the page who stores and owns the script. SOP often allow write / execute access, but not read access from another origin. 

Other 3rd party plugins have their own SOPs, these are not browser native SOP. So these could be utilized by hackers doing XSS attack.

If there’s no SOP, you can only open one website in your browser at a time, and you have to clear all cache then open another website. WHY? 

If you open your bank website (cba.com) , at the same time, you open an malicious website (evil.com). Then javascript in malicious website can access bank website’s DOM, and get its form data, and steal its cookie.

 

 

What is CORS?

The CORS, (Cross Origin Resource Sharing), mechenism supports secure cross-orogin requests and data transfers between browsers and servers. Modern browsers use CORS in APIs such as XMLHttpRequest or Fetch_API to mitigate the risk of cross-origin HTTP requests. — from Mozilla (CORS)

Why we need CORS?

There are so many CORS scenarios, such as:

  • Backend developer finished some business logic code, then provide interface for Frontend developer. In the “Separation of Frontend and Backend Pattern”, frontend and backend domains are different. Then, CORS happens.
  • A e-commerce website wants to load tracking information in the browser, from a 3rd-party logistics website.

How CORS attack happen

Step 1: Create two hosts:

Step 2: Sheep has login page and information page:

Step 2.1: Login page set some cookies. (login.php)

Step 2.2: Information page will use these cookies and display them. (infomation.php)

Step 2.3: Access login.php first, then change URL to information.php

You should be able to see HTTP_COOKIE in your infomation page.

 

Step 3: Create a attack.html page in Wolf.com

You should get this:

 

Step 4: Allow CORS origin to attack sheep’s information page, by uncomment first two lines of code.

Then you refresh www.wolf.com/attack.html again, in your console log, you should see this:

 

What we learn from the example?

When user on wolf.com page, in the browser, and send a AJAX request to sheep.com, browser will add a Origin in the request header. It tells server that, the request is from wolf.com. (If browser does not add Origin header, sheep.com server will added in response.)

Then sheep.com receive this request, and will return the response with Access-Control-Allow-Origin header. So, the request actually has already been processed by sheep.com’s server, and also added a new header.

Then user on wolf.com page, will receive response from sheep.com, and browser will compare Access-Control-Allow-Origin with Origin value. If it is not the same, browser will block the response, and display “blocked by CORS policy”.

From the explain above, the origin from wolf.com actually can be faked by using CURL or BurpSuite tools.

Tools to check CORS

https://github.com/chenjj/CORScanner

 

References:

安全部署最佳实

跨域资源共享 CORS 详解