Common mistakes when protecting sites from CSRF attacks

Currently, a very interesting situation has arisen in the field of security of websites and applications: on the one hand, some developers pay special attention to security, on the other hand, they completely forget about some types of attacks and do not consider errors that allow these attacks to execute vulnerabilities. For example, CSRF (Cross Site Request Forgery) can be attributed to this category. This attack allows you to perform various actions on a vulnerable site on behalf of an authorized user. If you have not heard of this, then I recommend reading the relevant Wikipedia article to get a general idea of ​​this type of attack. The main part of the article is intended for those who are concerned about the proper protection of their sites from CSRF.


Note 1: formally, CSRF is an attack, not a vulnerability, like XSS. The vulnerability is improper handling of input data, and CSRF uses this.
Note 2: if any errors seemed obvious to you and are not worth mentioning, then I am happy for you. However, this material is based on the real vulnerabilities of large sites, and each item shows an error of a development team that turned into a security hole.
')

List of errors:

1) There is no protection against CSRF.

From my own experience I can say that at present this is the most common mistake. It can be found both on obscure blogs and on large projects. The only good reason not to use protection against this type of attack is that the site does not store any user data, and you do not use the admin panel to edit materials.

2) Not all requests are protected.

I would put this error in second place. On many sites where any protection against CSRF is implemented, vulnerable queries can be found. For example, if you use the Habr search habrahabr.ru/search/?q=CSRF , you will see a significant number of articles telling about vulnerabilities found on those services where there is protection.
You must protect absolutely all requests that change anything on the site. You have added a token in the form of changing the email address, and the attacker will not be able to seize the account of your user, changing the mail on his behalf, and then the password? Great. That's just such a measure is useless if you can just send a request for the transfer of money from the victim's account to the attacker's wallet, bypassing your protection.
Convenience security is one of the reasons to use only the POST method for requests that change user data. If you follow this advice, you just need to make sure that all POST requests contain a reliable and correct token. This will be discussed below.

3) Use to protect against CSRF anything other than tokens.

It would seem very convenient to use HTTP referer (https://ru.wikipedia.org/wiki/HTTP_referer) to protect against attacks. If the title is not a page from your domain, then the request was forged. But not everything is so rosy. A small part of HTTP referer users may be empty for various reasons. In addition, it can be tampered with using old versions of Flash, which puts at risk those who have not updated anything on their computer for a very long time.

How about using captcha? I heard a fairly large number of questions from the developers about the possibility of using them to protect against attacks. My definitive answer is no. First, you obviously will not force the user to enter a captcha for every sneeze: this will lead to error number 2. Secondly, not all methods of implementing captcha will provide you with adequate protection that an attacker cannot bypass. Since this topic is very controversial and relevant, in the future I will devote a separate article to it.

To protect against CSRF, you must use anti-CSRF tokens and only them. Only they provide proper protection for your sites. In general, the mechanism of tokens is described in Wikipedia:

Another common method of protection is the mechanism by which an additional secret key is associated with each user session, which is intended to fulfill requests. The user sends this key among the parameters of each request, and the server checks this key before performing any actions. The advantage of this mechanism, compared to the Referer check, is the guaranteed protection against attacks of this type. The disadvantages are: requirements for the ability to organize user sessions and dynamically generate the HTML code of the active pages of the site.

4) No verification of anti-CSRF token when processing the request.

I encountered a similar error on the websites of very serious companies whose security should be at their best.
There is a token in the request itself, but it is not checked during its processing. You can insert any string in this field, the request will still be processed correctly. There is nothing special to comment on, you just need to indicate that using the isset () function php.net/manual/ru/function.isset.php to verify the token is completely unacceptable.

5) Partial check of anti-CSRF token.

I met this error at once on several large sites of the RuNet in different variations. For example, one of the sites used tokens of the form "User_Name. Current_Time.Long_Spouse_Number". In this case, only the correspondence of the username in the token and the login of the person on whose behalf the request was sent was checked. This complicates the attack a little, but does not make it impossible.

6) Ability to use one token for different users.

I met this error once, but on a fairly large site, so I consider it necessary to mention it. An attacker could register a new account on the site, copy the token from the source code of the page and use it for CSRF. Do not make such an error, as it completely destroys all the advantages of tokens on your site.

7) Insufficient length of the token.

Your token should be so long that an attacker spends at least as much time on selecting him as he does on selecting a user password. I have seen tokens of 2 characters, they will not help much if someone really wants to make a CSRF attack.

8) Predictable tokens.

When designing the token generation algorithm, be sure to use random data in the token (the advice is relevant if you are developing the entire system from scratch. If you use a framework or CMS, you must rely on their developers). Believe me, the “md5 (user_id)” token is a very bad idea.

9) Lack of tokens in the admin panel or system for technical support staff.

Even if the entire site accessible to your users is protected from CSRF, then you should not forget about the admin panel. In one narrowly known billing system, there was a lot of CSRF in the admin panel (although they were in the public part of the system, but this is not so important). And anyone who knew the query structure could use a CSRF attack on a tech support employee and get access to the data of all clients of the company using this billing system. The only problem is the need to find out the structure of requests: for this you can use social engineering, download a copy from open sources, or just hack a less secure site using the same system.

10) Transfer of tokens in open form, especially in GET requests.

On several sites I saw situations when users' tokens were transmitted in open form: if the token is contained in the page address, the user can copy the entire link and place it somewhere, without even knowing about the danger. You do not need to worry much about the hidden transfer of tokens only when they are disposable, and the user can accidentally reveal only the used token. However, this is still not very good, as it signals some problems with the architecture of the application: for example, you use GET, and not POST for requests that modify user data.

The presence of these errors even on large and serious sites shows that the problem of protection against CSRF attacks is quite acute. Of course, this list is not exhaustive. I am sure that you can find a few more errors and ways to exploit them. However, if you check your sites for the problems described in this article and fix them, you will significantly increase the security of the project.