Skip to main content


Showing posts from September, 2010

Cookie 'Secure' attribute-really secure?

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

So, How will you work with a Proxy on NTLM...?

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 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: Date: Sat, 04 Sep 2010 06:38:22 GMT Content-Length: 0 You can