Attack Afternoon – CSRF Countermeasures #1
The last post of this series presented one of the most important attacks on web applications: “Cross-Site Request Forgery” (CSRF).
Short repetition of the CSRF attack vector: If a web application identifies users via session cookies, it is the user’s browser who takes care that these are attached to every HTTP request while the user is logged in to the application. An attacker can now try to send requests to this web application, for instance if he lures the user into visiting a manipulated web site. A web application that is susceptible to CSRF will only check if the session cookie (which automatically gets attached by the user’s browser) is valid. In this case it executes the attacker-triggered action in the context of the user’s session without the user being aware of it. So in general, all web applications that manage session state via cookies face the threat of being vulnerable to CSRF and need to implement protection measures against this attack vector.
One possibility to prevent CSRF is the usage of an anti-CSRF token. The application generates a (cryptographic) random value which is long enough for every session. This value is written into a hidden form field within the HTML page, for instance. As a consequence, this token is only sent back to the server if the user submits this HTML form. The token is not attached by the browser automatically (as is the case for cookies). Whenever the application receives a form submit, it also receives the hidden form field containing the anti-CSRF token and checks whether it is identical with the value stored for the respective user session.
If an attacker tries to perform a CSRF attack now he can of course still issue HTTP requests with arbitrary content and the browser will still attach the user’s session cookie. But the attacker cannot guess the anti-CSRF token connected to the user session because this token only exists on the HTML page in the user’s browser (to which the attacker has no access). The application will reject such a request and does not execute any action triggered by the attacker.
Luckily, many web application frameworks provide standard functionality for generating, storing and validating such tokens. However, it is important that this functionality is active and configured correctly throughout the entire application.
Another countermeasure is presented in one of our next Attack Afternoons. Stay tuned!
Do you already have a CSRF protection and want to have it checked? Please feel free to contact us!
mgm sp @ Heise DevSec
With the topic “How practical is DevSecOps really? – A field report” our colleague Maximiliane Zirm is present at this year’s Heise devSec.
Pentest FAQ – #7 and #8 – What is a penetration test? And what is it not?
In our Big Application Security Penetration Test FAQ for clients we answer everything you should know before, during and after the commissioning of an Application Security Penetration Test.
In focus today: : Questions #7 and #8 – What is a penetration test? And what is it not?
The Big Application Security Penetration Testing FAQ for Clients
Have you ever wondered what a pentest is exactly or how such a test works? Our Big Application Security Penetration Test FAQ for clients answers these questions and much more.
Tool Tuesday – nmap
One tool which should be installed on every pentester PC is nmap. This command line tool is the Swiss army knive for penetration tests on network level, but also used regularly by system administrators.
mgm sp @ Munich
Our head office is located in the heart of Bavaria, since the time of SecureNet. Come have a look!