Skip to main content


Showing posts from October, 2010

ViewState and CSRF

Today, me and my colleagues- Chintan and Ronnie were having a long discussion about ViewState's ability to thwart CSRF attacks. While Chintan's argument was that CSRF is possible even the application is implementing ViewState, Ronnie's thought was it's virtually impossible to launch a CSRF attack on ViewState enabled application. My idea was that it's not impossible but very difficult and takes a great expertise to launch the attack. We also saw various articles were mentioning the ViewState as a countermeasures to CSRF, at the same time they were not denying the fact that this can also be circumvented.
For sake of doing some research over topic I stumbled upon some articles and came to some conclusion:
When attempting to exploit a CSRF issue, the attacker will try to remove the viewstate from the page, since often viewstate is not required for a page to function properly. If the page complains when the viewstate is removed, the attacker will try logging into the app…

Your Cookie attribute will be overwritten

In one of the applications , there was a vulnerability-they were not marking the cookie as 'HTTPOnly' but marking it as 'Secure'. I recommended them to as a best practice, flag the cookie as 'HTTPOnly' as well.

Set-Cookie: JSESSIONID=AJ122112KJYS.......; secure

Now they fixed it- They were setting the Cookie (Set-Cookie) as soon as the application loads in the browser and marking it as 'Secure'. Once the user is successfully authenticated they were regenerating the session ID and again (Set-Cookie) and this time marking it as 'HTTPOnly' only.

Set-Cookie: JSESSIONID=7H8TKLSDOPC56.......; HTTPOnly

Fine! but really? They were using the Set-Cookie header two times. First time they were marking it as 'secure' and again after regenerating it marking it as 'HTTPOnly'. Now this was the problem. Setting the cookie with Set-Cookie again overwrites the earlier attribute of Cookie. That means if you are setting cookie as 'secure and again se…

Open Redirection-How to Secure it

When the OWASP has also included this issue in it's Top Ten 2010 list and also I have been finding lots of unvalidated redirects in the applications assessed everyday, I was just giving standard recommendation to developers to go for whitelisting approach. Include a set of valid domains- to which only your users should be forwarded- into your application. Once you have identified a “whitelist” of trusted domains, put the list in a configuration file on the server or database. From a secure coding perspective, the redirection servlet or script should not take a URL as a parameter. Instead, require that the servlet accepts an index that maps to the list of trusted domains.
But as I am not very good in coding I was not able to assist them in coding.
Eventually today I stumbled upon a very nice article here. It describes the best practices for redirecting users to trusted domains and how to 'code' that.
Please visit: