Nilesh Kumar

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.

During an assessment of an application, I and my colleague Ronnie were discussing about a scenario in the application. The application had login section behind which there were few pages that were vulnerable to Reflected XSS. Application was also vulnerable to CSRF.Needless to say that we suggested anti-CSRF measures for the application. Although we also suggested anti-XSS measures but the anti-CSRF measures were good enough to mitigate any attempt to exploit the reflected XSS flaws on the pages behind authentication. The application was rejecting any external request. So any attempt to exploit the reflected XSS will bear no fruit in scenario like this. Anyways we had recommended fixing both flaws independently but I wanted to have a discussion over the issue . Lots of people responded to that. All were with the same suggestion- do fix both issues, don't take chance. But what I found most convincing were these arguments from MustLive and Lava: MustLive says: Hel...