This is the 28th day of my participation in Gwen Challenge
What is CSRF?
For example, if we need to delete an article on a blog, the attacker first constructs a page in his domain, using an IMG tag whose address points to the deleted blog link. Attacker to induce target users, that is, bloggers visit this page, the user saw a unable to display a picture, look back at this time in the blog, this article found that the article has been removed, the original just image links sweet blog server sends a get request, this time request, led to one side of the blog articles be deleted. Throughout the successful attack, the attacker only lured a user to a page and then performed an operation on a third-party site under that user’s identity. The request to remove the blog post is forged by the attacker, so the attack is called “cross-site request forgery.”
Browser Cookie Policy
The attacker’s forged request can be authenticated by the server because the user’s browser sends a cookie. There are two types of cookies held by browsers: Session cookies, also known as “temporary cookies”, and third-party cookies, also known as “local cookies”. The Cookie will Expire only when the Expire time expires. Therefore, the Cookie will be stored locally: Session cookies, on the other hand, have no Expire time specified, so Session cookies Expire when the browser closes.
If a website sets a Session Cookie, the Session Cookie is valid even if the browser opens a new Tab page during the lifetime of the browser process. The Session Cookie is stored in the memory space of the browser process. Third-party cookies are stored locally.
Third=party cookies are blocked by default in IE6, IE7, IE8, and Safari. Firefox 2, Firefox 3, Oprea, Google Chrome, Android, etc.
However, if the target of CSRF attack does not need to use cookies, you do not need to worry about the browser’s Cookie policy.
Side effects of P3P head
Although some CSRF attacks can be carried out without authentication and without sending cookies, it is undeniable that most sensitive or important operations are hidden behind authentication. Therefore, the sending of third-party cookies by browsers, to some extent, reduces the power of CSRF attacks. However, the situation is complicated by the involvement of the P3P head. The P3P header is a privacy standard developed by w3c. If a WEB site returns an Http header containing a P3P header to the browser, it allows the browser to send third-party cookies to some extent.
For example, the front-end uses iframe to load a piece of back-end code. The back-end code tries to set set-cookie, and the browser receives a Cookie. If the setcookie succeeds, the browser sends the Cookie it just received when it requests the page again. But because of the cross-domain display, set-cookie is not successful, so can not send the cookie just received. It doesn’t matter if it’s a temporary Cookie or a local Cookie. The second time the packet is sent, only the Cookie is received again, and the value of set-cookie of the last time is not sent, indicating that set-cookie is not successful. However, this situation changes with the addition of a P3P header, which allows cross-domain access to private data and thus cross-domain set-cookie success.
The introduction of the P3P header changes the privacy policy so that iframe, script and other tags in IE do not block the sending of third-party cookies. The P3P header only needs to be set once by the site, and each subsequent request follows this policy without having to be set again.
P3P header is currently widely used in the application of websites, so the defense of CSRF cannot rely on the browser’s blocking strategy against third-party cookies.
Request way
CSRF attacks is popular in the beginning, it was once thought can only be initiated by a Get request, therefore many development put some important operation to the post request, but this view is wrong, the main reason is that most of the CSRF attacks launched by the label attribute, such labels can only launch a Get request, rather than a post request.
Feasible CSRF defense
1. The verification code
Captcha is considered to be the simplest and most effective defense against CSRF attacks. It forces the user to interact with the application in order to complete the final request. Therefore, captcha can contain CSRF well. However, it is not omnipotent, and it is impossible to add verification codes to all user operations. It can only be used as an auxiliary means, but not as the most important solution.
2. Referer Check
This method can be used to check whether the request is coming from a legitimate “source.” In common Internet applications, there is a certain logical relationship between pages, which makes the Referer of each normal request have a certain rule. The drawback is that servers don’t always get Referer. Many users have privacy concerns that limit Referer. Browsers also don’t send referers in certain situations, such as jumping from Https to Http, and they don’t send referers for security reasons. Therefore, this method can not be used as the main means.
Token
The essence of CSRF: All parameters of an important operation can be guessed by an attacker. An attacker can successfully construct a forged request only by predicting all the parameters and parameter values of the URL. Otherwise, the attacker cannot attack successfully. Therefore, we need a more general solution to help solve this problem, which is to use tokens.
Tokens are random and unpredictable. The token needs to be sufficiently random to use either a secure random number generation algorithm or a true random number generator. Token should be a ‘secret’ that is held jointly by the user and the server and cannot be known by any third party. In practical applications, tokens can be stored in the user’s Session, cookie, and localstorage. Because of the existence of tokens, attackers cannot carry out CSRF attacks after constructing a completed URL. The token needs to be stored in both the form and Session. When submitting a request, the server only needs to verify whether the token in the form is consistent with the token in the user Session. If so, the request is considered valid. If inconsistent, or one is empty, the request is considered illegal and a CSRF may have occurred.
The token to defend against CSRF is designed according to the principle of unpredictability. Therefore, the token generation must be random enough and a secure random number generator must be used to generate the token. Tokens are not intended to prevent double submissions. So for ease of use, it is possible to allow the same token to be used throughout the lifetime of a user until it is consumed. But if the user has already submitted the form, the token has been consumed and a new token should be generated again.
When using tokens, attention should be paid to the confidentiality of tokens. If tokens appear in the URL of a page, they may be disclosed by means of Referer. When using tokens, you should try to put them in a form and change get to POST to avoid token disclosure.
CSRF’s token is only used against CSRF attacks, and this scheme becomes ineffective when a site also has XSS vulnerabilities, because XSS can simulate arbitrary actions of a client’s browser. Under XSS attack, an attacker can request a page, read the token value of the page content, and then construct a legitimate request. This process is called XSRF and will not be explained here.
Gentlemen, shame on you!!