Skip to main content

URL rewriting and CSRF

Is url rewriting a mitigation of CSRF? Though, almost sure it's not a foolproof solution, I put up this query before all security gurus out there on webappsec.

The application in question was replacing all the urls with some randomized and unique long strings in this format:

https://mysite.com/myportal/b1/04_SjzQ0NTYyNzS2MLTUj9CPykssy0xPLMnMz0vMAfGjzOJDfU19LNxMTQwsAoydDDyNXb0cnc2dDA2czfRzoxwVAVLe6h0!/

The url was long enough and sufficiently randomized.

The argument in favor of randomized url as csrf mitigation is, even an attacker is able to grab the url, it won't be valid for next session. So, the attacker can't exploit it by sending/ embedding in link/ images etc as it would stand invalid. Thus csrf mitigated.

But let's consider the scenario wherein an attacker goes to logged in victim's machine, applied his social engineering tricks and note down the url , convince user to click the forged link sent to him. If the user stays at the same page, he gets exploited. Though, it's a infeasible scenario and unpractical one and there's very remote chance of its technical viability, still it's a risk.  The attack window is certainly very small and short timed, but why to take chances.Even, I have detected some static urls in a page which don't rewritten each time, so they can be easily forged. Therefore it's always best mitigation is to implement anti-csrf tokens on the pages where critical actions are performed.

The url rewriting improves the anti-csrf defense mechanism, but we need to be sure that the strings/ tokens etc are unique and sufficiently randomized.So, even they are cached, they are unusable in next session or unpredictable. Invalidating them is always a part of good session management once the user is logged out.

However there are flipside of rewriting is that it can't be bookmarked for a later use and it would be a server intensive task as generating random strings for each and every ulr will affect the performance too.

So the bottom line is, though url rewriting raises the bar it's not foolproof solution to CSRF. The safest approach is using anti-csrf token in pages.

I thank all the people on webappsec.org mailing list for such a nice discussion.

 

Comments

Anonymous said…
Hello Sir,

I want ur favour.
I want t know if i put this query ’ 1 OR 1=1‘“ in search field the record is not displayed but the editinf field is displayed..

so i this page vulnerable to sql?

Popular posts from this blog

SQL Injection in search field

Earlier I had written about performing SQL injection in search field and how to do a DoS attack and privilege escalation using 'Like' operators. Now another SQLi exploitation I came across recently. That too in the search field. This becomes important as lots of people don't pay much attention on the search forms/ fields in the application. My aim is to show that a search form can also be exploited with SQL Injection. The following queries are based on a real world exploitation. The steps and data are for just illustration purpose only. Suppose, the search form provides the details of users who have accessed the application some time and their login time details etc, we just need to provide their name in the search box provided. All the data were being going as Post request. So, to just fingerprint the database, I provide, 'nil'+'esh' in the search field and it successfully gives me the results. That means the database behind the application is concatenat…

File Upload through Null Byte Injection

Sometimes, during file upload we come across situation wherein there would be check on the file extension at the client side as well as server side too. If the application does allow only .jpeg extension to be uploaded, the client side java script checks for the extension of the file before passing the request. We all know that how easily this can be defeated.
Some applications, checks for the extension at the server side also. That's not easy to bypass. However there are some ways with which it still can be bypassed. Most of server side scripts are written in high level languages such as Php, Java etc who still use some C/C++ libraries to read the file name and contents. That leads to the problem. In C/C++ a line ends with /00 or which is called Null Byte. So whenever the interpreter sees a null byte at the end of the a string, it stops reading thinking it has reached at the end of the string.
This can be used for the bypass. It works for many servers, specially php servers. Th…

Insecure protocols

Some basic insecure protocols and risk associated with them: