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

Today I just stumbled upon a discussion somewhere over net. I saw reply from Jeff (Chair, OWASP) to question about 'secure' attribute of cookie-how much secure it is? Well, it's a bit tricky, means when server is sending the secure attribute to the client (browser), the client must have initiated the SSL connection before it happens. Otherwise the server will send the set-cookie:secure flag on non-ssl channel itself. So you will need to ensure that the client has established a SSL connection to the server before the server sends a set cookie response. In Jeff's words: If what you expect is full SSL protection for your cookies, there are two problems with this. First, as you've noted, your cookie might get exposed in a "set-cookie" header that you inadvertently include in a non-SSL response. Second, and probably worse, the "secure" flag doesn't really mean use SSL all the time. If you do send the "set-cookie" header in a non-SSL re...

Most SharePoint environments today are using NTLM (the default) as the authentication protocol. NTLM authentication is a challenge-response scheme, consisting of three messages, commonly referred to as Type 1 (negotiation), Type 2 (challenge) and Type 3 (authentication). For more information on NTLM go to http://en.wikipedia.org/wiki/NTLM as discussion over NTLM and its working in out of scope for this post. The problem with setting up Web Proxies (Paros, Burp etc) is that they work fine with other types of authentication (Custom, Basic) but where there's NTLM is used the chain breaks between the proxy and the server resulting in non function of the application. As soon as the proxy wants to connect to the server it gets the following '401:Unauthorized' response: HTTP/1.1 401 Unauthorized Server: Microsoft-IIS/7.5 WWW-Authenticate: NTLM X-Powered-By: ASP.NET MicrosoftSharePointTeamServices: 14.0.0.4762 Date: Sat, 04 Sep 2010 06:38:22 GMT Content-Length: 0 You can'...

Continuing with my last post " DoS with Like Query ", another impact of it I want to discuss here. As I had said that the % and _ qualifier is often overlooked by developers to filter as its not so devastating as other characters. They are used for matching zero or more characters and single character respectively. I got a taste of it again when I was assessing an application recently. The application had several roles. Role A can't access data of Role B (that's obvious :) ). The Authorization checks were properly implemented-so no chance of Privilege Escalation. When I was examining the application closely, it has various search modules based on several conditions. If you search for a record after filling up a long form with fields with name, location, unit, suggestion no., suggestion name..blah,blah,blah. The one thing I noticed that the application was using the 'Supplier Name' field to search the records and listing down only those records which has matc...

My article on basic introduction on Reverse Engineering of Flash and .Net files. The magazine Hakin9 in which the article published can be downloaded here . The article is from Page#16 to Page#19.