White Hat Institute

Cross-site request forgery

Cross-site request forgery is an assault vector that fools an internet browser into executing an undesirable activity in an application to which a client is signed in. An effective CSRF assault can be devastating for both the business and the client. It can result in damaged customer relationships, password changes, unapproved finance transfers, and information theft — including taken session cookies. 

CSRFs are usually directed utilizing vindictive social engineering, for example, an email or connection that fools the target into sending a forged solicitation to a server. As their application confirms the clueless client at the time of the assault, it’s difficult to recognize a real solicitation from a forged one.

Let’s take a look at a few examples and perform some CSRF attacks.

CSRF — change password

For this example, we will be using an “OWASP-BWA” web server and targeting the “bWAPP” database. Login to the site with the default username and password, and select the “Cross-Site Request Forgery (Change Password)” option to start hacking. From the “Change your password” page, type a new password, and click on the “Change” button.

Cross-site request forgery

Right-click on the page and select the “View Page Source” option from the drop-down menu.

Cross site request forgery 2

Copy the whole part of the HTML code that starts with (<div id=“main”>).

Cross site request forgery 3

Open up any text editor and paste the copied HTML code.

Ex: ([email protected]:~# nano csrf.html).

Before saving it, we need to do a small configuration on the (<from action=/bWAPP/csrf_1.php” method=“GET”>) line and provide a full path to the page.

Ex: (<from action=“http:10.10.10.6/bWAPP/csrf_1.php” method=“GET”>).

Cross site request forgery 4

Now, our “.html” file is ready and can be executed from any computer. Double-click on the file, and it should load the “CSRF (Change Password)” page.

Cross site request forgery 5

Type any password and click on the “Change” button.

Cross site request forgery 6

It will allow you to access the page as the previously authenticated user and have full privileges.

Cross site request forgery 7

CSRF — transfer amount

In this example, we will show you how to perform a fraud money transaction on CSRF vulnerable website. For this purpose, we will use the same bWAPP database.

From the “Choose your bug” section, select the “Cross-Site Request Forgery (Transfer Amount)” option and click on the “Hack” button to start compromising. Next, specify the amount you want to transfer and click the “Transfer” button.

Cross site request forgery 8

Right-click on the page and select the “View Page Source” option from the drop-down menu. Copy the whole part of the HTML code that starts with (<div id=“main”>).

Cross site request forgery 9

Open up any text editor and paste the copied HTML code.

Ex: ([email protected]:~# nano csrf2.html).

Before saving it, we need to do some configuration on (<from action=/bWAPP/csrf_2.php” method=“GET”>) line and provide a full path to the page.

Ex: (<from action=“http:10.10.10.6/bWAPP/csrf_2.php” method=“GET”>).

We can also change the value of the account number and the amount of the transaction.

Cross site request forgery 10

Now, our “.html” file is ready and can be executed from any computer. Double-click on the file, and it should load the “CSRF (Transfer Amount)” page.

Cross site request forgery 11

The page will display an altered account number and the transaction amount.

Cross site request forgery 12

Click on the “Transfer” button to complete the money transfer and access the page as the previously authenticated user.

Cross site request forgery 13

The fact that a user is authenticated to a specific site is used in CSRF attacks.

Only an authenticated user should have access to any feature that is useful to an attacker. Otherwise, the intruder might actually go to the site and carry out the desired actions. Cookies lengthen user sessions, making a site more accessible but also making it more vulnerable to CSRF attacks. 

Allowing most passive functionality on a web (such as displaying account balances) without authentication, but requiring re-authentication or some user interaction for active functionality, would be a good combination of usability and protection (like performing a bank transfer). Since a CSRF attacker never sees the CSRF response, they are unable to take this next step, even though it is simply pressing the “are you sure?” button.