Detailed explanation of JS homology strategy and CSRF

Overview

This article mainly involves three keywords:

• Same-origin policy (SOP)
• Cross-site request forgery (CSRF)
• Cross-Origin Resource Sharing (CORS)

Same Origin Policy (SOP)

Homologous

Let me first explain what the same origin means: the protocol, domain name, and port are all the same, which is the same origin.

limit

The reason why you encounter cross-domain problems is because of the various restrictions of SOP. But what exactly is restricted?

If you say that SOP means "limiting the acquisition of non-same-origin resources", this is wrong. The simplest example is that cross-domain is allowed when referencing resources such as images, css, js files, etc.

If you say that SOP means "prohibiting cross-domain requests", this is also wrong. In essence, SOP does not prohibit cross-domain requests, but intercepts the response of the request after the request. This will cause the CSRF mentioned later

In fact, SOP is not a single definition, but has different interpretations in different situations:

• Limit named scopes for cookies, DOM, and JavaScript
• Limit content operations on iframes, images, and other resources
• Limiting ajax requests, or more precisely limiting the operation of ajax response results, is essentially the same as the previous one

Here are 3 examples you might encounter in real-world applications:

• Use ajax to request other cross-domain APIs, the most common situation, the nightmare of front-end novices
• iframe communicates with the parent page, the occurrence rate is relatively low, and the solution is easy to understand
• When operating cross-domain images (such as those from <img>), this problem will occur when operating images on canvas

If there is no SOP:

• If you open several tabs in a browser, your data will be leaked.
• If you use iframe to open a bank website, you can read the content of the website at will, and you can get the content entered by the user
• More aggressive CSRF

Bypass cross-domain

SOP brings security, but also brings a certain degree of trouble, because sometimes there is a cross-domain demand. Due to space limitations and the fact that there are many related articles on the Internet, I will not elaborate on the solution to cross-domain issues here, but only give a few keywords:

For ajax

• Using jsONP
• Backend CORS configuration
• Backend reverse proxy

For iframe

• Use location.hash or window.name to communicate information
• Using postMessage

Cross-site request forgery (CSRF)

Brief description

CSRF (Cross-site request forgery) is a common attack method. It means that after the A website logs in normally, the cookie is saved normally. Other websites B call the A website interface in some way to operate, and the A interface will automatically bring the cookie when requesting.

As mentioned above, SOP can load resources through htmltag, and SOP does not block interface requests but intercepts request results. CSRF takes advantage of these two.

Therefore, SOP cannot be used as a method to prevent CSRF.

For GET requests, you can directly put it in <img> to request the cross-domain interface without anyone noticing.

For POST requests, many examples use form submission:

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
  <input type="hidden" name="acct" value="MARIA" />
  <input type="hidden" name="amount" value="100000" />
  <input type="submit" value="View my pictures" />
</form>

In the final analysis, these two methods do not report cross-domain because the request is controlled by HTML, and you cannot use JS to directly manipulate the results.

SOP and ajax

For ajax requests, you can perform js operations as you wish after obtaining the data. At this time, although the same-origin policy will prevent the response, the request will still be made. Because it is the browser rather than the backend program that performs the response interception. In fact, your request has been sent to the server and the result has been returned, but due to security policies, the browser does not allow you to continue js operations, so it reports the familiar message "blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource."

So let me emphasize again that the same-origin policy cannot be used as a method to prevent CSRF.

However, there are exceptions that can prevent CSRF. The browser does not allow all requests to be sent successfully. The above situation is limited to simple requests. The relevant knowledge will be explained in detail in the CORS section below.

CSRF Countermeasures

SOP is exploited by CSRF, so is it really useless?

no! Do you remember that SOP limits the naming range of cookies? Although the request will automatically bring cookies, the attacker will not be able to obtain the cookie content itself anyway.

So the idea to deal with CSRF is to write a token into a cookie and then include the token in the query, body or header when making a request. The request arrives at the server and checks the token. If it is correct, then it must be a request sent by the domain that can see the cookie. CSRF cannot do this. (This method is used to separate the front-end and back-end, and the back-end rendering can be written directly into the DOM)

The sample code is as follows:

var csrftoken = Cookies.get('csrfToken')

function csrfSafeMethod(method) {
  // these HTTP methods do not require CSRF protection
  return /^(GET|HEAD|OPTIONS|TRACE)$/.test(method)
}
$.ajaxSetup({
  beforeSend: function(xhr, settings) {
    if (!csrfSafeMethod(settings.type) && !this.crossDomain) {
      xhr.setRequestHeader('x-csrf-token', csrftoken)
    }
  },
})

Cross-origin resource sharing (CORS)

Cross-domain is a browser restriction, but if the server sets CORS related configuration, Access-Control-Allow-Origin will be added to the information header returned to the server. When the browser sees that the value of this field matches the current origin, it will unlock the cross-domain restriction.

HTTP/1.1 200 OK

Date: Sun, 24 Apr 2016 12:43:39 GMT

Server: Apache

Access-Control-Allow-Origin: http://www.acceptmeplease.com

Keep-Alive: timeout=2, max=100

Connection: Keep-Alive

Content-Type: application/xml

Content-Length: 423

For CORS, there are two types of requests.

Simple request

• The request method is GET, POST or HEAD.
• Content-Type is set to application/x-www-form-urlencoded, multipart/form-data, or text/plain

All requests that meet the above two conditions are CORS simple requests. Simple requests are sent directly to the server, which may cause CSRF.

Preflight Request

Requests that do not meet the requirements of a simple request need to send a preflight request first. The browser will send a request with the OPTION method to ask the server whether the current source meets the CORS target before making the actual request. The formal request will be sent only after the verification is passed.

For example, a POST request that uses application/json to pass parameters is a non-simple request and will be intercepted during pre-check.

For example, if a PUT method request is used, a pre-check request will also be sent.

The exception mentioned above that can prevent CSRF refers to pre-check requests. Even if the cross-domain request pre-check is successful, the actual request cannot be sent out, which ensures that CSRF cannot succeed.

CORS and cookies

Unlike the same domain, cross-domain CORS requests do not send cookies and HTTP authentication information by default. Both the frontend and backend must set the request to include cookies in the configuration.

This is why axios needs to set withCredentials: true when making CORS requests.

Below is the CORS setting of the node.js backend koa framework:

/**
 * CORS middleware
 *
 * @param {Object} [options]
 * - {String|Function(ctx)} origin `Access-Control-Allow-Origin`, default is request Origin header
 * - {String|Array} allowMethods `Access-Control-Allow-Methods`, default is 'GET,HEAD,PUT,POST,DELETE,PATCH'
 * - {String|Array} exposeHeaders `Access-Control-Expose-Headers`
 * - {String|Array} allowHeaders `Access-Control-Allow-Headers`
 * - {String|Number} maxAge `Access-Control-Max-Age` in seconds
 * - {Boolean} credentials `Access-Control-Allow-Credentials`
 * - {Boolean} keepHeadersOnError Add set headers to `err.header` if an error is thrown
 * @return {Function} cors middleware
 * @api public
 */

The above is a detailed explanation of JS Same-Origin Policy and CSRF. For more information about JS Same-Origin Policy and CSRF, please pay attention to other related articles on 123WORDPRESS.COM!