For my first -real- blog post, I chose to analyse a common vulnerability found in many web applications; the Cross Site Request Forgery (CSRF) attack.
Overview
CSRF? Gime the big picture!
CSRF is rated among the 10 most critical web application security flaws in
OWASP's Top 10 project. In simple words, CSRF vulnerabilities occur when the web application cannot distinguish legitimate requests from forged requests. In simple words, a user can perform actions in his account without his explicit permission and consent.
In the following picture you can see how a CSRF attack is performed, in a simple graphic:
Step 1: Mallory sends a phishing email to Bob, inviting him to visit her web server in order, for example, to win an iPhone 5. She has already created a web page at her web server with a hidden request to the Web Application where Bob is logged in. She has added some buttons to lure the victim in order to click on her page and win the iPhone!
Step 2: Bob visits the page at Mallory's Web server. Maybe he is greedy or he may not, however he clicks on the button in order to win the iPhone!...
Step 3: The forged request is "legitimized" with Bob's logged-in session and is executed at the web application.
A real-world analogy would be the following: Mallory presented a bank cheque to Bob and Bob puts under his name and signature, but haven't examined what sum of money is written on the cheque.
In the following attack scenario, we can see how a malicious user can add a user to a web application just by fooling a logged-in administrator to click on a link.
Attack Scenario
Ok. And how's that done?...
For my demo I choose multidae vulnerable web application which can be found on
OWASP's Vulnerable Apps VM, an intercepting proxy tool (I used
Portswigger's Burp Proxy, however it is not essential, just a "View Source" from any browser can work on most cases) and an Apache web server.
In the following picture you can see the main page of Multidae's web application as it can be browsed by any -non authenticated- user.
In this web application any user can register an account, but our goal is to register the account with the administrator's privileges!
Below is the "register user" page that any, unauthenticated user can see.
If we view the source of the "Register Account" page, we can identify the forms (and therefore the POST request) that are being sent to the web application. That data are then processed by the application and the user is created.
Now, the attacker can create his own form at his web server and populates the HTML fields with the data of the user he wants to create on the system. (Note: no code expertise is needed in order to create this HTML page!)
In the following picture, you can see the HTML page that creates on his web server. He creates a user named "andrew", with password "qwerty".
Now he launches the web server (192.168.200.14) hosting this page. At this point, he needs the user's interaction. This could be accomplished, for example, by a phishing attack scenario: the victim receives an email inviting the victim to visit the attacker's page saying "click here to win an iPhone 5", or he could attach this message this "iPhone 5 message" at the page he created!
Just imagine:
And this is how it will appear on the victim's web browser:
The victim, which is at the same time logged in with this account at Multidae web application, is now tricked to click on the button and submit a register user form with the username and password set by the attacker.
User "andrew" can log in with the password set during the CSRF request.
Impact
And what I am supposed to lose?
CSRF vulnerabilities affect the Application Business Logic and the Session Management of a web application. We can understand this in the following -in purpose- trivial scenario in order to understand the nature of the impact.
Let's assume we have an ebanking web application that needs two steps to perform a bank transfer; the first one is the details of the transfer and the second one is confirmation. Now, imagine an attacker who is logged in on his account, and reaches the second step (confirmation), but with receiver of the bank transfer himself, and sender of the bank transfer the victim. What if he could create such a request, host it on his web server and trick the victim click on it? The victim's bank account would be charged the amount defined by the attacker, and sent to the victim's bank account! With this trivial scenario, we can see how Application Business Logic can be bypassed.
The attacker, upon a successful exploitation of a CSRF attack can achieve elevation of privileges with significant business impact and reputation loss to the organization hosting the web application.
Am I vulnerable to CSRF?
I am safe?
Web applications are vulnerable to CSRF attacks if their requests are not "unique" or "pegged" to one user's session. Remember, in the overview section I mentioned that: "CSRF vulnerabilities occur when the web application cannot distinguish legitimate requests from forged requests". Therefore, we can question ourselves if each request is made "unique" through our session. In most web applications, browsers tend to include any authentication token (e.g. sessionid) while sending the requests associated with the web application.
As a second step, we can examine our web application by using a proxy tool and by scrutinizing every request sent to the web application. Furthermore, web developer firefox add-on offers numerous capabilities to inspect and alter forms and cookies interchanged between the web server and the web application.
Prevention Techniques
Protection! NOW!
In order to prevent CSRF attacks to our web application, we should deploy technologies that would differentiate legitimate from forged requests.
According to this mentality, we should deploy a mechanism that would make unique every session initiated by the user. This can be achieved by sending the browser an anti-CSRF token that would be appended in every request the browser sends to the server. The above technique is being explained in more technical terms in
OWASP's CSRF Prevention cheat sheet:
"These challenge tokens are the inserted within the HTML forms and links associated with sensitive server-side operations. When the user wishes to invoke these sensitive operations, the HTTP request should include this challenge token. It is then the responsibility of the server application to verify the existence and correctness of this token. By including a challenge token with each request, the developer has a strong control to verify that the user actually intended to submit the desired requests. Inclusion of a required security token in HTTP requests associated with sensitive business functions helps mitigate CSRF attacks as successful exploitation assumes the attacker knows the randomly generated token for the target victim's session. This is analogous to the attacker being able to guess the target victim's session identifier."
In the web there are numerous references regarding the implementation of anti-CSRF tokens.
Few examples:
Using View State to prevent CSRF attacks (example
here)
-
-
-
- Anti CSRF for Joomla!
Conclusion
As you have seen, patching existing code or creating non-vulnerable code can be really time consuming. Nevertheless, CSRF attacks can cause serious business impact if successfully deployed. That's why it is imperative to guard our web applications against CSRF attacks.
References
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
