This document will guide you to exploit the CSRF (Cross Site Request Forgery) vulnerability step by step wherein an attacker can launch the CSRF attack against the valid application user and update the details. It will also give an idea to mitigate these risks under the recommendations section.
Since this was a real-time attack on the leading healthcare domain web application, I have blurred the actual URLs.
The objective of this article is to help the Security Analyst/Penetration Testers/Developers/Ethical Hackers to understand the exploitation of CSRF vulnerabilities and mitigate the same.
A Cross Site Request Forgery (CSRF) attack forces a logged-in victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim.
Prerequisites of the attack:
The victim is logged in to the application.
The victim clicks on the URL sent by an attacker.
This vulnerability presents a High Risk to the application since an attacker can perform unauthorized actions on behalf of the victim.
CSRF attacks take advantage of the cookie sharing between two instances of the same browser. The cookie is a small text file, which stores the session ID on the client side.
This means that if a user is logged in from one instance of a browser (say Mozilla Firefox), he can successfully access restricted pages and their functionality from another instance of Mozilla Firefox.
This occurs because the two instances of Mozilla Firefox browser are designed to share cookies, which store session IDs.
An application user logs in to the application and browses to the internal page at the URL (after authentication): http://www.xxx.com/recept/mina-sidor/mina-installningar/
His session ID, for our reference, can be seen by capturing a request in a proxy (Burp Proxy)
Step 3 Simultaneously the user is checking his email in another instance of the browser. He receives an interesting email and is drawn into clicking on the link in
The user clicks on the link encircled above and a new page is opened with an image as shown below:
The user returns to the browser in which he browses the application. He refreshes the page and observes that the details have been updated without his knowledge, as encircled below:
The source of the link was a post request for updating the ‘settings of the user’ as shown in the figure below.
The page ‘efgh.html’ in the first frame containing an image is visible in the browser window while the page ‘csrf.html’ in the second frame is not visible because of the frame dimensions. However, the page does load and it does submit the malicious request to the application. The following is the malicious ‘csrf.html’ page:
For our reference, the trapped HTTP post request for updating the settings sent from the ‘csrf.html’ page in the background is the following. Notice that the session sent in this request is the valid session ID of the logged in user:
Recommendation: Here the problem is that only the session cookie is used to validate all transactions after authentication. The application should implement the following techniques to prevent the CSRF attack:>
Insert custom random tokens into every form and URL – these tokens will not be shared across different tabs of the same browser accessing the same host page.
<Form action=”FundTransfer.aspx” method=”POST”>
<Input type = “hidden” name=”87987896″ value=”435654785766398″>
These tokens can be unique for the entire session or can be unique to that particular function or page for that user.
Validate the submitted token at the server end.
If the request doesn’t contain the token or if the submitted token is incorrect, don’t address the request.