Learn Web Security with Google (Google I/O '17)

Key Takeaways

[Music] Bonjour. My name is Ellie Buren. I work on anti-abuse and security research. And today with Yuan who work on web security research and Eric who work on web master relationship, we're going to tell you how you can learn about web security with Google. But before we get started, let's do a quick show of hand. How many of you had their website compromised or know someone who had their website hacked? Come on, don't be shy. Raise your hand. Yep. This is not s all most of you raise your hand. This is not surprising. Uh in 2016, uh hacking has never been so prevalent. Uh we found 32% more website compromise than ever. So hacker goes try to hack your website for many reason from attacking your user by sending malware to them or trying to fish them to using your resources as an attack platform to hack other website to try to steal your data and expose them. In either way when you get hacked the consequences are pretty dear. Uh you are losing the trust of your user and potentially suffer financial loss. Some of the lasting effects such as user trust can take year to recover. So this is why it is essential to keep security at the forefront of your web strategy and make sure that you invest in security constantly from when you develop a new thing. So when you maintain it so when you upgrade it. Uh I'm pretty sure you already know that because otherwise you will not be there today. Right? So today, what we're going to do, we're going to walk you through the resources that Google provide to help you secure your website and defend against hackers. More precisely, we're going to go into two topics. First, Eric will cover how you can get help from Google when you get hacked. What are the resources we have uh to help you clean up and to help you resecure your website? Then with Yuan, we're going to give you a sneak preview of our upcoming web security courses. and we are very excited to release later this summer. To make it very practical and give you a sense of what you're going to learn, we're going to give you a short overview followed by a sneak preview of one of the lecture, the SQL injection lecture. And of course, because we wanted to have something which is really hands-on, we'll have a lot of demo today. That is if that works, of course. And let's go and write jump right in. Eric, they're all yours. Thanks, Ellie. So, first off, hi mom. Uh, I'm on live stream right now and my mom's watching, so I'm super excited. I always want to do that. So, hi mom. Um, let's jump right into what you should do if your site gets hacked. You're most likely going to get some type of notification. From Google's perspective, that notification is this red interstitial that you may have seen. It could be some type of notification in search results. Now, notifications don't only have to come from Google, right? Uh, if your users are emailing you and they're saying, "I'm getting redirected. There's something wrong with your site." or if you're monitoring your web traffic and you see sudden spikes, those are all early warning signs that your site might be compromised and you'll want to check those out. As Ellie said, if your site is compromised, there's financial burdens, brand reputation, it's really annoying and worst of all, your users are trying to get to your site and they can't get to your site. So, it is in your best interest to clean up as soon as possible. Now, the process of cleaning up, it can um be quite daunting. Um, it's going to take some time, but if you follow these steps methodically, there's a really high chance that you can clean your site. And so, I'm going to walk through these really fast. The first thing is to quarantine your site. That means taking all your site offline or if you can isolate it to certain parts, take certain parts of your site offline. In this phase, you'll want to change any usernames, passwords, user permissions. The whole point being you don't want to be hacked while you're trying to fix your site, right? And also, you don't want your users trying to get to your site while it's compromised. So taking your site offline temporarily is usually the best move. You also want to start building your team here. Talk to your hosting provider. They may be able to help you. Talk to your wider team. Let them know that in these next few steps, you're probably going to need their help. Identification. This is probably the most difficult part and the most time consuming. Um, hackers are constantly trying to prevent you from removing the hack on your site. And so they'll do weird little tricky things like cloaking where you'll go to a page and you'll see, oh, this page is showing an HTTP 404, but it's still serving spam to your users and search engines. So identification is really important, but it's going to take some time. At this phase, you'll also want to identify the vulnerability because you want to understand how hackers got into your site. Cleaning up is just about removing those files and then testing, making sure that your site is running well again. Um, that's that's the main part of cleaning up and that's really all you need to do. Patching is about closing those vulnerabilities that you identified earlier to make sure that hackers can't compromise your site again. This is super important. A lot of people miss this and their sites do get compromised again. So, don't forget to close those vulnerabilities. One of the easiest things you can do is just to update your site software, your CMS's, uh your plugins, things like that. Just make sure that they're updated. Um, and that'll close a lot of vulnerabilities. Finally, if your site was flagged by Google, you saw those red interstitials on your site or you saw some warnings in search results, you'll want to tell Google that your site was hacked or that your site is cleaned up so that uh they can remove those flags. The steps we talked through just now, they'll work for most types of hacks on your site, but we've been doing a lot of research and we've realized that a lot of hacking campaigns, they work in very very similar ways. And this helps us understand how users are or how attackers are scaling their attacks, how they're trying to fly under the radar, uh, go against detection. And this also helps us build better detection systems and better documentation for our users. We've identified three major hacking campaigns so far. The cloak keywords and link hack where they create cloaked pages. They drop keywords and links on those pages. The gibberish hack. The gibberish hack creates a bunch of longtail keywords and then uses a domain's reputation to rank well. And then when users click in, they get redirected to these spammy malware bad sites. And finally, the Japanese keyword injection. This targets specifically Japanese brand name goods and sends users to counterfeit websites and attempts to sell them fake goods. We've been able because we've been able to cluster these sites in this way, we've been able to create really great documentation, step-by-step guides for each one of these hacks. And I'll link you to these documents in a second because I think it'll really help if you, your friends, or someone that you know um as you said, as you shown in the show of hands has been hacked or will be hacked in the future. First though, I want to talk you through the gibberish hack. Understanding how these hacks work are super interesting because it'll help you with remediation in the future. Now, this is what the gibberish hack looks like. It's really plain. Again, longtail keywords trying to use a domain's reputation to rank well, redirects users. The underlying mechanics behind it are also pretty simple when you, you know, put it into three separate pieces. the user clicks onto the site, they're redirected in some way or fashion to a spam ph to a PHP generator script and then those users are then redirected to the spam. So the first important part of this whole chain is this redirect. If you can identify how that redirect is happening, where it's happening, you can identify the other parts of your site that have been compromised as well. In this example, the ht access file has been compromised. Three lines of code. It's going to redirect your users coming from major search engines and then send them to this page right here, the spam.php page generator page. So you can see right now that you've identified the other piece of the chain, right? And so this is the the piece that you want to identify later. It's not going to be called spam.php. That's way too obvious. We've seen hackers call things horse duck 2. We've seen them try to mask as core files like wpc_config instead of wp-config. They're really trying to trick users from accurately and quickly trying fixing their sites. Okay, so from the redirect, we see that you're sent to the page generator page. Now, you're probably going to open this file. You want to figure out what's going on, right? You're curious. You're curious how they're they're they're doing all this damage. And you're gonna get something like this. This is just pure gibberish. They've offiscated. They've encrypted. They don't want you to find out exactly what they're doing. It's really difficult to understand uh what a lot of these scripts are doing. Even if you do deoffuscate, you take the time to figure out, you know, this is exactly what the code is. It's still not really human readable. This is not coding best practices. Your CS professors would be appalled by looking at this. Luckily for you, all you really need to do is remove this file. Um, I would ask that you back up these files just in case, just in case they are good files. And later on, if you do want to do some forensic work, it could be helpful having these files as a backup. So, just back up just in case. You can see these two files, they've done a lot of damage to a website. And so, that's why you you don't even want to be in the phase of cleaning a website. Cleaning a website is difficult. It's financially costly. It's annoying. you have brand reputation, your brand reputation on the line. And that's why the key takeaway here is that prevention is key. So, let's talk about a couple quick things that you can do today right after the session in order to help with prevention. First off, back up your site. There's a lot of people that don't back up their site, and that's actually a little bit baffling to me. Um, definitely back up your site as often as possible. If you do get compromised, one of the easiest ways to recover is just to restore a backedup version of your site. Remember that even if you're restoring the backup version of your site, that vulnerability that the hackers initially got to probably still exist. So, you want to fix that vulnerability. Secondly, sign up for search console. If Google does find that there is a compromise on your site, we'll send a notification via search console. This is this is one of the ways that Google communicates with web masters about not only security issues, but a lot of search issues as well. And finally, update your code, your CMS, your plugins, your themes. Like I said before, this is one of the most common ways that attackers compromise site. And I know this is difficult because I've talked to a developer before and she said, "My client, they don't want to update their site because if we update the core CMS build files, they're going to mess up a whole bunch of plugins." Um, yeah, that does happen, right? But it's really in your client's best interest to update, and you have to convince them. you have to talk to them about making a site that is both secure and still works for them. So that's a really really important piece. Uh as I said earlier, there's a lot of documentation that Google can give to help you. Our web master hacked help center is at g.co/hacked webmasters and that's where our security guides are the the ones for the specific hack campaigns that we've identified and we're we're constantly building more of these guides for different types of hack campaigns that we've identified. The second thing is the web master help forums. We have a lot of awesome top contributors, uh, experienced web masters and Googlers in these help forums to help you remediate your site, uh, fix your site, identify any vulnerabilities. And finally, follow us on Twitter. We give not only security updates, but we'll give you uh, updates about search. Now, I'm going to hand it back to Ellie to talk to you about the second part of securing your site, and that's building a safer website. Thank you, Eric. [Applause] So as Eric said when it come to security prevention is key and so far at Google we didn't had much of a uh public course to help you out. So we decided over the last year and a half to develop a new security course which is meant to be very hands-on so you can have a very practical knowledge you can apply to secure your website. Uh the core idea behind the course is to have very short focused lecture on core concept that you can apply immediately and a lot of exercises so you can build down handon experience and have this knowledge that you can help to protect your site. So let's look at what the course look like and then we'll do a few demo along the way. The course will be a set of 12 lecture which will be grouped into three main categories. The first thing we're going to discuss is how to handle user data safely from how do I authenticate my user? How do I maintain session with them safely? And finally, of course, how do I encrypt my communication so that when they interact with your website, your user are safe. The second thing we're going to cover is web attacks. These are attacks which are specific to web security and that you need to know to make sure they you are not vulnerable to them. We're going to cover the four big ones which are XSS, CSRF, SQL injection, and clickjacking. And finally, but not least, uh we are going to tell you how to handle securely third party content. Whether you would like to embed a widget from a third party website and make sure that when you do that, you not get hacked if they get hacked to how do you deal with user content? How do I make sure that I don't have toxic content on my website or they don't post inf famousamous picture into my uh beautiful stream? And finally uh because as Eric said when you get hacked it's really difficult to recover. We'll have a lecture dedicated to investigation and show you concrete case of hacking so you can learn how to investigate them and clean up. So in the event you get hacked uh you already prepare. So for each lecture we're going to provide you a few material. First we're going to give you slides where you can review the lecture. Uh we'll do a video of the slide with some explanation and the most important part we will give you exercises you can do and the quizzes so you can know how well you're doing and if you have understood the concept. So exercise was really a key development point. We have built a ton of those. We have over 50 exercises for you. Uh they're going to be uh in multiple aspect and multiple aspects of web security. First you have attack exercise where you wear your black hat and you try to attack websites. So you get into the mindset of the attacker and understand how they go about attacking your website. Then of course we go to defense where you know how to apply the best state-of-the-art technique to protect your website and you really understand what are the security mechanism are and how you can apply them successfully. And finally for some of the things especially for hacking we will cover investigation where we give you some puzzle and some interesting hack to look at and understand if you can figure them out. One of the essential challenge we had to overcome was it's not easy to teach web security because you manipulate vulnerable code, right? So we can't put it online and because we're going to get hacked. So how you do that? Originally people come up with the idea of using virtual machine or have people install a ton of packages and you have to run a lot of things. Uh this is not very ideal because it's very resource intensive. You have to download a lot of stuff. It's on your computer. It also limits the amount of device you can use. there is no way you can use a tablet for example. So about a year ago we were thinking of the problem and we say well web technology has so much evolved uh let's try to do something different let's try to use a web app technology and the crazy idea we had is let's build a web server directly into a web page I know that sounds crazy but the idea was we have web service worker so we can make it offline we can make it intercepting the request and just respond to it so let's build that and you know what let's throw in a webq injection SQL database and maybe a PHP interpreter and see if it works. And it was crazy, but we tried and it actually worked really well. So now what we have for you is a test bed where you just go to the website and then everything happened to your browser. Nothing to install. You get started. It's very easy and it all happened as you were on a real website. So that being said, uh this is all word, right? And you probably want to show to see it. Yes. All right. So let's jump to our first demo uh which will show you the framework. So we're going to do a simple website which going to allow us to loging our users. So to do that uh we're going first to need to have a server system. So as everything and it's like really look like node with express. So if you're familiar with nodejs you will recognize the syntax. We need to declare our root. So because we're doing a login page we need two web page. First, we need somewhere where the user will land and we'll have a form. So, let's create that. Then, let's add a second route which will be processing the login information and decide whether or not you authorize to loged in. So, we're going to create two routes. One is a get as you can see and the other one is a post and which for now we're just going to say hello world just to see if it works. Remember this all is local host. You can see it on the bar. This is all local host. No connection, all offline. And we hope it's going to work. All right. So, let's load the exercise, uh, reload the framework and go to the page and see if it works. And here you have it. We have a working web page into our browser. Now, let's add a little bit more things because, you know, it's a login page. So, we need a form. So, let's add a form. Fortunately, our framework authorize and support templates like any normal web framework. So, let's add a little bit of CSS so it looks pretty. A password and a login field. And let's reload to make sure we see our login form. So, to add the template, I forgot to add. Thank you, Yuan. Uh, we have to add the index HTML. So, we're going to load the template, return the template, reload, and hopefully you have a nice Google IO form. Yay. So that's great, but it doesn't do much right now. We have a form, but we need to process it. Uh, so let's have a bunch of users. So here, what we're going to do is we're going to add a database. So adding a database in the framework is very easy. All you have to do is create a database. One line of code. The framework do all the magic for us. Then we're going to add a user. So let's create a a user table, which will just contain a login and a password. All right, let's add a user, a Google IO user for the demo. And by the way, do not do that for real. Do not store your password in clear. Do not do this, right? Don't that's just for demo. Please don't do that. It's insecure. But for the demo, it will do. So let's add that. And let's add a little bit of JavaScript code to check create a database and check if it's happen. Here it is. So we get two variable from the environment. Run it into an SQL query. That's if it's correct and we should have everything for and we're good to go, right? So, let's try it. Um, we reload now. We have a page. Let's try with the wrong password. So, Google IO and I don't know password one two three. Oops. Yeah, user not recognized. Works as intended. Now, let's copy this thing which is insecure. And let's try again. Google IO as a user and the password and click on it. Woohoo. We are logged in. So we have a fully functional login system with a database website. Few lines of code. This is a framework we built and this is a framework we use to create exercise. Pretty cool. Yes. All right. Let's go back to the slide and talk a little bit more about the content. Right. So we show you the technical framework we have behind it. So but framework is great content is better right you need it. So let's jump into one of our lecture the SQL injection lecture. So we show you what kind of content you're going to learn. So SQL injection is one of the most deadly attack you can suffer from. And so I'm going to tell you a little bit about what are SQL injection vulnerability and of course how to prevent them. And then after that you want to will do a few of the exercise to show you how you can learn it hands on. So why do SQL injection exist? Well, it turned out that during our little demo, we introduced a vulnerability. We introduce a vulnerability because when you have an SQL statement, an SQL contain both keywords which tell you what to do and also parameter which tell you what to look for. If an attacker is able to control one of those parameters, it can actually inject keywords and the server have no way to distinguish between the two. We actually have this vulnerability in our very own code. So this is a mix between keyword and parameter which make SQ injection possible. So what an attacker can do with that? Well, an attacker with the ability to control SQL query will bypass any type of security check you have and will do unexpected query from reading sensitive data to deleting your database encrypting it and do all ne things. uh more formally the consequences of such as an attack if you have it is it breach the confidentiality integrity of your website because everything is the database and also it allow to authenticate without knowing the password for example because you can defeat any type of check so there is multiple type of SQL injections there is a classic one we're going to demonstrate today and there are more advanced ones such as the blind SQL injection and the second order injection I'm not going to talk to them about today because we don't have time. Let's just focus on the classic one. So the classic one as I explained works very simply. The attacker instead of sending what you expect will do the unexpectable and would try to manipulate the SQL query by sending specific payloads. Then it will result on an expected SQL query and then your database will just happily do whatever the attacker want and potentially excfiltrate sensitive data. Uh here is a concrete example, right? If the attacker can inject the username then he can decide instead of say username to say let's say Google then close the field and then add dash dash which commands arrested as a result of that as you can see on the screen well uh you are basically bypassing authentication. So to make it more concrete let's jump to our second demo. So we'll show you the attack live hopefully. Um demo please. All right. So, we back to our uh demo. And if you remember, can you go back to the uh the code? If you remember, we took the username and directly inputed into our query, right? You can see it on the screen, right? So, we didn't do any check. We're like, okay, we trust the user input, which you should never do. And as a result, we'll be able to log to the website without the password. So, let's demonstrate that. So, the way to do that is, as we explained, is you use a username. So that's Google IO. But then instead of doing what expected, we're going to add a quote to close the parameters. And then we're going to escape. And the escape in SQL is just this. How many of you believe that's going to work? One person. You have very no faith in me, man. Come on. All right. So we're going to to do it to do it. Okay. Let's try. All right. So here it is. We were able to log to the website without any password because we let the attacker manipulate the input which you should never do. All right, let's go back to the slide. So, how do you prevent that? There is a simple way to defend against that. This is called parameterized query, also known as prepare statement. The idea is instead of using the variable directly into your query, you're going to actually write your query and specify where the parameter should go and then input them afterward. That will prevent SQL injection. You should also always escape the user input because you should not trust them. It open you to many more other attacks such as XSS. So that conclude our uh short explanation about SQL injection. You going to in a few minutes to show you how the exercise works and all the frameworks work. But before that, how many of you would like to get early access to the course? All of you. That's brilliant. So you is going to tell you that just before the exercise. You answer all yours. All right. So signing up is very easy. You just have to register using the link on the screen starting today. Um g.co/learnweb tech. Okay, let's switch to the demo and we'll show that slide again at the end of our presentation. So since we're familiar with SQL injection already, we'll just skip to that. Um, as Ellie mentioned, each topic will have material so that you can learn on your own. So slides, the lecture, a related reading list, quizzes, and of course the exercises that are going to give you some hands-on experience so that you can reinforce what you've been learning. Uh, you'll be attacking, defending, and investigating sites. And to make it a little more fun, we're taking inspiration from the pie versus cake war, uh, to craft some of our scenarios. So, um, in our world, the pie syndicate is a little worried that a new cake shop has just opened up and so they're going to try to attack their rivals website. And then the cake guys are going to be defending themselves and investigating these attacks. All right. So, we'll be sticking with the basic exercises today. And since we've pretty much done attack number one already with Ellie, we'll just skip to number two. And for this, I'll need my black hat. Okay. All right. So, we have our objective on the left. Hey, Pi Minion, that cake shop is still in business. We can't keep losing slices of our territory to rival industries. They still have a mostly online operation for now, but we must act quickly. Word is that they're still vulnerable to SQL injections. We've gotten a leaked copy of their server code, but unfortunately no idea who any users might be. We need you to batter down the defenses and get their customer list. Get to it, Pi Boss. All right. So, very helpfully, we have a direct link to the page that we're going to attack. Um, and we have a copy of the server code. So, we have the same vulnerability as before, but because we don't know the username, um, uh, this we, uh, our previous bad input won't work. So, let's take a look at the code. And on line 12, we see that actually it doesn't really matter what the select statement returns as long as it returns anything at all. And so this is where we'll be uh targeting our our new crafted query. Um we just need to get the wear statement to return true at all times. And to do that, we'll just add uh let's see an or 1 equals 1. And this has the effect of saying choose uh select from users uh where username equals admin or true. And so now we're going to force the statement to always evaluate to true. And now we have access to their customer list. And that popup means that we've succeeded. So we can move on to the defense. Okay, let's close this. Okay, for this I'm back on team cake and I got my white hat for that. So, our mission once again, greetings, fellow baker. As you know, there's been chatter of an upstart upstart pie maker with crusty connections. We suspect they've been trying to attack cake shops for some nefarious and no doubt irrational purpose. Your site has been identified as one of these targets. In particular, it seems your login page leaves you vulnerable to SQL injection. Please fix it at your earliest convenience. Cake boss. Okay, so this time we're going to use the editor. And let's see. I'm going to refresh. Um, and let's see. Refresh again. Sometimes the service workers need to get updated properly. So, takes a little bit of time. Okay, there we go. And let's verify first that we are still vulnerable to this SQL injection attack. And indeed, we are. Okay. So, all right. We're going to use our editor to fix things. And this editor comes with syntax highlighting, linting, all the nice stuff. uh and we'll also need these three buttons on the side. So the first one will run our code uh against the test framework and make sure that uh what we're doing will succeed, will not succeed, you know, just tells us when we've finished the exercise. In this case, we failed because we haven't actually fixed anything. The second button is going to give us a hint. Um and finally the third one will reset everything and uh so that we can start from scratch. So to go about actually uh fixing this we'll just use parameterized queries or it it's also called a prepared statement. Um so remember we're not supposed to use user input directly. So instead we'll tell the SQL uh prepare a statement that has specified exactly when to expect external input. So here um this is the parameterized statement and then we'll give it the username and password here and let's see if that passes our test. Okay, so this should be good. Now, let's refresh and double check that we've it actually works. Oops. And we've successfully defended ourselves against this particular SQL injection attack. So remember that this is just the basic exercise. So in practice in creating actual websites in the live you would also sanitize user input as LA said and it can't be said enough times never trust external input. Um so that's it for the demo today. Let's not tempt the demo gods any further. Uh back to the slides [Applause] please. Okay so uh thank you for attending our session. Um, you can sign up for early access to the course which will be released this summer. And if you're interested in more about uh in learning more about web tech or maps or whatever, hand over uh head over to some of the sandboxes. Um, I think there's one by stage six that's going to talk about progressive web apps. And thank you again and enjoy the rest of IO. [Music] Hey,