Talks
Hack Me If You Can
Summarized using AI
Hack Me If You Can
by Konstantin HaaseThe video titled "Hack Me If You Can" features Konstantin Haase discussing the importance of web security for developers. He highlights various opportunistic attack vectors that web applications are vulnerable to and outlines preventive measures that can be implemented to enhance security. The talk is part of the Ancient City Ruby 2014 event, where the speaker also shares anecdotes and illustrations to engage the audience while delivering the core message about security.
Key Points Discussed:
- Introduction: Haase narrates his travel experiences to engage the audience.
- Importance of Security: He emphasizes that web developers lack experience in security measures, which is a critical aspect of application development.
- Common Attacks:
- Cross-Site Scripting (XSS): Haase explains how user input can be exploited through XSS and stresses the importance of sanitizing inputs and employing Content Security Policy headers.
- Cross-Site Request Forgery (CSRF): He describes CSRF attacks, where a malicious site tricks a user into submitting an unwanted request to another site using their session cookies. Solutions, including the use of CSRF tokens, are discussed.
- Path Traversal Attacks: Haase warns against potential file access issues, explaining how attackers can manipulate path parameters to access restricted files.
- Clickjacking: He outlines how attackers can lure users to click on hidden iframes. Solutions like X-Frame-Options are recommended.
- Same Origin Policy: Haase discusses the security provided by the same origin policy, which prevents unauthorized access to resources across different origins.
- Conclusion: The summary reiterates the need for developers to integrate security best practices into their applications, highlighting that security should be foundational in the development process rather than an afterthought. Haase's humorous anecdotes and practical examples help make the technical aspects more relatable and engaging for the audience.
00:00:00.399
Hello, hello! Hi, is anyone listening? Yeah, I understand whoever decided to have me go after Eron. Thank you.
00:00:07.120
At least Ain isn't able to send me tweets about me because he just got his account suspended.
00:00:12.240
So I know that there's one person who will be listening. Anyway, I'm Konstantin and I came here from Berlin.
00:00:23.880
I took a very smart route to get here. I started off in Berlin, then I went to Doha in Qatar, and I actually spent quite some time there. I landed in Saudi Arabia on the way, then I went to the Philippines. This was supposed to be an 18-hour trip, but it turned into 3 days. It took me 5 days to get to San Francisco, and then I took a red-eye flight to Florida. It's a highly recommended way to travel from Europe to Florida.
00:01:01.039
So anyway, I said, "My bag got lost," and now I’m faced with the situation where my bag has its own Twitter account and it's actually more popular than I am!
00:01:34.320
Let me be the first to welcome you to St. Augustine, the oldest city in America, or at least that's what I hear!
00:01:44.680
So the three things I’m really good at are history, geography, and telling people that they are wrong. Oh, and bullets on slides. I heard last year that this was even on the conference website, and I was like, as a European, I'm very proud that we have historic cities.
00:02:14.000
What’s your definition of the oldest city? What’s your definition of America? I wanted to figure out what it means to be the oldest city in America, so I looked it up and came up with a chart.
00:02:40.760
Depending on your definition, there’s one scale for your definition of an oldest city and another scale for America. Apparently, if your definition is the oldest European settlement where people are living today in the continental US, then it’s... I’m not sure how to pronounce it, but there's still a definition where St. Augustine is actually the oldest city in America.
00:03:14.000
This is because this city was uninhabited for almost 10 years sometime after the British conquered it about 300 years ago or so. So, if you make that requirement, then St. Augustine would actually win.
00:03:34.040
Interestingly, I didn't know how to pronounce it. I think the one city I have the least problems with is...EB, which is the first European settlement in the Americas.
00:03:41.439
It's actually in Greenland, but apparently that’s America. Anyway, don't take me too seriously; I'm actually here to talk to you about security.
00:03:48.840
About hackers! There’s an easy way that all the stories about security are usually structured, and it’s about Bob and Alice. I'm not sure I should be talking about Bob and Alice, though. I mean, you can have amazing stories about them, but I actually want to talk about real people.
00:04:02.400
Real people that I work with at Travis CI. These are the four founders in our company uniform, yes, that is a onesie! There’s this guy, Josh; he recently started windsurfing, and windsurfing is really hard. It creates super dangerous situations. For instance, you might fall off, and the big problem is that there are sharks in the water.
00:05:12.960
I’m really happy no one fell in the water while I was there because there are sharks everywhere around here. When I go out into the water, you could die! We talked about sharks yesterday, and I thought I would add that to my talk.
00:05:26.960
So I added the shark slides, and then I thought, how do I make this about websites again, about web applications and web security? So, imagine if you will, sharks attacking websites. That is way better than any Alice and Bob story.
00:06:02.400
But it seems a bit far-fetched, like why would a shark attack a website? It's a hard question, isn't it? There is, however, one website that sharks really, really don't like: it’s the one that tracks where there are sharks.
00:06:16.000
Right now, there are like three great whites outside of Jacksonville. Again, do not go in the water!
00:06:27.280
So, as those sharks want to eat us all, there's just one last piece of advice before I talk about the attacks that sharks can actually perform on our websites. If you want to avoid sharks and need to go into the water, there are frequencies that sharks don’t like that you can use to get rid of them. Just sing them out loud while you go into the water.
00:06:45.280
Okay, no, seriously now, let’s talk about web security. Who here thinks about web security when they write applications?
00:06:58.360
Okay, so what do you think of? Which attacks are common? Cross-site scripting? Who has heard of cross-site scripting? Yes, yes, yes! Who has not heard of cross-site scripting? I have it here because it is an element that is used in other attacks, so it's important that we know what we're talking about. What we’re talking about is when user input is presented somewhere on the website, and someone injects some HTML or JavaScript. It does something, and it’s very common.
00:08:03.440
We saw that in Eron’s slides where he escaped unsafe strings, and that’s what you need to do; you need to sanitize all user input! There are other ways to prevent cross-site scripting attacks. There’s this Content Security Policy header. Have you heard of this? It’s very, very powerful. You can specify that the following content can be loaded from specific domains.
00:08:42.560
So, the self is a magic keyword; it represents the same origin as your own domain. This states you may only load JavaScript from your own address and from Google. You can say the same for stylesheets, which might seem not dangerous, but if you can influence the way the page looks, you can do serious harm.
00:09:02.519
One nifty feature is that you can send a report URI. I’m not sure if all browsers implement this, but you can send a report URI that the browser will contact for violations of this policy. If anything tries to load a script from a different host, it will send a report to this address.
00:09:20.640
Really great! You should look into it. Okay, what other attacks do you know of? Anyone heard of man-in-the-middle?
00:09:34.079
Okay, I’m going to come back to man-in-the-middle later. What I was actually going for is Cross-Site Request Forgery (CSRF). That's like the second attack you usually hear about for browser-based attacks. This is a very straightforward attack. All you need is a decoy website that you lure someone to go to.
00:10:00.600
This sounds hard; it’s actually not! There are even some temptations, and I’ll get into that in a minute. There are reasons why you'd want people to stay on your website for a while.
00:10:31.840
The problem with this website is that it’s old—no one watches Nyan Cat anymore—so the sharks wouldn’t set up this website right now because the joke is quite old.
00:10:59.640
But there's a new game out there that actually has a lot of copycats. I’m not sure if you've seen it; it's amazing! I was considering doing a talk instead about what the best strategy is to win this game. And so, the most amazing thing about this game is that there's a sheer endless amount of copycats, various forks that do awesome stuff. Personally, I really like the Fibonacci version, but there’s also a great one—the Dodge version.
00:11:47.920
It’s a bit hard in the beginning because you need to memorize what the values are, or at least the order of Doge, how you pronounce it—what’s your order of Doge? They exploit a simple fact about how our browsers work, which is that if you send a request to a website where you are logged in or where you have been before, all requests will include the session cookies.
00:12:30.720
If session cookies are used, all requests—regardless of where they're originally triggered from—will carry those cookies as long as they are executed from the same browser session.
00:13:05.920
So, what you can do is take a URL that performs some harmful action, modify something, or trigger some action. You can take that URL and embed it as an image. It won't be displayed, but it will still trigger a request, and the request will still have that cookie.
00:13:25.720
Now, there are easy ways to prevent this. In HTTP, there are methods like GET, HEAD, and OPTIONS. They all have different properties, and they have a lot to discuss in a different talk, but we should be aware of the safe HTTP methods—like GET, HEAD, and OPTIONS.
00:13:45.580
These safe HTTP methods should never change anything, so you should not use a GET request for actions like taking down your shark tracking website. However, that only gets you so far because a website could still have a hidden form, and it could take that form and submit via JavaScript, and you may never notice because you're playing the game.
00:14:18.760
What can you do against this? What do web applications do to prevent this? Frameworks like Rails or libraries like Rack Protection, which is what SRA uses, will try to prevent such attacks. There’s a well-established method for that, which is using CSRF tokens. These are randomly generated tokens.
00:15:27.040
This is how you would implement it in Sinatra, for example: when it generates a token, it checks if it's not there and stores it in a session. Once this token is presented in a submitted form, it compares the token against what was generated.
00:15:49.960
If the two match, then the request can go through. Of course, you have to check that it’s not a safe request because you can’t actually lock out GET requests, or else no one could visit the website! If you wonder why this is strangely arranged with the if here and the unless, that’s because that way it fitted nicely on the slide.
00:16:44.760
So, in a nutshell, that’s what Rails and Sinatra do for you automatically, under the hood. When you have a form, it has a hidden field that contains the token.
00:17:18.600
It’s not actually configured as a cookie; it’s actually stored in the session store, which will then be written as a cookie to compare the two. This is the standard defense against CSRF. Keep that in mind.
00:17:39.360
Another very basic attack that I’ve often seen against earlier Sinatra versions, before Rack Protection was added, is path traversal attacks. One thing that some people used to do was take a pattern from a Sinatra route and map it to a filename or something they read from the disk or a template.
00:18:22.720
So, you would match the path and then use that to present a file. You might feel safe because you think: what dangerous things could happen? Well, you could navigate to a different directory by using ../ and so on.
00:18:59.280
But the pattern would not match because that's how Sinatra and Rails patterns work. It would not match a slash, so one thing you could do is to encode a slash. This is actually the URL encoding for `..%2F`, and you could add that in there, and it would match.
00:19:34.400
Sinatra currently does not do that, unless you have explicitly enabled this behavior. People keep opening issues about this, saying: hey, you're actually violating the HTTP specification because it says you should match the parts of the path before escaping these things.
00:20:22.800
But the plug you would compromise the integrity of many applications if the sharks could be allowed to access your server.
00:20:48.160
Another attack is clickjacking, which works like a CSRF attack. They lure you to a website and then make you click on something that is an iframe, embedding the other website that's under attack. It could be sized in a way that you don't recognize it.
00:21:06.760
Websites like Facebook suffered from this a lot at the beginning, where people would share things that they weren’t intending to and other people would click on that.
00:21:42.760
There’s actually a really easy solution, and again Sinatra and Rails do this by default: there’s a header called X-Frame-Options where you can have different modes.
00:22:06.840
You can say, yes, this page may be embedded in an iframe, or no, this page may not be embedded at all, or the third version is that it can be embedded by the same origin.
00:23:24.800
This is the second time I've mentioned the same origin, so let’s talk about it. Who has heard of the same origin policy? I want to see more hands!
00:24:20.400
So this is usually referred to with JSON and Ajax requests. The origin is the schema; is SSL used or not, the domain, and its port. The same origin policy states that resources like JSON files may only be loaded if the origin matches.
00:25:21.280
There are ways to disable this with Cross-Origin Resource Sharing (CORS) and other protocols, but by default, this shouldn’t be possible, so it should be safe to load JSON. However, it turns out that’s not 100% true.
00:26:13.920
Does anyone remember VBScript? VBScript is an alternative to JavaScript by Microsoft that was supposed to eradicate JavaScript because it’s better as it’s based on Visual Basic. Turns out, there was a security issue in all the versions that supported VBScript.”},{
Explore all talks recorded at Ancient City Ruby 2014
