Cross-Site Request Forgery (CSRF) Cheat Sheet, Attack Examples & Protection
Cross-Site Request Forgery (CSRF), also known as Session Riding and XSRF, is a common application-layer vulnerability that allows the malicious attacker to use an active session of the victim to perform actions on his behalf without his prior knowledge or consent. CSRF incidents are hard to detect as they are disguised into normal user requests.
A regular starrer in the OWASP Top-10, CSRF attacks are fast gaining popularity in hacking circles. As per the Seperfecta (The top-4 types of cyberattacks executed today – SQL Injection, Cross-site Scripting, Directory Traversal and Cross-site Request Forgery) report released by FireHost, CSRF attacks almost doubled from Q1 of 2012 to the Q1 of 2013.
What is a CSRF attack?
CSRF attacks manipulate the inability of the web applications to authenticate user access. These attacks typically take shape in the following manner:
- The victim first logs on to the CSRF vulnerable web application, which then initiates the session and creates a unique ID for him. He is then free to interact with the server and perform data modifying tasks.
- The hacker uses social engineering techniques (unsolicited emails with HTML content, malware planted on popular webpages, etc) to make the victim click on malicious URLs containing legal commands for the targeted web application.
- Once the malicious URL is clicked, the web application assumes the commands are coming from the victim and performs them.
How do CSRF attacks look in real life?
As mentioned above, CSRF attacks can be executed exclusively or in tandem with other techniques. But they are most commonly initiated with the help of social engineering.
Web applications enable changes to their databases when they receive commands from the browsers, also called “task URLs”. Once a server is contacted, the user gets a unique session ID. This session ID enables the web application to recognize the input source. It then allows access to its databases. CSRF attacks manipulate this very authentication system.
Malicious attackers create contaminated “task URLs” and push them out using various social engineering techniques. Once clicked, the victim’s browser generates unauthorized requests while riding on the same session ID acquired earlier.
CSRF attack examples
The victim enters his banking web application (www.mybank.com) and initiates a session. He is given a unique session ID and the interaction with the server is launched.
The malicious attacker creates a URL with a CSRF payload with the intent of stealing $1000 from the victim’s bank account. This malicious URL is pushed to the victim via the various social engineering techniques. The contaminated URL can look like:
<iframe src="http://mybank.com/app/transferAmount?amount=1000&destinationAccount=... >
The loading of the iframe sends the request to mybank.com, while riding the session the victim is already logged on to. The stolen $1000 is sent to the account specified by the hacker.
The risks of CSRF attacks
- Impersonation and identity riding.
- Modification of application data with the victim’s credentials and permissions.
- Posting content on behalf of the victim without his consent or prior knowledge.
- Launching of organized attacks against all of the application’s users.
- Exploitation of vulnerable DSL routers.
Besides the aforementioned dangers the CSRF vulnerability, it can also help initiate other types of attacks. For example, a Cross-Site Scripting (XSS) initiated CSRF attack is a potent hacking method that can cause colossal damage to organizations and private users alike.
How to prevent CSRF attacks?
Besides using the Checkmarx solution that provides a comprehensive solution, security officers and developers must make a habit of taking the following security measures:
- Unique CSRF tokens – The user should get a random CSRF token every time he logs into the web application. In all subsequent requests, this token should be passed and validated in the server. This effectively cripples the malicious URLs as they cannot be authenticated by the server, which checks for the unique CSRF tokens.
- Tokens per request – The aforementioned CSRF tokens are usually given out per session, but can be given out for each request separately for added protection.
- Timing out sessions – Making sure the session times out after a short period of time reduces the time-frame that the victim has to perform the attack.
Preventing CSRF attacks with CxSAST
CxSAST helps eradicate CSRF vulnerabilities by scanning the source code and identifying sensitive junctions where the application can be compromised. All the developer has to do is insert appropriate anti-CSRF solutions in the vulnerable junctions located by Checkmarx’s scanner. CxSAST comes with built-in CSRF queries for out-of-the-box CSRF detection.