

Sidejack Prevention - abraham
http://github.com/blog/737-sidejack-prevention

======
nikcub
The chrome extension I wrote today both redirects to HTTPS for the sites you
specify in options, but also re-writes all the cookies to set the secure flag.

Works perfectly on Facebook and Twitter without your session cookies every
leaking (including the initial HTTP request) and including like buttons, etc.

Add any other site in options (Twitter and Facebook are on by default - I
added github.com to mine and it works perfect, you may just need to re-login)

See: <http://github.com/nikcub/Fidelio>

------
asuth
We do exactly the same thing -- data-sensitive requests sent over HTTPS with a
secure cookie, normal browsing over HTTP. At this point it seems difficult to
implement site-wide SSL (CDN issues, browser bugs, overhead in SSL).

It seems like an important area of development for the web community to
improve the tools and services available to make SSL on regular sites easier
to implement. Yes, it's easy to turn on SSL, but there's a lot of nuance in a
good implementation.

~~~
look_lookatme
That's basically what we are going to have to do. There will be trade offs
(carving time out of our roadmap, etc) and it's going to be a pita, but our
space is one where some moron is going to sniff out a bunch of logins at a
conference and pull some epic trolling and we'll have to spend time deleting
the crap.

It's a shame that we can't go all SSL, but that's just the way it will have to
be. The best we can do is make it difficult to hijack access to our tools that
require elevated permissions.

------
jgrahamc
Not to diss the OP but most of the proposed solutions to FireSheep I've seen
display a distinct lack of knowledge of security. And that's one of those
fields where enthusiastic amateurs tend to get things badly wrong.

The solution to FireSheep is something akin to SSL (robust, fast encryption
with authentication). Could be SSL, or a VPN, or an SSH tunnel doing SOCKS.

Beware the MITM attack if you think all you need is encryption without
authentication.

~~~
mseebach
What's wrong with GitHubs solution? As I understand it, only insensitive stuff
is available in the unencrypted session, while writes and sensitive stuff goes
via unsidejackable HTTPS. Stealing a read-only Facebook/Twitter session is
much less critical, and allows for CDNs etc.

~~~
nopal
Can someone still sidejack a session and view a private repo?

~~~
brown9-2
The secure cookie is meant to prevent this.

~~~
nopal
Yes, I see this right in the post now. I completely overlooked that SSL was
used for browsing private repositories.

------
antileet
I have a basic proof-of-concept workaround to prevent Firesheep and other HTTP
Sniffers from seeing data sent from Client -> Server and Server -> Client. I
will announce it here when I get enough time to get it to properly work.

Since the concept is so ridiculously simple, I'm sure anyone can trivially
implement it. The only issue is that it needs HTML5 Local Storage to work.

    
    
        1. HTML rendered by the server has a small piece of code to generate an RSA Key Pair on the client using Javascript.
        2. The randomly generated keypair is stored on the Client using the HTML5 Local storage mechanism.
        3. For every request that the client sends the server, it sends the RSA Public key along with it. Also, the Server's Public Key is known by the client, and all outgoing data is encrypted.
    

The heavy work is already done, but by leveraging Local Storage and enhanced
Javascript Capabilities, it is trivial to create a pseudo SSL functionality.
This also deals with the issue of requirement of Static IPs, and other
limitations of SSL.

Of course, this won't mean that the entire Website will be secure. It'll be
quite trivial to create a small script to force all Form Data to get encrypted
with the Server's public key - thus making sure that atleast your Passwords
aren't transmitted in Plaintext.

In fact, with my current startup's application, the user's Password would
never even _leave_ the client machine. Javascript would perform an MD5 hash,
and the server treats that as the client's password. The issue with this is
that you'll need JS active on all browsers for it to work.

~~~
kule
>In fact, with my current startup's application, the user's Password would
never even _leave_ the client machine. Javascript would perform an MD5 hash,
and the server treats that as the client's password.

In some respects it makes you wonder why browsers never had this natively in
the first place - why should a third-party need to know my password when it
could just send a hash instead?

~~~
pieter
Because if you just send the MD5, others can log in as you when they know the
MD5, which they can just sniff. It doesn't gain anything in security, except
for not knowing your actual password.

~~~
pornel
You can send `nonce + MD5(nonce MD5(username realm pass))`, and then it's not
sniffable.

~~~
pieter
At that point, the server will have to have received the MD5(username realm
pass) at least once in order to verify the hash. You're better off not
building your own schemes and instead trust existing solutions like SSL.

------
mike-cardwell
So basically, Firesheeps existance has directly lead to Github becoming more
secure. Excellent.

If you use a vulnerable service, just write a Firesheep handler for it,
publish it, and then let the provider of that service know.

