LUCIANO ARANGO: OK, guys. My name is Luciano Arango. I'm a sophomore in Adams House. And we're going to be talking about web security active defense. So I work for the Office of Information Security in SEAS. And over the summer, I interned at SeguraTec, which was a information security company that served for the Bank of Columbia. That's mostly where I learned what I've learned so far. And so some of the material that we're going to go over today, we haven't really talked about in class. But we will soon. It's going to be like SQL, JavaScript. And we haven't really gone over it. So I may sort of flight through it, and you might not know some things. But soon, you'll learn it. And it'll all make sense. Also another thing-- stay ethical. Some of the things that you learn, you could use in non-ethical ways. If it's yours, definitely try. I definitely motivate you guys to try your own servers, try going inside them. See if you can penetrate them, if you can get inside them. But not anyone else's. Cops don't really like the jokes and the whole, we put this here. We were messing around. They get really angry. So head over to this website. I have it opened right here. This is a website, and it has a bunch of examples. What happens is that the first example is sort of going to be a lot easier than the last example in a sense that the first example is completely insecure. And the last one is sort of what a normal web security person would do. But you can still sort of get around that. And we're going to focusing on one and two, examples one and two. OK. Let's start with cross-site scripting. The JavaScript is run on the client's browser. It's a programming language that you use to run on the client's browser so you don't have to update the website and go back to the server. You have it running. For example, Facebook, you don't have to reload the website for new status updates to come up. It's using JavaScript to generate all these things. So we can inject malicious JavaScript into the websites. And that way, when we send a link to someone, we could sort of send it with some of the code that we want. There's persistent and non-persistent JavaScript-- persistent and non-persistent cross-site scripting, I mean. And the difference being that persistent is JavaScript that will be saved on the website. And non-persistent will be JavaScript that will actually just happen once. So let's look at an example real quick. OK. So this website, simple, nothing happens here. And we're going to try to insert some JavaScript. So the way we start writing JavaScript is we start with the beginning script. And we close it with script. We're simply going to put a message-- I'll show you-- alert. Alert is a function that JavaScript uses to display something. So let's try it real quick. I'm going to go, alert hello. Well, I forgot to put-- OK. So that's simple. We put JavaScript on a website, and it came up. And it sort of only happens on our website, right? So it seems like it's not a problem, right? I mean, how could you use this maliciously? So the way that hackers do this is really simple. They're going to grab it. They can send this link to you. If I'll send this link to you right now, and you open it up, it's going to say, hello, saying that my website is telling you hello. And so if I were to say something a little bit smarter, if I pull up a JavaScript function I kind of already wrote-- but if you look at it, I'll go over it before I wrote it. So we're going to set a timeout. We're going to wait for a couple seconds. In fact, we're going to wait for, if I'm not mistaken, five seconds. This goes in milliseconds. And then what we're going to do is we're going to alert that the login timed out to log back in. And we're going to change the location to a different location. So if I send this website to someone, they're going to be browsing around, calm. Nothing's happening. And in five seconds, it's going to say, your login timed out. Please log back in. Once they click OK, I'm going to take them to another website. Presumably, the website's going to be similar to the website that they were in before. And they're going to log their credentials into my website instead of their website. And so I can send people an email with this link. I say, oh, here's a link. This is a bank, for example. I say, here, go on this link. And once they send it, they're going to be browsing around. I can wait for 15 seconds, 20 seconds, and then pop that please log back in sign back on. You guys can try it with a lot more things. It's complicated because you guys haven't seen JavaScript, so you might not know some functions. But all you have to do is start with script, end with script. And you could put anything in the middle. Alert is a function, wait for. Window location takes you to a new location. But you can do so much more. And so the idea is that we take that off. If I go to example two, and I put in this same code, it's not going to work. So it's printing everything out because what this website originally does is if I put anything here, it'll print it out right here. So it's not printing anything out. This example is actually checking to see if script is there. So yeah, go ahead. Ask me. AUDIENCE: Is not sending a get or post request? LUCIANO ARANGO: Yeah. they're sending a get request. AUDIENCE: It is? LUCIANO ARANGO: Yeah. Also browsers use post requests. But I'm trying to show get requests so that we can see what is actually going on. And so if we look at this code-- so it's not working anymore. And if we take a look at this code, it's going to be in example two. What this person is doing, the person in charge of this browser-- open up, OK-- is replacing the word script. This is PHP, which you guys might have seen a little bit of yet. He's just replacing the word script with name. So however, if I go ahead and just put in-- if I grab my code again, and I'm going to modify it just a little bit. Instead of script, I'm going to change it for scRipt with a capital R. And we're going to see if this code works. So it didn't print it out, which is a good sign. And hopefully in two more seconds, it's going to pop up. Your login timed out. OK. That's all right. So checking for script might not necessarily work. The person-- it can also check for script uppercase, script lowercase, str case compare, make sure they're the same. But the hacker can still do sort of what we did in Vigenere when we moved back a couple characters, move forward. And it can figure out how to put script back in there so it can inject that script. So what you want to use is htmlspecialchars to protect your website. And what this does is it makes sure that what you put in-- for example, quotations or this greater than or less than-- is replaced with something that won't be-- let me zoom in here-- the actual ampersand. It will replace those special HTML characters that we'll see when we're talking about-- oh, this is going to take me back to-- these characters right here. These signify that something is coming. For HTML, that beginning bracket tells us that something HTML related is coming. And we want to get rid of that. We don't want to put HTML into a website.k We don't want the user to be able to put something in their website that can affect their website, like script or HTML or something like that. What's important is that you sanitize the user input. So the users may input many things. He can input a bunch of stuff to try to trick your browser into still running this script code. What you want to do is not just look for script, but look for everything that could be malicious. And htmlspecialchars will do that for you, so you don't have to worry about it. But don't try to do by yourself sort of with your own code. Is everyone clear on XSS? OK. Let's go to SQL injection. So SQL injection is probably the number one vulnerability in different websites. I mean, a good example-- I was just researching furthest for this thing. And I found this awesome article, where I saw that Harvard was breached, was hacked. And I was wondering, well, how would they do it? Harvard's the most awesome, most secure university ever. Right? Well, to breach the servers, the hackers used a technique called SQL injection. So this happens on a day to day basis. People forget to take account for SQL injection. Harvard does. I think it says here, Princeton, Stanford, Cornell. So how do we-- so what is this SQL injection that is bringing all these people down? OK. So SQL is a programming language that we use to access databases. What we do is we select-- so what this reads right now is select everything from the table. SQL, it changes into these databases that have tables full of information. So select everything from users where the name is username. Right? Simple enough. The idea of SQL injection is that we insert some malicious code that would trick the server into running something different than what it originally was running. So let's say for username, we put in or 1 equals 1. So we put in or 1 equals 1. The way it will read now will be select from users, everything from users-- this is everything-- where name is username, but username is or 1 equals 1. So name is nothing or 1 equals 1. 1 equals 1 is always true. So this will always return information from the users. OK. We don't need to have the correct username. We can just have anything that we want, and it will return information that we need. Let's look at another example. If we have select everything from user, where name is DROP TABLE users-- so what do you think this will do if I put in the username as DROP TABLE users? Anyone have an idea? Yes. AUDIENCE: It's going to tell it to dump all the tables. LUCIANO ARANGO: It's going to tell us to dump everything in the website, everything in the database. And what people use this for-- so I'm going to show you guys. I disabled dropping the tables because I didn't want you guys to drop my tables. Let's take a look at this. So this simply pulls up the information for a certain person. So how do we know if this is affected by SQL injection. We're going to check real quick if we can put something-- let me copy this code. I'm going to go over it in a second. I'm going to put root and 1 equals 1. This right here, this percent sign 23-- what it really is, if I look right here at-- the way HTML takes in numbers, if you take a look at when I put in a space here-- if I were to space something here, it changes it to a percent 2. Do you guys see this right here when I put in a space? The way it works is that you can only send ASCII values through HTML. So it replaces, for example, a space with percent 20. I don't know if you guys have seen that before. It replaces a hashtag with percent 23. We need a hashtag at the end of or statement so that we can tell the database to forget to comment out this last semicolon at the end. We want it to not think about that. We just want it to run everything that we have beforehand and comment that out. Let's take a look at it. So if I were to put something wrong-- let's say for example, I put 2 equals 1, it doesn't give me anything. When I put in 1 equals 1, and it does return something, this tells me that this is vulnerable to an SQL injection. I know now that whatever I put after this-- and for example, DROP TABLES or something like that will definitely work. I know it's vulnerable to SQL injection because I know that underneath the hood, it's letting me do the 1 equals 1 thing. OK? And if we look at these other ones, number two and number three, it's going to do a little bit more of checking underneath the hood of what it is. So anyone enable the drop anything yet or tried? Do you guys sort of get SQL yet? Because I know you guys haven't seen it yet, so it's kind of confusing for you guys. Let's take a look. So what's the way to prevent SQLI? OK. So this is really important because you guys definitely want to prevent this in your websites. If not, all your friends are going to make fun of you when they drop all your tables. So the idea is that you repair the SQL in a certain way, whereas you match what the user inputs with a certain string. So the way this works is you prepare the database. You select name, color, and calories from a database called fruit. And then where calories is less than, and we put a question mark there saying we're going to input something in a second. And color equals, and we put a question mark saying we're going to input something in a second as well. OK? And then we execute it, putting in 150 and red. And this will check to make sure that these two-- this array will check that these two are an integer and that this is a string. Then we go, and we fetch all, we put it in red. That means we fetch all. It means we actually execute the SQL statement and put it back in red. Here we do the same, but we do the same for yellow. And we fetch all. And in this way, we prevent the user from being able to input something that is not what we specified, a string or an integer, for example. I was talking earlier about relying on others. When you guys start your project, you're most definitely going to use bootstrap or something similar. Have you guys ever used Wordpress? Probably you guys have used Wordpress most likely. So the problem with using other people's things-- I'm just going to Google real quick Wordpress vulnerability. If I pull this up right now-- I literally did a two second Google. We can see that Wordpress-- this is dated as September '12. 26 is updated. The default configuration of Wordpress before 3.6 does not prevent these certain uploads, which might make it easier for cross-site scripting attacks. So a quick story, once we were working with-- so I was, in summer, working an internship. And we were working with sort of like a big credit card company. And they rely on something called-- I don't know if you guys ever played with a product called Joomla. Joomla's a product that is used to control-- sort of similar to Wordpress, used to build websites. So they had their website working on Joomla. This is actually a credit card company in Colombia. I'll take you to their website real quick. So they used Joomla. And they hadn't updated Joomla to the latest addition. And so when we were taking a look at their code, we were able to actually go inside their code and steal all the credit card information that they had, all the credit card numbers, the names, the addresses. And this was just-- and their code was perfectly fine. They had great code. It was all security. They checked all the databases. They made sure cross-site scripting was fine. But they used something that was not updated, that was not secure. And so that led them to-- so you guys are definitely going to use other people's code, other people's frameworks to build up your website. Make sure that they're secure because sometimes it's not you, the one that makes a mistake. But someone else makes a mistake, and then you fall down because of that. Passwords and PII. So passwords. OK. Let's take a look at passwords real quick. OK. Please tell me that everyone uses secure-- I'm hoping everyone here uses secure passwords. I'm just letting that in as an assumption. So you guys are definitely going to store passwords for your websites. You're going to make something like a login or something like that. What's important is to not store passwords in plain text. This is extremely important. You do not want to store a password in plain text. And you definitely don't really want to store it in a one way hash. So what a one way hash is that when you generate a word, when you put this word into a hash function, it will generate back some sort of cryptic message or cryptic set of keys. I'll show you an example. I'm going to hash they word password1. So md5 Hash is going to return me some sort of weird information. The problem is that people out there that like to go into websites have already figured out sort of all the md5 hashes. What they did is they sat down on their computers, and they hashed every single possible word out there until they got sort of what this is. If I were to look this up-- I just grabbed this hash. If I get this hash from-- if I go into a website, and I find this hash because I get to the databases, and I look it up, someone already figured it out for me. Yeah. So people sat down, and whatever md5 hash that you put in, they're going to return to you something that is a word. If I hash another word, like-- I don't know-- trees2. I don't want to be disappointed by my Google searches. There it is, trees2. So a lot of websites still use md5 hash. They say, oh, it's secure. We're not storing in plain text. We have this md5 hash. And all I have to do is just Google the number. I don't even have to compute myself. I can just Google it, and someone already did it for me. Here's a bunch of them. Here's a bunch of passwords. So definitely don't use md5 hash, because all you have to do is Google it. So what do you want to use instead? OK. Something called salting. So what salting is-- do you guys remember when we were talking about random in-- I'm not sure what pset it was-- was it pset there or four? We were talking about finding the needle in the haystack. And in the pset, it said that you could actually figure out what random generates because someone's already ran random a million times and just sort of formed what they generate. What you want to do is put in an input. So that's what salting sort of is. They already figured out what salting returns for each work. So what salting does is you put in a salt. You put in a certain word. And it will hash that word depending on what you put in here. So if I hash password one with this sentence, it's going to hash differently if I hash password1 with a different sentence. It sort of gives it somewhere to start for the hashing to begin. So it's a lot harder to compute, but you can still compute it, especially if you use a bad salt. People have already also figured out common salts and figured out what that it is. Random salts are much better, but the best way is to use something called crypt. And what crypt allows you to do-- so these functions are already built for you. Many people forget that, or they forget to use it. But if I look up crypt PHP, crypt already returns a hash string for me. And it actually salts it many times and hashes it many times. So we don't have to do this. So all you have to do is send it into crypt. And it will create a great hash without you having to worry about salt or anything. Because if you were to salt it, you have to remember what salt you used because if not, you can't get your password back without the salt that you used. OK. And also personal identifiable information. So social security, credit card-- that's pretty obvious. But sometimes people forget the way it works is, how much information do you actually need to find some one person? Someone did a study about this a way back. And it was like, if you have a full name, you can't find someone that easily. But what if you have a full name and their date of birth? Is that enough to identify someone specifically? What if you have their name and the street address that they live on? Is that enough to find someone? And that's when they question, what is personal identifiable information, and what should you worry about not giving away? If you give away personal identifiable information that someone gives you, you could potentially get sued. And we definitely don't want that. So when you're putting your website out, and you have a really cool design, hopefully you made an awesome final project. Any you sort of want to put it out there. You want to make sure that whatever you're taking from the user, if it's personal identifiable information, you want to make sure you're being really careful with it. Shell injection. OK. Shell injection allows the intruder to get access to your actual command line in your server. And so he's able to run code that you can't control. Let's take an example of this beautiful string right here. If we go into the website again, I'm going to go into code injection. So what this does is-- it's also what we were looking at before. We're letting the user put in whatever he wants, and it will print out whatever you want. So I'm going to put a call. What this does is-- it will start by concatenating. So it will let me run whatever command the person's running before and my command. And I'm running a system command. And these last strings are-- remember what I talked to you guys about, whereas you have to encode it in a URL method. If I run this now-- I'll show you over here-- you'll see that I ended up running a command. This is actually the actual server that my website is running on. So we don't want that, because I can run-- this server is not mine. So I don't want to mess up his sister, Marcus's server. But you can run more commands that are dangerous. And potentially, you could delete files, remove directories. I can remove a certain directory if I wanted to, but I don't want to do that to Marcus. He's a nice guy. He let me borrow his server. So I'm going to let him off on the good one. So what we don't want to use-- we don't want to use eval or system. Eval or system allows us to make these system calls. Eval means evaluate. System means what I ran. It's run something in the system. But we can outlaw these things in PHP so that we don't use them. And file upload. I was going to do an awesome thing with the file upload. But like I told you guys, my file upload thing isn't working. If I were to upload a file right now-- if I were to upload a file, and it's a picture-- you have an upload thing that's a picture. That's fine. Nothing happens. But if you have an upload file, for example, and the user actually uploads a PHP file or a exe file or something like that, then you could potentially have a problem. This was working before. Unfortunately for me, it's not working anymore. If I, for example, upload this file, I'm not getting permission to upload the file due to the server not being mine. So the guy's really smart. So we don't want to-- I'm going to show you guys-- OK, these are some really cool tools. So these-- go into-- if you guys have Firefox-- hopefully you do. There's two add-ons called SQL Inject Me and Cross-Site Script Me. They open up as little side bars on the side. And if I were to go to CS60 for example-- so what it does is it looks for all the forms that-- hopefully, I won't get in trouble for this. But OK. Here's the pin system. So when I start looking for holes in the system, the first thing I do is open up this beautiful little tool on the side. And I'm going to test forms with auto attacks. And so what this does is it will slowly open up a bunch of browsers. Here's a bunch of browsers. And it's trying every single combination of cross-site scripting that there possibly is, if you see on the side. And it will give me a result sort of what the answer is. All pass. Obviously, they all pass. I mean, they're really smart people up there. But if I were to run-- I've had times before when I run this on students' final projects. I simply run SQL Inject Me with all different attacks. And it's trying to SQL inject this pin server. So if we scroll down, for example, it says-- this is good if it returns. So it tested some certain values. And the server returned a code that was negative. Remove temporarily. This is good. It tries all these tests. So you could simply run-- I wish I could find a website real quick that would let me-- maybe the CS50 store. Wow, this is going to take way too long. I'll let the first test not finish right. So it's complaining. So these are three things. These tools are free. You can download them and run them on your website, and it will tell you if you have cross-site scripting, if you have SQL, if you have something of the like. I'm sort of messing up. What's important-- OK, so never trust the user. Whatever the user inputs to you, make sure you sanitize it, you clean it, you check for the right things, that it's giving you what you want him to give you. Always be updated on what frameworks that you're actually using. If you use something like bootstrap-- I know you guys are going to use bootstrap because he's going to go over this soon in class-- and Wordpress or something like that, normally this could be hacked. And then you don't even know. You're just running your website. And it's totally secure. And you go down. So I'm fishing really early. But I want to thank Pentest Labs. I'm going to show you guys something called Pentest Labs. If you guys are really interested in what security really is, there's a website called Pentest Labs if you guys go to it right now. Oh, well, that's not it. I'm just going to run it like this. Google tells me the answer. OK. And it teaches use you-- so it says, learn web penetration testing the right way. It teaches you-- hopefully, you're an ethical person. But it teaches you how you can look at how you can get inside websites. And if you learn how you can get inside websites, you can learn how to protect yourself from getting inside websites. Let me zoom in because maybe you guys are not looking at this right. From SQL injection to shell, so sort of how I can get from SQL injection to shell. And you download this virtual machine. And the virtual machine already comes with the website that you're going to try it on. You download this PDF. And it will show you line by line what you have to do, what you check. This is what an attacker actually does to get inside a website. And some of this stuff is complicated. I wish I could go over more things with you guys. But I worry that you guys haven't really-- this is what I went over with you guys, web tests for penetration testing. Don't really know what SQL is and what-- Carl Jackson's seminar is awesome as well. You guys don't know sort of what this is. But if you go to this website, and you download these tutorials and these PDFs, you can take a look at sort of what the area of security really does in penetration testing, see how you can get inside websites and protect yourself from it. So if I make a super quick overview, it'll be prevent cross-site scripting. You want to use htmlspecialchars every time the user inputs something. Prevent SQL injection. If you do that, you're already better off than Harvard was when they got breached. And make sure your passwords are not in plain text. Make sure you don't only one way hash them but that you use crypt, the PHP function that I showed you guys. That way, you should be good. Also, if your friends let you, run SQL Inject Me on their websites. Run cross-site scripting on their websites. And you'll see a lot of these websites have a ton of vulnerabilities. It's incredible how much people forget to sanitize their databases or to make sure what the person's inputting is not script code. OK. I sort of ended really early. But if anyone has any questions about anything, you can shoot me a question. Yeah. Go, go. AUDIENCE: I just want to ask, can you explain how the file upload exactly works. LUCIANO ARANGO: Yeah. So let me show you the file upload real quick. So the file upload-- the problem wit the file upload right now is that-- I'm going to open the code so you guys see the code behind the scenes. And it is upload. Here's a code for the file uploader. We're trying to go into this directory over here. And we're trying to, once we input the file, isset file-- so when there is a file in FILES, that image, then we try to move it here. We grab the file over here. The method is POST, type, image, file. And we're sending this file. And then once we get it, so once file has an image, we're trying to send it to this directory. The problem is that the website is not letting me go to this directory, because it doesn't want me to go back. It doesn't want me to go-- I have to go-- so here's upload. Here's images. I have to go all the way back to the beginning and put it in there and then go and put it into the directory. So if I was running a terminal window, and I wanted to move a file-- [INAUDIBLE] can see it. If I wanted to move a file, I have to put the file name and then the complete path I want to send it to. And then the server's not letting me go back. And so it's not letting me get to that file. But normally-- so there's a code for uploading a file. So normally what will happen is that the person's not checking if my file ends with .jpeg, so I would want to check. Let me open an example too real quick. OK. This person right-- so example two is checking if preg_match-- here it is over here-- to make sure that ends with PHP, which is good. This is good. But there's a real big problem with this. This is good. But if I were to put a file called myfavoritepicture.php.jpeg, I could still potentially get rid of the jpeg and run it.k That PHP's dangerous. You don't want the person to be able to run code on your website. But then .jpeg lets it pass. The idea is what you really want to do is not take files, A. But, OK, what you really want to do is make sure that you read over the whole world. And there's nothing .php in it. There's no .php in the whole file name. AUDIENCE: But you could put .jpeg on the end. The servers still run the code. LUCIANO ARANGO: No, it won't run at the beginning. You have to go back and try to see if you can-- AUDIENCE: So we have to-- OK, just another set that involves-- LUCIANO ARANGO: Yeah. AUDIENCE: OK. LUCIANO ARANGO: Yeah. OK. Any other questions? OK. I'm going to leave this up and sort of try to see if you guys can-- the other ones are a little bit more complicated because they require much more knowledge of SQL than just the beginning knowledge of web SQL is and what JavaScript is. But I'm going to try to keep this up, and hopefully you guys will learn about this and try to take a peek at what you can do and how many examples you can get through. Anyone have any other questions about it? Go ahead. Yeah, shoot, shoot. Yeah, go ahead. Go ahead. AUDIENCE: OK. So I heard about how Magic Quotes are not secure enough. LUCIANO ARANGO: What-- Magic Quotes? AUDIENCE: Yeah. So it adds-- so whenever you input something, it always adds quotes. LUCIANO ARANGO: Yeah. Yeah. OK. AUDIENCE: And then I though that worked, but then I searched it up. And it said it's not good. But I'm not sure why. LUCIANO ARANGO: Yeah. AUDIENCE: Don't use Magic Quotes, because it's not secure. LUCIANO ARANGO: OK. So Magic Quotes is when you insert SQL and it already adds the quote for you. AUDIENCE: It always adds quotes around whatever you put in. LUCIANO ARANGO: Yeah. So the problem with that is that-- I'll take a look at-- AUDIENCE: How does it acquire the SQL statement? Or I guess it could be like quote select. LUCIANO ARANGO: Yeah, you need good quotes for the SQL. AUDIENCE: No, but the server does it for you. LUCIANO ARANGO: These small quotes right here, these little quotes? AUDIENCE: Yeah. LUCIANO ARANGO: Yeah. The problem is that you can comment out the last-- OK, so what I can do is I can comment out-- so let's take a look at-- let me open a text edit file. Let me just edit this right here directly. OK. Can you guys see that clearly? What I can do is I can comment out the last one. This will comment out the last one. And then I'll put one here, put all malicious stuff here. So the user's actually inputting, right? The user's not inputting the things, right? This is what I'm going to input as the person trying to get inside. I'm going to put in-- that's one quotation mark. It's just squiggly by mistake. And then what the code is going to do-- sorry, I'm going to take this out. What the code is going to do is it's going to add the first quotation marks here. And it's going to add the last quotation mark as well. And it's also going to add the last, last quotation mark. But I'm commenting these quotation marks out, so they don't run. And I'm finishing this quotation mark over here. Do you understand? Are you lost? I can comment the last quotation mark, and take care of the first quotation mark. AUDIENCE: And just finish the first one. LUCIANO ARANGO: Yeah. And just finish the first one. Yeah, that's right. That's what I can do. Yeah. Any other questions like that? That's a great question. No, yes, maybe. Hopefully, you guys will sort of make more sense when you study SQL and things like that. But make sure you-- keep these tools in watch. Sorry, these tools over here. These tools are great. If anyone has any questions, you can also email me. This is my normal email. And this is my work email, which is when I work at SEAS. OK, thanks. Thanks, guys. You're good to go. You don't have to stay here. Don't clap. That's weird. OK, thanks, guys.