Web Vulnerabilities Part 3 - CSRF (Cross-Site Request Forgery) 11-20-2012, 10:47 PM
#1
The cross-site request forgery vulnerability is present when we can plant a request to the user, which is then sent to the targeted web site in his/her name. The request then executes certain action on the target web site in the user’s name. There are two questions we need to ask ourselves:
How can we plant a request to the user?
What kind of action can we execute on the target web site?
The answer to the first question is simple. We can plant a request to the user in various ways through which the end goal is the same: the user’s browser has to send the request to the target web site on one way or another. We can plant the request to the user in one of the following ways:
In case the target web site is vulnerable and we can temporarily inject some code into it, we need to construct the right URI that we sent to the user, who must click on it. Upon clicking on the URI, the initial request will be sent, but because of the vulnerability a second request will be made to request the action that we specified.
In case the target web site is vulnerable and we can permanently inject some code into it, we can simply insert another request into the source code of the web page. When the user visits that specific web page sometime in the future, our custom request will be executed in the user’s name. This approach doesn’t even need social engineering to work, because all the user has to do is visit the vulnerable web page.
We can also construct our own web page, which we have total control over. This is why we can include the code that will do the malicious request in the source code of the web page alone. But in the end the user must still visit that web page, which is why we must send him/her a link to our own web page. When the user visits the web page, the requests embedded into the web page alone will be executed in the user’s name.
We can see that there are various ways to plant a request to the user’s browser, which must execute the request. But this is only half of the story; we still need to talk about what kind of request we can embed into the web page. The requested action can really be anything we like, but the targeted web page must support that action and execute accordingly.
Let’s say that we programmed the web page presented below:
When the user visits this web page, a new request will be made requesting the index.php resource on the web page “http://www.anything.com” with parameters id=1000 and action=up. Now, if that web page doesn’t have the resource index.php the request will fail. But if the index.php is present but doesn’t use the parameters idand action, the request will again fail. This means that we need to know about the files present on the targeted web page as well as the parameters that the web page uses to do some action. This way we could alter the results of the survey, where we would make a request that would vote for the first candidate of the survey instead of the other (which might be more popular). After that we would need to attract users to our page, so the voting requests will be sent to the survey as well.
But this is just a tip of the ice berg; imagine what we could do if we could send requests that would add another administrator user to some database, delete all the usernames, or even send arbitrary emails to contacts in users’ mailbox signed by that user, etc.
Now we’re going to explore other web vulnerabilities, which are also both prominent and common.
The easiest way I found to prevent CSRF issues is:
On the server side, assign a cookie to the client with a random (unguessable) token
Place a hidden field on the form with that cookie value
Upon form submit, ensure the hidden field value equals the cookie value (on the server side of things)
The whole purpose of the random token, is that user B (a hacker) does not know user A's token, and therefor cannot forge a request as them.
How can we plant a request to the user?
What kind of action can we execute on the target web site?
The answer to the first question is simple. We can plant a request to the user in various ways through which the end goal is the same: the user’s browser has to send the request to the target web site on one way or another. We can plant the request to the user in one of the following ways:
In case the target web site is vulnerable and we can temporarily inject some code into it, we need to construct the right URI that we sent to the user, who must click on it. Upon clicking on the URI, the initial request will be sent, but because of the vulnerability a second request will be made to request the action that we specified.
In case the target web site is vulnerable and we can permanently inject some code into it, we can simply insert another request into the source code of the web page. When the user visits that specific web page sometime in the future, our custom request will be executed in the user’s name. This approach doesn’t even need social engineering to work, because all the user has to do is visit the vulnerable web page.
We can also construct our own web page, which we have total control over. This is why we can include the code that will do the malicious request in the source code of the web page alone. But in the end the user must still visit that web page, which is why we must send him/her a link to our own web page. When the user visits the web page, the requests embedded into the web page alone will be executed in the user’s name.
We can see that there are various ways to plant a request to the user’s browser, which must execute the request. But this is only half of the story; we still need to talk about what kind of request we can embed into the web page. The requested action can really be anything we like, but the targeted web page must support that action and execute accordingly.
Let’s say that we programmed the web page presented below:
Code:
<html>
<body>
<img src="http://www.anything.com/index.php?id=1000&action=up"/>
</body>
</html>When the user visits this web page, a new request will be made requesting the index.php resource on the web page “http://www.anything.com” with parameters id=1000 and action=up. Now, if that web page doesn’t have the resource index.php the request will fail. But if the index.php is present but doesn’t use the parameters idand action, the request will again fail. This means that we need to know about the files present on the targeted web page as well as the parameters that the web page uses to do some action. This way we could alter the results of the survey, where we would make a request that would vote for the first candidate of the survey instead of the other (which might be more popular). After that we would need to attract users to our page, so the voting requests will be sent to the survey as well.
But this is just a tip of the ice berg; imagine what we could do if we could send requests that would add another administrator user to some database, delete all the usernames, or even send arbitrary emails to contacts in users’ mailbox signed by that user, etc.
Now we’re going to explore other web vulnerabilities, which are also both prominent and common.
The easiest way I found to prevent CSRF issues is:
On the server side, assign a cookie to the client with a random (unguessable) token
Place a hidden field on the form with that cookie value
Upon form submit, ensure the hidden field value equals the cookie value (on the server side of things)
The whole purpose of the random token, is that user B (a hacker) does not know user A's token, and therefor cannot forge a request as them.
![[+]](https://sinister.li/images/modern/collapse_collapsed.png)
