The same-origin policy

What is the same

The same origin policy means that the protocol, domain name, and port are the same.

The purpose of the same-origin policy

Without the same-origin policy, when we open a bank’s website, if another malicious site is opened at this time, the malicious site will do a lot of things like:

  • Modify bank site DOM, CSSDOM, etc
  • Insert javascript scripts inside the bank site
  • Hijack user login username and password
  • Read cookies, indexDB and other data of bank websites
  • Fake transfer requests, etc

From this point of view, the online world will become very chaotic if left unchecked. Therefore, the same origin policy aims to protect user information and prevent websites from malicious data theft.

Limit content

Although restrictions on the same origin policy are necessary, they can sometimes be inconvenient, and their legitimate use can be compromised. So how can we reasonably circumvent these restrictions? So let’s analyze it.

  • Data level: Cookies, localStorage, and IndexDB cannot be read
    • Cookie: Cookie is a small piece of information written to the browser, but only the same origin can be shared, but for two web pages with only the second level domain name different, can be set through document.domain
    • LocalStorage and IndexDB: Use postMessage
  • Dom level: Dom is not available
    • postMessage
  • Network layer: Ajax requests cannot be sent
    • Json:<script>The tag has no cross-domain limitation “hole”. Web pages by adding one<script>Tag to request JSON data from the server. The server receives the request and returns the data in a named callback function.
    • CORS: Cross-domain resource sharing. The key to CORS communication is the server. As long as the server implements the CORS interface, cross-source communication is possible.

XSS attacks

What is an XSS attack

XSS (Cross Site Scripting) stands for cross-site Scripting. In our pages, third-party resources can be referenced. Hackers inject malicious scripts into HTML or DOM to attack users when they browse the page. This attack was initially implemented by cross-domain, but cross-domain is no longer the only way, but the name XSS has stuck.

What problems can malicious scripts cause?

  • Steal user information: JS can obtain cookie information through document.cookie, and can simulate user login on other computers.
  • Listen for user behavior: You can use addEventListener to listen for events, such as keyboarding id numbers
  • Modify DOM: forge fake login window
  • Create floating window ads in the page, affecting the user experience

Common injection methods of malicious scripts

  • Stored XSS attack
    • Use the vulnerability of the website to enter a section of JS code, and put this code into the database. A user requests a page from a web site that contains a malicious JS script. Malicious scripts steal user information such as cookies.
  • Reflex XSS attack
    • Script code is added to URL parameters, such as when openhttp://localhost:3000/?xss=<script>alert(' you have been attacked by XSS ')</script>This URL, the page will display a pop-up box. Hackers may use this vulnerability to induce us to click on QQ or email malicious links.
  • Dom-based XSS attacks that modify data on a Web page during the transfer of Web resources or while a user is using the page.

How do YOU prevent XSS attacks?

  • HttpOnly: Since many XSS attacks are designed to steal cookies, we can also secure our cookies by using the HttpOnly attribute.
  • Filter or transcode the input content through the server
  • Take full advantage of CSP

CSRF attacks

What is a CSRF attack?

CSRF, also known as cross-site request forgery, means that hackers lure users to open the hacker’s website and launch cross-site requests using users’ login status. To put it simply, CSRF attack means that hackers take advantage of users’ login status and do some bad things through third-party sites.

How do you prevent CSRF attacks?

  • The SameSite property of the Cookie: See the Cookie guide for details. To protect against CSRF attacks, we can set some key cookies to Strict or Lax mode depending on the actual situation
  • Verify the source site of the request: The site that verifies the source of the request on the server side
  • CSRF Token: The server generates a CSRF Token when the browser makes a request to the server. If you want to initiate a transfer request on the browser side, you need to bring the CSRF Token in the page, and then the server will verify that the Token is valid.