Question 1. What is Cross-Site Request Forgery?

Question 2. What's the difference between Cross-Site Scripting and Cross-Site Request Forgery?

Question 3. How to prevent Cross-Site Request Forgery?

1. What is Cross-Site Request Forgery

2. Some examples of Cross-Site Request Forgery

3. Prevention of Cross-Site Request Forgery

Cross-Site Request Forgery, short for CSRF, refers to that on the website where user logged in, impersonate the user's identify, and execute some operations automatically act as the user.

Using Cross-Site Request Forgery, the attacker doesn't need to get the user's cookie or the user's identify, but to use the web brower of the user himself to do fake operations autimatically.

For example, add friends code of a forum is as following:

 

<form action=“addfriend.php” method=“get”>

    Username to add as friend: <input type=“text” name=“username” />

</form>

 

Then, we send a message within the forum as following:

 

<img src=“addfriend.php?username=username_of_attacker” />

 

When the user views the message in the forum, he added the attacker as friend automatically.

We changed the method of add friends to POST:

 

<form action=“addfriend.php” method=“post”>

    Username to add as friend: <input type=“text” name=“username” />

</form>

 

This time, the attacker cannot simply send “addfriend.php?username_of_attacker” to perform the attack, for the attacker method is GET, but we changed our code to POST.

 

But, the attacker can still use JavaScript to perform the attack, such as send the following code to the user:

 

<form id=“addform” action=“addfriend.php” method=“post”>

<input type=“hidden” name=“username” value=“username_of_attacker” />

</form>

<script>addform.submit();</script>

 

When user visits this code, it will automatically post the add friend request to the server.

For example, the delete post code of a forum is as following:

 

<a href=“tipsdel.php?tipId=123”>Delete the post</a>

 

Simily as above, we can send an attack message to the user within the forum, to delete the user's posts automatically.

 

<img src=“tipsdel.php?tipId=123” />

When user views the message within the forum, it requests "tipsdel.php" automatically, and delete the user's post automatically.

Especially, when the user is the administrator of the forum, the attacker may delete all the posts of the forum using this attack method.

As with the previous approach, even if we change the deletion of posts to accept POST only, there is currently no protect methods against this attack.

In this way, as long as the user is logged in to the website, if there is no prevention, the attacker can use similar simple ways to automatically perform various operations such as adding users, deleting posts, sending emails, etc., which should only be performed after the user has confirmed himself.

Difficulty 1. The attack is preformed by the legal logged in user, with the browser of the user himself. The attacker needn't to know any information of the user, and the attacker doesn't need to preform any attack operations. The attack is executed automatically, without the user's knowledge. So it's difficult to prevent.

Difficulty 2. We cannot use the same way as prevention Cross-Site Scripting attack, which is filter user's input contents, to prevent Cross-Site Request Forgery. As of the previous example, filter of within forum message is invalid to prevent the attack.

For example, the attacker can send such message to the user within the forum:

Click the following link: http://website_of_attacker/crack.html. If the link cannot be click, please copy the link, open a new browser window, and paste the link.

Thus the attacker can move the attack code to his website. When the user open the attacker's web site, the attack is preformed automatically. We cannot do any filter to the attacker's website. And the user opened a new browser window without close the previous original website window, so the identify of the user is still exists in the browser, so the attacker can preform the attack.

At the server, in the handler of addfriend.php and tipsdel.php, we should check original website of the user's request. That is, to check whether $_SERVER[“HTTP_REFERER”] is the same as our website at the beginning of the php files. If not, we should stop execute following codes to handle user's request to add friends and delete posts. This may avoid attack from the attacker's website to some extent.

But, $_SERVER[“HTTP_REFERER”] may be fake too. And in some situations, the browser may not send $_SERVER[“HTTP_REFERER”] to the server. So we cannot rely on this way only.

For example, to add a friend using GET method, we change the code as following:

 

<form action=“addfriend.php” method=“get”>

    Username to add as friend:<input type=“text” name=“username” />

    <input type=“hidden” name=“token” value=“123” />

</form>

In this example, the token is generated by the server and saved to session. Each time the user add friend, the tokens are different. When then addfriend.php handles the add friend request, it will check whether $_GET[“token”] and $_SESSION[“token”] is equal, if not, it will stop to handle the add friend request.

For the token is regenerated each time, and is different each time, the attacker don't know what the token is, so he cannot send an automatically attack code to the user.

For example, if the attacker send the following code to the user:

 

<img src=“addfriend.php?username=username_of_attacker”&token=123” />

 

For the token is valid only for one time, and is changed every time, the attacker cannot get a correct token and send to user, so the attack cannot be preformed.

In the same way, the server can use simily token to prevent attacks using POST method.

This is the most popular and valid way to prevent Cross-Site Request Forgery attack.