Nilesh Kumar

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...

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 ...

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: http://mikeware.us/goodcode/?p=260