Archive for the ‘Tools’ Category

Firesheep and HSTS (HTTP Strict Transport Security)

Friday, October 29th, 2010

Firesheep, released earlier this week, is a Firefox add-on that enables one to easily capture HTTP application session cookies from other users communications with specific popular sites. The problem it exploits is that many sites protect the initial reusable shared password-based authentication with TLS/SSL, but then revert further communication to unsecured HTTP. This exposes any application session cookies employed by the site, and returned by users’ browsers to the site on every request, to capture and replay by an attacker. This enables one to hang out on a local network, your favorite coffee shop for instance, and hijack others’ interactions with various social networking sites and retailers, for example.

This particular class of typical website vulnerability has been known for ages, as well as techniques for addressing it. For example, websites can simply offer their entire site over TLS/SSL (i.e. via “HTTPS“), as PayPal does. Some sites do so, but for whatever reason still revert users communications to unsecured HTTP by default, or some portion of their communications remain unsecured. However, if one can configure one’s browser to only securely interact with some given site (i.e. domain), and if the site supports this, then Problem Largely Solved. See, for example, Collin Jackson and Adam Barth‘s paper, ForceHTTPS: Protecting High-Security Web Sites from Network Attacks, for a description of this class of vulnerabilities, attacks, and remediation approaches.

I’ve been working with Collin and Adam on standardizing ForceHTTPS — their paper was the inspiration for the HTTP Strict Transport Security (HSTS) work and the present Internet-Draft specification thereof, and thus the HSTS implementations presently available in Firefox 3.x (via the Force-TLS and NoScript plugins), natively in Firefox 4 beta 6 and later, and natively in Chrome 4 and later. There’s also the HTTPS-Everywhere extension from the EFF that comes pre-loaded with a list of sites to use only via HTTPS, and is configurable such that one can add more (unfortunately it doesn’t support HSTS apparently)..

Now, HSTS is a website security policy that in typical cases, sites will explicitly signal to browsers (via an HTTP request header field), as PayPal presently does. However, this week, Sid Stamm, who authored the Firefox v3 HSTS add-on (Force-TLS) and native implementation, conzed-up a new Firefox v4 add-on, STS UI (Strict Transport Security User Interface), that allows one to configure one’s browser to regard given sites as HSTS sites, even if they don’t signal it. This also addresses the Bootstrap MITM Vulnerability noted in the HSTS draft spec.

Note that Chrome features “Preloaded HSTS sites”, and that NoScript (FF v3 & v4), HTTPS-Everywhere (FFv3), and Force-TLS (FFv3) all facilitate user configuration of HTTPS-only sites.

We’ll be working in the new IETF WebSec working group to finish the HSTS draft spec and get it published as an RFC, hopefully before too much of 2011 is gone. I’ll try to keep you all updated on that.

In the meantime, =JeffH sez be careful with your web logins :)

updated 31-Oct-2010: Added NoScript and HTTPS-Everywhere. Apologies to Giorgio and the EFF for not including them straight away.

Browser Security Handbook

Monday, December 14th, 2009

The Browser Security Handbook, brought to us by Michal Zalewski (of Google) is a quite useful document (droll understatement). It documents various security facets of the leading web browsers and provides succinct tabular comparisons of behaviors. It is available here..

Browser Security Handbook (BSH)
http://code.google.com/p/browsersec/wiki/Main

Michal has also created various test scripts and their source code is available from this page:

http ://code.google.com/p/browsersec/

The BSH is created and maintained on the Google Code wiki, and thus isn’t available if you’re offline (like on a plane). The wiki doesn’t provide for a clean download with link fixups and all, so I turned to wget and use the below command to cache a local copy (I’m on Ubuntu GNU/Linux)..

wget -E -H -p --convert-links -nH -nd -N -P/PATH/TO/WHERE/YOU/WANT/IT/TO/LOCALLY/LIVE http://code.google.com/p/browsersec/wiki/Main http://code.google.com/p/browsersec/wiki/Part1 http://code.google.com/p/browsersec/wiki/Part2 http://code.google.com/p/browsersec/wiki/Part3

I alias the above gnarly command line to the simple “getbrowsersec” command name (via my .cshrc file), and so whenever I’m online and want to ensure I’ve got the latest revision, I just type “getbrowsersec” and I’m all set. If you live in the Windows world, I’m not sure how you’d do the above natively. I’d install Cygwin, and then one has wget, and can just use the above command.

Stats – A Cool Last.fm Group

Monday, March 10th, 2008

I just ran across this group at Last.fm..

Stats

..it’s denizens post articles about and pointers to cool little gizmos/widgets/whathaveyous that one can use to leverage Last.fm data.

I ran across it via this person’s profile..

Anthony Liekens

..he has a personal website where he offers..

Data mining musical profiles
Anthony Liekens, March, 28-April, 2 2007

..that article, and a web interface to his various tools.
.
=JeffH sez check it out 😉

[update] ps: note that sites such as last.fm have relevance to the more general notion of identity in that publishing the music one listens to is an aspect of one’s identity.