Skip to main content


Showing posts from January, 2011

An alternative to Paros+Ntlmaps

In my last post , I had described about how to set up Paros with Ntlmaps to do security assessment of the application requiring NTLM authentication. It always works for me properly, until today! After a long time , I stumbled upon one application which requires NTLM authentication. As a Paros lover (no reasons, just due to its simple interface, I love it), I launched Paros and Ntlmaps. But badluck for me, couldn't figure out why Ntlmaps was unhappy with me. My whole day went in troubleshooting! Even I ended up un-installing and installing Ntlmaps. Even I locked my Windows user-credentials after exceeding maximum no of attempts from my system to the application. Anyways I got it unlocked. Even my colleagues were absent today (Ronnie, Thyagu) who might have helped me in configuring Ntlmaps. Anyways, it's funny that I had never paid attention to a functionality already there in Burp and WebScarab- I was laughing at myself! These proxies already have built-in functionality for wo

How cookie can leak

Today I was having a chat with my friend Vaibhav about few vulnerabilities in one of the applications. In order of that he asked me it's really necessary to mark cookie as "Secure". Well, depends...if your whole application is on https then you should always go for "Secure" attribute. Cookies set with the "Secure" keyword will only be sent by the browser when connecting by a secure means (HTTPS). Apart from that there is no distinction - if "Secure" is absent, the cookie may be sent over an insecure connection. We have seen a lot of cases where the cookie is leaked and sent over from https to http: 1. If your page contains mixed contents, ie. if you are including some links that is on http then the cookie may be leaked. For example, if your application uses url and you are including someother links in the page using http://, the browser may warn you as "this page contains both secure and nonsecure items". 2.

Few common web.xml misconfigurations-Part I

While doing code review usually I find various misconfigurations. I am trying to compile them here. Although they might not be a comprehensive list and something I may miss, but will touch most of the common points: Refer- 1. Authentication & Authorization Bypass: <security-constraint> <web-resource-collection> <web-resource-name>secure</web-resource-name> <url-pattern>/secure/*</url-pattern> <http-method>GET</http-method> <http-method>POST</http-method> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint> The above configuration shows how to setup web-based control. Here the assumption is that the everything in 'secure' directory must be accessible by 'admin' user only by using methods listed in tags i.e, GET and POST. No other methods should be allowed. B