View Security 101: Just don’t do it slides.
Okay, so this talk may actually fit in five minutes :)
So, this is a talk about Security 101: Just don’t actually do it.
So, the background for this is that there was a post by Daniel on Yammer which was basically we’re writing a piece of code in SQL Server Monitor Hosted, and we need to know how to do something in a secure way, and there was a whole 12 replies, and people came up with something, and I found a blog post where Google basically solved the same problem, only they solved it a different way because if you do it the way, the conclusion, we came to, it leaves you open to a misinterpretation attack. Because they’re quite complicated to explain, I’m going to pick a different example instead.
So, the point of this talk is to show you that something that seems so trivial and such a good idea actually is not.
So, in this hypothetical world in my example, you’re working for a company that has a couple of products. It’s got a web browser which is used regularly by 45% of people on the internet, and it’s got a web server which is visited by 90% of people on the internet. You should be able to work out which company I’m talking about here; it’s not entirely hard.
Cool, so, the product manager comes to you; you’re one of the developers, and says it has to go faster. We want our web browser and our web server to work awesomely fast together, because the application is people doing internet searches, where showing results is really really important to happen very quickly. And users have very slow internet connections, especially their upload, so if we can take into account of that in our design.
And what the product manager thinks is the feature we should implement is we’re going to embrace, extend and extinguish the HTTP/HTTPS standard, by adding our own proprietary extension so that when our web browser talks to our web server we’re going to compress all the HTTP headers, and we’re going to do this even when we run HTTP over HTTPS.
Are we all following so far? Cool, awesome.
So, what are you going to say back to your product manager? So this is a show of hands. So how many of you are going to say yep that’s a brilliant feature, we should definitely go and implement that? And how many people are going to say nope that’s a terrible idea; it would introduce a security vulnerability in our web browser? Hands for that? You all know what’s coming, don’t you? :( And the third one is the one that…, votes for the third one? The third one is that it depends on what our threat model is.
So then we come onto threat models. So with security you always start with a threat model, before you do absolutely anything else, you start with a threat model.
And the quote’s from Wikipedia, so it says: Attacker-centric threat modelling starts with the attacker, and evaluates what they actually want to achieve and what technical capabilities they have in their bag of tricks to achieve that, because only when you know what the attacker wants to do with your system, do you know where it’s worth spending the time to invest, because you’ve got limited resources, limited development, and you probably should be spending those resources actually defending the bits that the attacker is going to attack, and the bits that the attacker is not going to attack probably doesn’t need as much of your time.
So, now we come onto how the…, so let’s say that we have actually compressed the HTTP headers, this is what the attacker is going to do.
So, this is just a bit of background about HTTP headers for those of you that don’t know what they are. So they look a bit like this, so, basically, the bit in green is all constant across every single request. The bit in red is the bit that the web browser must keep secure, this is the authentication cookie, so if the attacker gets the bit in red he wins, and the bit in blue at the top is the actual page which we’re requesting off the web server.
So, now this is how the attacker attacks the compression of HTTP headers. The attacker can change the DOM on his site, just insert a whole bunch of images into the DOM; images that come from the target site he’s attacking. So the first time round he inserts an image with the URL (it’s going to 404 but that’s not really important), so with the URL DeploymentManagerAuthenticationTicket=0. The next time round he inserts an image with that one, and then next time round he inserts an image with that one.
And the point is that now we’re compressing the HTTP headers (these are all HTTP headers), the top one is going to compress better than the bottom two, because it’s got a longer repeated string, which means that because the attacker’s on the public Wi-Fi network, just as you are, he gets to see the length of your request, and he gets to work out the first character of the cookie is 0, and he gets to repeat the same thing to get the next character, and he can do all of this with the number of requests he has to make is the number of characters in the cookie times the number of possibilities for each character, which is fairly small.
So, this is why you can’t implement the feature your product manager says.
And this is the last slide. So the takeaway from the talk is that a feature that seems so simple will have a security vulnerability in it that you can’t reason about, so basically just don’t write this kind of code. Use an existing library if you can. If OpenSSL doesn’t have a function to compress the HTTP then there’s a reason, you shouldn’t build it on top, because there’s a reason it’s not in the underlying library. And if you can’t use an existing library then you’ve got a big problem, which is beyond the scope of this 5 minute talk :)
Cool, and that’s it. Any questions?