Friday, February 20, 2009

Compromising HTTP to HTTPS redirects

Update [3/22/2011]:
A great solution to properly address this problem is to use HTTP Strict Transport Security. This effectively instructs the browser to only interact with the webpage over HTTPS. The browser will prevent a user from sending any requests to the site over HTTP.
Content Security Policy (CSP Blog Post)
OWASP TLS Cheat Sheet

Many sites do their best to secure the login page. They post to https and even use an https landing page to accept the username and password. These items are great and exactly what should be happening. The next step is often to disable http access to the login page or automatically redirect http to https. Just in case a user types in instead of https.

Here is where we hit a problem. Once a user makes an http request they have lost. We must assume from a security perspective that there is always an active-man-in-the-middle attack. Assuming otherwise is placing a false trust on the infrastructure. So, the MitM simply takes the http request, intercepts the response (404 or 300 redirect) and inserts their own content. The easiest attack? Simply modify the response to a 200 and insert the correct html from the site's https login page.

Now the victim sees what they expect, a login page on their bank's website. The only problem is that the site never redirected to https. So the user enters the username and password and its transmitted in the clear. The MitM then happily sniffs that info and passes it to the actual site. The user never knows their creds have been stolen.

The above scenario is a simplified version of the new attack tool SSLStrip which was recently unveiled at Black Hat. The SSLStrip tool actually does a bit more by modifying the post location to a similar looking url which is accomplished with punycode. However, this is just icing on the cake. The fundamental issue above is a large enough issue on its own.

How to we protect ourselves?
We can say that we need to keep educating our users to look for HTTPS, but realisticly that's not the best defense. We should have technical controls to protect the user. What can we do? Aside from hoping the user always directly types in, the answer is nothing. But this isn't realistic. Users see that their site automatically redirects them so they happily type in the least amount of characters "".

Our only hope is to begin modifying the browser itself. I propose we add a setting to the browsers which allows a user to specify the website of their bank to the browser. The browser will then never access a page from that domain unless it is HTTPS.

Will this protect the user? Yes. Will it also break other things or be a burden to the site? Probably. But what's it going to be? Are we going to adapt or continue to let our users get compromised?

-Michael Coates

Wednesday, February 11, 2009


Did you know you can get printed and bound books written by OWASP? Did you also know that these books are provided at cost? So most books are less than $10.

Check out my AppSensor Book

Here's a quick link to all OWASP Books

By the way, you should know that one of OWASP's core principles is to be "free and open". So all of these books are available in electronic copy at absolutely no cost. Why would you want a book instead of a free electronic copy? Well, sometimes its just nice to have it in book form :)

-Michael Coates

Wednesday, February 4, 2009

XSS Prevention

Quick Link: OWASP XSS Prevention Cheat Sheet

How well do you know XSS? Do your defenses end at blacklisting alert("xss")? Let's hope not. In fact, if you are blacklisting at all to prevent XSS you are fighting a losing battle.

What's the correct approach? Well, you need to consider where you tainted data is going and then use the appropriate escaping technique. And just for the record, html entity encoding won't work everywhere :)

If you are interested in the positive approach for preventing XSS then check out OWASP's new XSS Prevention Cheat Sheet

Here are a few cool things that are discussed:
  • Injecting Up vs Injecting Down
  • Attribute Escaping
  • Javascripting Escaping
  • CSS Escaping
  • URL Escaping
-Michael Coates