CSRF (Cross Site Request Forgery)
A CSRF attack forces a logged-on victim’s browser to send a request to a vulnerable web application, which then performs the chosen action on behalf of the victim.
The following tests are based on an application for fund transfer. The authenticated and authorized user is provided with an interface where he can transfer funds from one account to another account.
This test can be similarly applied to similar applications with functions identified as critical in the application context such as above, publishing application content thru a CMS, or change password etc.
The attack is possible in the following scenario (Tested).
1. The user has opened his mail from the browser window where he already opened his Fund Transfer application in a separate tab as shown in the snapshot above. This is seen in IE 7.0.
2. In case of IE 6, the user needs to create another instance of the browser by selecting File-> New->Window.
3. In case the application is opened in one browser window and only one browser is open and the link is clicked from a mail viewed with Outlook Express.
In each of the above scenarios the same browser cookie is shared/used between the different instances of the browser.
How to test:
1. User logged in using his credential as shown below snapshot
This is where the user gives the valid account numbers to transfer fund amount.
3. Now, while the genuine user is logged on to the above application and holds a valid session, a user with malicious intent launches the CSRF attack.
An examination of the source code of the above interface shows the following:
The following tests are based on an application for fund transfer. The authenticated and authorized user is provided with an interface where he can transfer funds from one account to another account.
This test can be similarly applied to similar applications with functions identified as critical in the application context such as above, publishing application content thru a CMS, or change password etc.
The attack is possible in the following scenario (Tested).
1. The user has opened his mail from the browser window where he already opened his Fund Transfer application in a separate tab as shown in the snapshot above. This is seen in IE 7.0.
2. In case of IE 6, the user needs to create another instance of the browser by selecting File-> New->Window.
3. In case the application is opened in one browser window and only one browser is open and the link is clicked from a mail viewed with Outlook Express.
In each of the above scenarios the same browser cookie is shared/used between the different instances of the browser.
How to test:
1. User logged in using his credential as shown below snapshot
2. By clicking on “Login” user gets the following response page
When the victim clicks on “Transfer”, following request is sent to the server ( the request is sent via a HTTP interceptor. The interceptor is used for examination of the traffic as it goes from the client to server and vice versa).
As observed above, the user sends the following valid cookies to access all the application functionalities
Interface for fund transfer.
This is where the user gives the valid account numbers to transfer fund amount.
3. Now, while the genuine user is logged on to the above application and holds a valid session, a user with malicious intent launches the CSRF attack.
An examination of the source code of the above interface shows the following:
As seen above, thanq.asp is the handling program for the transfer form. Note the field names. ( The attacker needs to have studied the above code earlier to launch the attack).4. The attacker creates the following html source code file. This code submits the following form fields and their values to the thanq.asp program on the hosting server to transfer an amount of 1000 from Ac: 20048 to Ac: 20320.
5. Malicious user sends this html file as a link to the victim through the mail or bulletin board etc
6. Now the victim is lured by the attacker to navigate to the URL http://members.lycos.co.uk/srilatha/link2.html in another instance of the browser ( a browser tab in IE7)
User clicked on “Click here”
From the above snapshot user can observe that http://memebers.lycos.co.uk/srilatha/link2.hmtl has been redirect to the http://members.lycos.co.uk/srilatha/attack1.asp URL. This is the URL where the malicious user hosted the html page (created above in step 4) which is used for CSRF attack.
7. On interception and examination of the above HTTP requests it was found that a request is being transmitted to http://164.100.28.70/csrf/thanq.asp server.
7. On interception and examination of the above HTTP requests it was found that a request is being transmitted to http://164.100.28.70/csrf/thanq.asp server.
Along with the POST request the cookie details of the logged-in user and the details of the transaction is automatically transmitted to the http://164.100.28.70/csrf/thanq.asp server.Note the cookie above. This is the same as seen earlier in step2.
8. By forwarding the above request user gets the following response page
8. By forwarding the above request user gets the following response page
( The displayed strings server side cookie values are displayed for debugging purpose.)The message above shows that Rs. 1000 transferred from Account Number 20048 to Account number : 20320.This shows successful transaction from the account number 20048 to 20320.This was as per the html source code in step 4.From the Step#2 and Step#7 user can observe the cookie values which were passed to the server are same. Session value of the logged in user is being shared by another instance of the same browser so that attacker can perform the actions on behalf of the logged in user (Victim).
Comments
Post a Comment