Common mistakes in protecting sites from CSRF attacks
Currently, a very interesting situation has arisen in the field of website and application security: 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 be performed as 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 corresponding Wikipedia article to have 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 input processing, and CSRF uses this.
Note 2: if any errors seemed obvious to you and not worthy of mention, 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) Completely no protection against CSRF.
From my own experience I can say that this is currently the most common mistake. It can be found both on low-visited 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 in prevalence. On many sites where some kind of 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 the vulnerabilities found on those services where there is protection.
You must protect absolutely all requests that change anything on the site. You added a token to the email address change form, and the attacker will not be able to take possession of your user’s account by changing the email and then the password on his behalf? Wow. That's just such a measure is useless if you can simply send a request to transfer money from the victim's account to the attacker's wallet, bypassing your defense.
Convenience of security is one of the reasons to use only the POST method for requests that modify 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) Using anything other than tokens to protect against CSRF.
It would seem very convenient to use an HTTP referer (https://ru.wikipedia.org/wiki/HTTP_referer) to protect against attacks. If this header does not contain pages from your domain, then the request has been tampered with. But not everything is so rosy. For a small fraction of HTTP users, the referer may be empty for various reasons. In addition, it can be faked using older 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 have heard quite a lot of questions from developers about the possibility of using them to protect against attacks. My definite answer is no. Firstly, you will not explicitly force the user to enter captcha for each sneeze: this will lead to error No. 2. Secondly, far from all ways to implement captcha will provide you with proper protection that an attacker cannot get around. Since this topic is very controversial and relevant, in the future I will devote a separate article to it.
To protect against CSRF you should use anti-CSRF tokens and only them. Only they provide proper protection for your sites. In general, the token mechanism is described on Wikipedia:
Another common method of protection is a mechanism in which an additional secret key is assigned to each user session for executing requests. The user sends this key among the parameters of each request, and before performing any actions, the server checks this key. The advantage of this mechanism, in comparison with the Referer check, is the guaranteed protection against attacks of this type. The disadvantages are: requirements for the possibility of organizing user sessions and the dynamic generation of HTML-code of the active pages of the site.
4) Lack of anti-CSRF token verification during request processing.
I met a similar error on the websites of very serious companies, whose safety should be on top.
There is a token in the request itself, but it is not checked during its processing. You can insert any line into this field, the request will still be processed correctly. There is especially nothing to comment here, you just need to indicate that using the isset () function php.net/manual/ru/function.isset.php to check the token is completely unacceptable.
5) Partial check of anti-CSRF token.
I met this error at once on several large sites of a Runet in different variations. For example, one of the sites used tokens of the form "User_name. Current_time. Long_random_number". In this case, only the correspondence of the username in the token and the login of the one on whose behalf the request was sent was checked. This complicates the attack a little, but does not make it impossible.
6) The 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 a mistake, as it completely destroys all the advantages of tokens on your site.
7) Insufficient token length.
Your token should be so long that the attacker spends at least the same amount of time on his selection as on the user's password. I met tokens of 2 characters, they will not help much if someone really wants to carry out a CSRF attack.
8) Predictable tokens.
When developing a 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. In the case of using a framework or CMS, you should rely on their developers). Believe me, a token like “md5 (user_id)” is a very bad idea.
9) Lack of tokens in the admin panel or system for technical support employees.
Even if the entire site available to your users is protected from CSRF, then do not forget about the admin panel. In one known in narrow circles billing system, there were a lot of CSRFs in the admin panel (although they were also in the public part of the system, but this is not so important). And anyone who knew the structure of requests could use a CSRF attack on a technical support employee and gain access to the data of all customers of the company using this billing system. The only problem is you need to know the structure of the requests: for this you can use social engineering, download a copy in open sources or just hack a less secure site using the same system.
10) Transfer of tokens in clear form, especially in GET requests.
On several sites, I saw situations when user tokens were transmitted in clear form: if the token is contained in the page address, then 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 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 application architecture: 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 how to use them. However, if you check your sites for the problems described in this article and fix them, then significantly increase the security of the project.