Attack Afternoon – CSRF
CSRF stands for “Cross-Site Request Forgery” and is a classic among web application attacks. With this attack, it is possible to perform certain user actions without them noticing it. But how exactly does this attack work?
Let’s start from the beginning: Most applications identify a user via session cookies. Cookies are suitable because they are stored in the user’s browser after being set. Furthermore, the browser automatically sends the respective cookies with all following HTTP requests. However, whether the HTTP request is sent by the actual application or by a third party does not matter for the browser when cookies are transmitted.
This means that an HTTP request that comes from a user’s browser is by no means an HTTP request that is deliberately executed by the user. Every page that a user surfs to can send an HTTP request to any destination in the background via the user’s browser. For example, the website on which you are viewing holiday pictures could secretly send an HTTP request that triggers a transfer to your online banking application if that application is vulnerable to CSRF. To do this, an attacker, the mastermind behind the alleged holiday picture website, must forge the HTTP request for this transfer and send it cross-site to the online banking application – Cross-Site Request Forgery -. If you are currently logged on to the online banking application, your cookies are automatically sent along by the browser and you are identified as a customer. The transfer then goes through – under your name.
Learn in one of our next Attack Afternoons how you can effectively protect yourself against CSRF. Stay tuned!
Do you already have a CSRF protection and want to have it checked? Please feel free to contact us!
How can you actively prevent usernames from being enumerated on WordPress author pages?
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 #18 and #19 – How are vulnerabilities found evaluated? And what is the CVSS?
CSRF Countermeasures #2: Another way to protect against CSRF – stateless – is the Double Submit Cookie method.
The NinjaDVA is our comfortable and flexible training environment.
Is your web application vulnerable to SQL Injection? With sqlmap you can test it.