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 logg

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 = AJ 122112 KJYS .......; 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 =7H8 TKLSDOPC 56.......; 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 

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: