About csrf CSRF attack principle, the principle of prevention and csrftoken

Principles and processes csrf attack

　　CSRF cookie using the normal login user generated, while still keeping the user logged in, visit the phishing site passed to the user to send a form and the content of the code containing the attack, the front end can use js send request and held hostage normal site of the user's login access cookies normal website, the purpose of the forged forms through the user's hand spread on the site. To avoid the user submits the form to other sites produced, the website issued when the user logs on to the user a csrftoken, the token is not stored in the cookie (stored in a local storage in the browser), call (identified by the website front-end JS {{csrftoken}}), submitted when the token carries the required form from the form in order to verify this website (server authentication token data stored in the session).

How CSRF defense

Submit codes
to add a random number or letter codes in the form. Interaction by forcing users and applications. To effectively curb the CSRF attack.
Referer Check
check assume a non-normal over the page request, the most likely CSRF attacks.
token verification
- In the HTTP request is added in the form of parameters of a randomly generated token and establish an interceptor server side to authenticate the token, no token is assumed that the request token or not the content, it may be that the request is rejected CSRF attack.
- token need random enough
- Sensitive operations should use POST. Instead of GET, submitted in the form form form. Token leak can be avoided.
HTTP header and validate their custom attributes

Such methods are used for authentication and token. Here the token is not placed into the form of an HTTP request parameters, but put it in their properties defined in the HTTP header in. XMLHttpRequest by this class, the class can be a one-time request to all the HTTP header plus csrftoken this property. And the token value into them. Such methods overcome the inconvenience added token in the request. The same time, will not be recorded into the address bar of the browser's address by XMLHttpRequest request, do not worry about token leak to other sites through Referer go.

About token #

Token should be saved (into the local / stograge the session )
Token addition to the same period of validity as the cookie, you also need to have a lot of other methods of operation. Once the token expires, only need to once again get one. You can use an interface to refresh token. You can even put token original publication time saved. And what forced once again to log in two weeks. Suppose you need to withdraw tokens (when the token lifetime longer when it is necessary) then you need to generate a token manager go for a check.
Local / session storage will not work across domains, use a tag the cookie : Same Origin Policy browser-based
There is need, then, to encryption and signature token
The JSON Web Tokens application to OAuth 2

About cross-domain requests whitelist

django-cors extended django flask or other extension

Write middleware, the middleware to intercept processing options
Way to determine whether the request is options, if not opitons, left untreated, into the view of the execution, otherwise, the process in accordance with the following procedure
Remove the access domain name from the request options, in contrast to the white list allows the domain name,
If the white list is returned to allow cross-domain access, otherwise not allowed

Same Origin Policy browser

Same Origin Policy (Same origin policy) is a convention, it is the core of the browser is also the most basic security feature, if the lack of the same origin policy, the browser's normal function may be affected. Web can be said to be built on the basis of the same origin policy, but the browser is directed to a realization origin policy. Said simply, a special property of the same origin policy is the browser itself, browser when accessing resources will be constrained in the same-origin policy, to avoid different sites to get information easily with each other.

The so-called homologous refers to the domain, protocol, the same port. When two tab pages in a browser are open Baidu and Google page. When executing the script browser Baidu tab page script which will check this page belongs, namely to check whether homologous, and Baidu only homologous script will be executed. If the non-homologous, then the data is requested, the browser will be an exception, denied access to the console prompt mid-year report.

We know that the browser is HTTP request mode acquisition request resources, such as: Http://www.baidu.com:8080/xxxx . In which the HTTP protocol is a request, www.baidu.com domain name, the port number is 8080, meaning that the request using the HTTP protocol mode, the server requests a resource on www.baidu.com XXXX 8080 ports deployed service from the domain name.

Then when the protocol, the domain name, the port is not the same, that is, different sources.

Copy

现在有一个网站：http://www.a.com/a。

https://www.a.com/a          ：不同源，协议不同，此处协议是https！

http://www.b.com/a ：不同源，域名不同 http://www.a.com:8080/a ：不同源，端口不同 http://www.a.com/b ：同源 综上，跨域就是请求路径的url不同源。

Refer to the documentation: https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy

session, localStorage, sessionStorage, cookies storage mechanism different from #

localStorage, sessionStorage, cookies can be used to cache data stored in the browser.

sessionStorage, cookies stored both as closing the browser or stopping access to the server and will disappear, and not a permanent presence.

localStorage is not cleared in this way, only when the user manually clearing the browser cache in order to truly clear out the data.

session not to store on the client, but stored on the server side. cookies will be saved in a sessionID, in order to verify the user's identity.

In the past, these caches are stored by the cookies done. However, cookies are not suitable for storing large amounts of data, by each of them to pass the request to the server, which makes the cookie is slow and inefficient.

In HTML5, the requested data is not transmitted by each server, but only using the data in the request. It allows to store large amounts of data without affecting site performance possible. For different website, data is stored in different areas, and a Web site can only access their own data.

That is when the browser opens a tab meet the same origin policy, can operate for mutual access data between each page, so they do not repeat repeated request for data operations, such as logging rights, access to user information and so on.