 So, we know how to secure our communications between browser and web server using HTTPS. And in fact, HTTPS is really HTTP on top of SSL, Secure Sockets Layer, or TLS is the other name. And one key part of that is that making sure that we know the correct public key of the server. We talked about digital certificates last week. Now we look at a different aspect of web security and some of the common attacks that happen on websites. Many communication-based applications today are based on web applications. So they use a browser and there's some server that implements the back end. And many security flaws and attacks today take advantage of flaws in those applications. So we'll look at some of them today and in this week I think. So first we need to just remind ourselves, what do we mean by a web application? I have a simplistic view of a web application. And we mentioned this last week, this diagram's copied from the previous slide from last week. Okay, our web browser talks to a web server using HTTP, sending requests, getting responses. But most websites today are not just some static HTML and some images, they are some dynamic content and they usually they use some, I'll generally call some engine that executes some code based upon the request they get. And sometimes a database that stores a set of data and that data is used to adapt the response that's sent back. So most of you have developed these dynamic websites by, for example, using a web server, an engine like a PHP interpreter, so you write PHP code. And that can send back dynamic content. So it changes the HTML depending upon the request. And often you may have extracted data from say a MySQL database. So the PHP extracts the data and that data is formatted and sent back to the web browser in the response. So this is the concept that websites are dynamic, that we use some engine to process the request they received and personalize the responses. So let's come back and look at HTTP and see how those web applications are implemented. And just remind ourselves that HTTP is what we call a stateless or originally designed as a stateless protocol. What that means is we have requests and responses. Stateless means that when the server receives a first request, it sends back a response. It doesn't need to store any information about the previous request response for the next one. There's no state information maintained about what happened in the past. The next request that the server receives is processed independently of the previous ones. That's what we mean by stateless here. It makes the server very simple. You don't have to store in memory any state information about what's happened. So the response to the second request in the simplest version of HTTP is that the response doesn't depend upon the first request. So in this case some browser visited the website, the server sent back some HTML saying welcome to our website. When that same browser visits the same page again, the server sends back the same message because it doesn't know anything about the previous visit because there was no state information stored. So that was the original design of HTTP. Of course, many web applications today would like to have more advanced interaction with the user. For example, the second time we visit the site, the server sends back welcome back to our website. That's an example of we'd like the server to adapt the response based upon what happened in the past. HTTP didn't originally have that feature, but we need it for things like personalizing the responses. So when my browser accesses a website, it sends back welcome Steve. When your browser accesses the same website, it says welcome to you. So personalized response based upon who's accessing, but accessing the same URL. Cation management, things like manage logins, allow someone to log in and it gets similar to the personalization to give them responses based upon what they've done in the previous visits. And tracking websites will often want to track what the users are doing so they can gain statistics about who's visiting, how often they visit the website so they can tailor and adapt their content based upon those statistics. So how do we take HTTP, a stateless protocol and provide some state such that the web server will respond differently depending upon the previous ones. So this is the example, this is the concept that we would like with many web applications. Browser X sends a request to the server. Server sends back a response, welcome. And then we'd like the server to store some state information saying something like browser X visited our website at 11am on the 12th of February. So store some information about what just happened and the next time browser X visits the same URL, the server checks that okay this is browser X again, I've got some state information saying they visited at 11am so in the response that I send back the response will depend upon that state information saying welcome back for example so the message that it sent back in the response changes depending upon what happened previously. So that's a typical very simplistic view of personalizing the response based upon the state information and maybe browser Y visits the same website and because they haven't visited in the past, the server has no state information about what browser Y did, they get the basic response just welcome. Okay so the idea is that the server will store some state information. We'll see how in a moment. So we can personalize responses, we can have login sessions. So an example is that there's a login page. The browser sends a request for the login page, the server sends back the login page which is a form, an HTML form has some boxes where you can enter in a username and a password and you press the button submit. So that's this page here, enter username and password is the meaning of the response. The user enters in their username and password and one way to implement that in HTML is you send a post. Instead of get some page you use post as the method. You submit the username and password in the request to the server. The server stored state information about the previous visit. When the server receives this submitted username and password, it compares against some stored value, maybe stored in a database. They're pre-configured for that user. If they match, that is if the user is authenticated, then the server sends back a response say welcome Steve. Because it now knows who the web browser is or the human user at the web browser based upon the username they submitted. And then we store some information at the server saying, browser X is logged in as Steve. The next time browser X visits, let's say some other page results, to view some results of students, the server checks Steve or browser X is already logged in. We don't need to ask them to log in again. That would be inconvenient to ask the user every time they visit a new page on this site to supply their username and password. So we'd like it such that, okay, browser X is already logged in. Since the server knows that, no need to re-authenticate, no need to check the username and password, send back a response saying a specific response for that particular user. So again, we need state information at the server. And in this case, we're using it also to do some authentication and to track who's logged in. Of course, if someone else, browser Y, tries to visit this results page, what should happen is that the server sends back a message, you are not logged in. Okay, so again, based upon what's happened in the past, the server tailors its response. And you use this in many websites today. So it's just this concept of storing state at the server. How do we implement that? So that's what we want to do. How do we implement that? Who has implemented features like this in websites before? Anyone? I know most of you did database systems and you created a website with PHP, correct? Anyone create log-ins? No one created a website, created log-ins? How did you implement that login? Use a session. Yeah, PHP, I think if you use PHP, has this concept of a session that the server. So PHP, how does it store this state information? It has this concept of a session. So we can think of this state information as session information that keeps track of who has logged in, who has accessed the website. So session information or state information is used here. Other languages have the same concepts, okay? So different interpreters can maintain this state information for us. So the normal web server doesn't do that. The engine on that server does that maintenance of state information. So I think most of you have done this. So just summarizing the concepts. But what else do we need? If the server maintains the state information, how do we know that the, how do we identify the browser? That's another thing that we need to know. So in particular, not just the browser or the computer that's browsing, X or Y, but maybe the user that's using that browser. So when someone sends a request for get results.php, the server needs to know that it came from the same person that logged in previously. It's not from someone else. Maybe someone else is using the browser or it's from a different computer. And how do we keep track of that using this concept of cookies? So we'll talk about and go through some examples of what we mean by cookies in a very simple description. We won't look at many of the details and see that cookies combined with the state information of the server is what provides these features of personalization and session management. And if you use PHP and the session features of PHP to create your website, then that usually creates a cookie for you. There are other ways to do it, but you can create cookies with PHP and other languages. So a cookie, what is it? It's a data structure. A data structure, a simple data structure that stores some name value pair. So the name of the cookie and the value that it takes. And some date information, date time information saying when this cookie expires, the path refers to the path in the URL where this cookie is valid for. If the path is slash, it means that this cookie is valid for this entire website. If the path is slash ABC slash, then it means it's valid for anything in that sub directory. The domain, so a cookie for www.abc.com would be valid for that domain. And then a few other flags to indicate whether this is needed for secure web browsing or not, or whether secure web browsing is needed for this cookie or not. So we'll see these explained through some examples. Let's use this to explain this login implementation using cookies. So again, the user wants to log in. So they visit this login page which has some code to send back a form saying, please enter your username and password. The user types in their username and password in the browser, presses Submit. That sends a post message to the server, including the username and password. The server checks the submitted values against, let's say, some value stored in a database. If they match, let's assume they match. It's everything's okay. Then the server stores some state information or some session information. Often we refer to it as session information. For example, it may store somebody username equals Steve, the logged in user, and some other information. And sends back a response saying welcome Steve because they're the ones that's logged in. But including in this response message is the cookie. It's a data structure including values which will be used in the subsequent requests. Will be used to identify the user that's browsing to this web server. So in this example, the session information is the username Steve and some ID hash. Well, we'll see another example of this later but some, let's say some hash of a password and some other secret information. But simple hash of a password. And the cookie contains in this case a name, username. They don't have to be the same here, but usually are. Username and the value Steve and some other information which I haven't shown here like the expiry time. And a second cookie, ID hash and this value the same as here. So this information is sent from the server to the browser. The cookies are sent to the browser. The browser stores those cookies. So the browser stores them locally on the computer. And the next time that browser visits the same domain and the path of the URL matches the path in the cookie. The browser sends the cookie to the server. So in this case, we're visiting the same server, so the domain matches. Remember the cookie stores the name and value, username and Steve, for example, a time and date, but a path like slash and a domain like abc.com. If the browser visits that same URL again, the path matches, then it sends back the cookie in the request. And now what the server does when it receives this request, instead of having to authenticate the user again, because the cookie information matches the session information, it knows who is accessing this website. And it assumes they're logged in because it's the same usernames, the same hash value here, and therefore it doesn't have to check the username and password again, it just checks here. So in the authenticate user step, we had to check the username and password against some database. But in this step, when we receive the cookie, we just check it quickly against the session information. Implementation-wise can be much faster than checking against the database. And we're just checking the values, direct comparison. We don't have to look up a password and calculate hashes. If they match, assume they're already logged in and therefore send back a response tailored to that user that's logged in. So cookies are one common way to implement this login capability, this session management. In this example, there are other ways to do it, but in this example, the idea was that the hash value here would be unique for this user. So we send that back to the browser. When the browser requests to the website again, it includes that value. So the server identifies who is the user. If someone else tries to visit the same web server, they won't have this value. Because they may be able to guess the username, but they can't guess the hash value. Therefore, they would be identified as someone different and would not be logged in. So the idea of the hash is to make a value that only the person that logged in will know. And every request from the browser to the server from now on includes this cookie. All the subsequent requests. And that's how the server identifies that browser. When you close your browser, what normally happens is some of the cookies are deleted. You can manually do it. So maybe you're on a public computer in a lab. You close your browser. If the cookies are deleted, someone else opens the browser and visits the same website. The web server will assume you're not logged in anymore because you didn't send the cookie in the request. So the idea is if you have the cookie, you'll be identified as the user Steve. But if you don't have it, the web server will know you're someone else and require you to log in again. That's the basic concept or an example of the use of cookies. There are other ways to implement this session management are logins. This is just one example that we'll use. All right, so these three steps just explain what we did in that example. We normally, the web server creates the cookie when you first log in and sends it back in the response. The web browser stores the cookies. And whenever they visit the same domain and the correct path, they will send the cookie in the request. And from the received cookie, the server knows who you are. So we'll identify the browser. Some issues with cookies. How long does your browser store them? There are different approaches. Two common ones are you have what's called session and persistent cookies. A session cookie, the expiry date in the cookie is usually not set. That means that the browser will normally delete the cookie when the browser closes. So if the server sends back a cookie with no expiry date, then the browser assumes that's just for this session. You close the browser, the cookie will be deleted by the browser. That depends upon the browser, but that's the common feature. Whereas if there is an expiry date set, then we can think of that as a persistent cookie and that will be deleted when the expiry date is reached. So let's say the cookie is valid for one year, your browser will store that for one year and every time you visit that same website, the browser will automatically send that cookie. Identifying you to the web server. Of course you can manually modify them in your browser usually. Delete them, for example. We'll see the cookies, why we're introducing cookies, because we'll see the use of them and lead to some different web attacks. So that's the focus of this topic about the web attacks, but they'll make use of cookies. One of the issues is that when you visit a website, the URL is www.abc.com, many web pages have links to other websites. Not just links, but they get images from other websites. They get content from other websites. So it's not just all the content from one web server. The domain of the cookie, the domain that's included in the cookie, if it's the same as the domain in the URL that you visit, it's called a first party cookie and usually considered more trustworthy than other cookies. So if I visit www.abc.com and the cookie is from that same domain, then my browser will trust that, more than if I visit abc.com, but the cookie is for some other domain, like ads.com, then your browser will treat that as a third party cookie and depending upon the policies of your browser, it may not trust that cookie or maybe not accept it even because these third party cookies are often used to track users as they visit different websites. So there are some privacy issues. In our next topic or our last topic, we may return to some of the privacy issues with cookies and other forms of tracking. There's a field in the cookie that says, is HTTPS needed? It means if it's not set, this cookie can be transferred using either HTTPS or HTTPS. If it is set, then this cookie must be transferred only using HTTPS. Don't send it unencrypted. Because if someone can find the cookie information, they can log in as a different person. And we'll see that in an attack. If someone knows the username and this hash in this example, some other browser knows those values. When they send a request to the server, if they include those values in the cookie, the server will think it's Steve that's logged in and send back a response for them. So one way to stop that is to encrypt all the communications using HTTPS so that no one, or it's much harder to find these values. We'll see some examples of that. So that's just the introduction of cookies and session management. A quick example of how to manage sessions in web applications. Because we'll see that many attacks attack these features. Any questions before we move on to the attacks? Let me just remind myself what handouts I gave you. We'll show you an example of cookies in a moment. Let's just introduce this next concept. So we want to look at if you need to develop a website, a web application, how do you make it secure? Because many attacks today take advantage of insecure web applications. I'm not going to focus on web application development. I'm not going to require you to do any programming. We're just going to talk about some of the common attacks that happen on websites. Show some examples of those attacks. Talk about some of the ways to prevent them. But we won't go into the details of how to program the websites to be secure. You need to study the different languages and so on, and many different features to do that. So we'll just talk about the concepts of the attacks. So we'll go through a list of different attacks on websites. And the list that I'm going to go through comes from this organization called OWASP. What is it? The Open Web Application Security Project. And included in your lecture notes is eight or nine pages from one of their documents that we'll go through. I cut out a few pages which are not so useful, but it's all available on the website. I'll show you shortly. But this is an organization that monitors different attacks on websites and produces a top ten list of the risks on different web applications and many other features and material about how to develop secure web applications. So let's just say who they are and then go into the attacks. So OWASP is this Open Web Application Security Project. So it's a group of people got together to try and promote developing secure web applications. So they wanted people to create better web applications. That's the idea. So it's a not-for-profit organization called OWASP. All of their resources, the document that you have and all the other guidelines that they provide are free on their website. They include tutorials of how to develop secure websites using different languages, cheat sheets. I'll show you a few of things like passwords. How should you manage passwords? The best practice in storing passwords and transferring passwords across the Internet. This top ten list of risks for web applications which we'll go through. Methodologies, they provide code and so on. If you want to develop a website using some login system with PHP, they provide some sample code that you can use. So it's a lot of resources available on the website. The top ten, the organization, every few years they've developed or released this list of the top ten what they think are the risks of web applications. So things that can go wrong. What they do is they collect data from different companies, seven or so companies collect data about attacks that have occurred on hundreds of other companies. So they collect data from many risks and vulnerabilities in web applications from many different companies, organizations. And they collect all that data and they come up with, well, which attacks are the most prevalent? Which happens the most? And what are the most dangerous attacks? And they come up with this top ten. And we will go through them using a few examples to demonstrate them. So this is the top ten from 2013 starting from Injection, which we'll look at. And we'll explain each of them. Poor session management. So the session management example we quickly went through. If that's implemented poorly, someone may be able to log in to your website when they shouldn't be able to maybe to access resources that are not authorized to. Talk about cross-site scripting and these other ten risks. So let's go through them. We'll go through some of them in more detail than others. So in the subsequent slides we list examples of each but the details are in this handout that I've given you. So each risk is on one page at a time and most of the information on the slides just comes from this handout that you have in front of you. Note that most of the risks in websites are due to either poor development that if the person who implements the website has not done something correctly or poor configuration, maybe some software has not been set up correctly. So it's often due to the developer that the risks arise from not necessarily from bugs in the software, some are due to bugs but many are due to someone's implemented something using a poor, a bad approach. There are better approaches that they should have chosen. Some of them are due to bugs or software vulnerabilities. For example, if you're creating a website and you use someone else's software, someone else's code, their PHP code for example, and that has some bugs in it then that opens your website up to some bugs and a potential attacks. The OWASP website has many details, many more than what we can cover. So if you're creating websites I highly recommend using it to learn about how to implement the different things we talk about in different languages. They talk about using Java, PHP, ASP and other languages. So let's go through several attacks. Before I describe them, I'm going to use a demo to illustrate several of them. I've created a virtual network. You're all experts at this. I don't know if you'll have to do it again this semester but I think you've worked out how to create them. You've overcome some of the bugs in creating virtual networks. But I've created this topology with five nodes. I've got it on my computer. We're going to have a browser. So the normal user is going to access some website. This node four is our web server and www.myuni.edu. That's the website which is going to allow the students to view the grades. They log in and view their grades, just their grades, not other people's grades and allow the faculty members to log in and view everyone's grades and even edit the grades. So change the grades. That's the basic functionality of this website. There's going to be a couple of other nodes which are going to be malicious nodes. We'll use them in some of the attacks. So there'll be a malicious browser, someone who wants to log into the web server or do things that they're not authorized to do. For example, a student wants to view the grades of other students. We'll see an attack where they can do that. And we'll see a case where the malicious user will use another server under their control to perform some attacks. So five nodes I need in this topology, but not all of them at the same time. So think of it simply as four nodes on the internet. Two web servers and some people using web browsers on the internet. There's a router in here, but that's not relevant for the concept here. It's just for this demo. So I've created a very, very excellent website for my uni.edu. Let's visit the website. And I'm going to open up node one. So here's my node one. I'm logged in on my virtual node, node one. And I want to visit the website. What web browser am I going to use? My favorite web browser. My web browser. What web browser am I going to use? Firefox. No, that's not my favorite web browser. I've got a better one. Firefox, maybe your favorite web browser. I've got one called links. And I type in some domain. What is it? Myuni.edu. That's the website I want to visit. So I open my browser. We'll use Firefox a little bit later. Just for this demo, I need to configure this browser. It takes a configuration file. This is not so important. So use links. There's my web browser, links, and it's going to visit this website. And we'll see the website. The configuration file is just to set this up for the demo. Links is a text-based web browser. There's no images that are going to be displayed. No JavaScript. No dynamic features on the client side are possible. It's just a text-based web browser. Why use it? Well, in these virtual nodes, we don't have a graphical interface. I can't open Firefox on these nodes. The other reason I'll use it quickly in this demo is I can easily manipulate the cookies that we'll use in one attack. But in a moment, we'll revert back to your favorite, Firefox. We can still use that. But just for a quick demo, we'll use links. I want to quit. And actually, the website I want to visit, the path is grades. Okay? And I'll show you this website. I'm already logged in. That's bad. Let's quit again. I tried this morning. Okay, here's the front page of the website. It's got a welcome message and a login button. So with links, you just scroll through the actual links. So by up and down, these are links to other pages. Okay? So the welcome page, and now I log in. So I follow that link. And it provides me a prompt for a username and password. And let's log in as a particular user. And this demo is set up that there are several faculty users and several student users. So I'll log in just to show you the features of the website. And then we'll do some different attacks. Everyone likes links? We don't have to use links, okay? We'll use it sometimes, but we can use Firefox. So let me open up Firefox. It may be easier to see. Okay? Now, I've set this up so that my Firefox on my host machine is actually going through the Node 1. So it's pretending to be running on Node 1. Because remember on these virtual nodes, there's no graphical interface. So this is actually a Firefox, not in my virtual machine, but on my computer. So I had to do some special setup for this to work. That's why links sometimes is easier. Okay, here's our website. Let's log in. And so I know the usernames and passwords. Let's log in as a student first. So some ID. That's just one of them that's set up. And some password. And we log in. And now it says welcome to this student. Okay, it's very basic. And it allows them to view the grades. So if you're not logged in, you shouldn't be able to view the grades. So just the functionality of this website. We can view the grades. And the way that this website allows you, as a student, to view the grades, you type in your ID here, and you can select the course. Okay. If you don't enter a course, you'll get all your grades, actually. So ITS 335, B+, okay. So the database stores a set of users, their courses, and grades. And it should be such that a student user can only see their grades. A student user cannot change their grades. That would be not so good. And a faculty user can see everyone's grades and can change their grades. That's the requirements for this website. If we try and... I'm logged in as user this five all zeros. I know there's another user on here with a different ID. If we try and view their grades for IDS 335, right, returns an error saying you can only view your own grades. So it works in terms of security. This website is designed such that one student cannot see other students' grades. And so I've implemented some simple PHP to try and do this check. If I log out, I can log in as someone else and view grades. I don't have any, but other users do. And many. And if I don't enter a course code, it should show me all their grades. So this user has grades for two courses. And if I click on their ID, I can change their grades. Okay, so they currently have a D. Let's change them to a C+. And just check. It's not very easy to use, but it works. So now this user for CSS 322 has a C+. So that's the features of the website, the intended features. We want to do some attacks on it so that we can defeat the required security features. First, let's see how the cookies are used. And this is where I want to use... Actually, we can do it in Firefox. If we see up here, we can see information about the web page. And one of the options is we can view the cookies. No cookies on this one. We've deleted them. I've deleted them so it doesn't work on this Firefox. So that's where I'm going to use links to view the cookies because we can edit them in links. Just for this demo. So let's log in again as a user. Logs in. And when I quit the browser... Yes. I've set it up so that the cookies are actually saved in a file. So here are the cookies that my browser saved in this case. Normally that's not the case. I've set it up just for this demo so we can save and look at the cookies. So this is the cookies of the browser. And the links browser stores them in this simple text format. So the domain, the path is a slash, the false. The two falses are the two flags. One's for HTTPS saying we don't need HTTPS. I can't remember which one. And one's for another feature of what that second feature is. I can't remember. But two flags used in the cookies. HTTPS and still can't remember. This is the time and date. But in a format which is usually from some original date in seconds. So this is just an encoding of the expiry date and time. This is the value of the cookie username and then we have the name of the cookie and the value is the ID. And the second cookie ID hash is this other long value. So what's the first attack I'm going to do? Give us a simple attack. What can you do as a malicious user maybe on a different web browser to defeat or to attack this website? Login, but all the users that know their username and password can log in. That's a normal feature. But what about the attack that maybe you can access other people's content? Change content. Sorry? Intercept what? Intercept the cookie. So remember the way that the cookie works, this is on the browser. Every time the browser accesses the website it sends this cookie information. And when the server receives this cookie information it knows who the logged in user is. So that's the one whose username or five with all zeros. Now if someone else can learn these values and set those values on their web browser to be the same then they could log in as that user. So the first attack and one of the simplest ones is steal someone else's cookie and log in as that other user. How do we steal someone else's cookie? Intercept? How can we intercept? So when I logged in what happened is the browser sent a request to the web server it sent back the login page and then the browser entered the username and password and eventually the cookie was sent back and in every request every subsequent request the cookie is sent from browser to server. So how does a malicious user going to intercept? How do they learn the cookie value? Capture? So if we can intercept somewhere in the internet where those packets go via we can capture those packets. That is we send a request across the internet if somewhere in here maybe at a router somewhere we can record as a malicious user the packets being sent we're not using any encryption just using HTTP and then we can intercept the requests and see the cookie and then take that cookie value and use it on our browser. So set up our browser to use the cookie of the other user so that from our browser the malicious user's browser when we access the website the website will identify us as the normal user that was logged in. So we need to intercept somewhere and server. Say we are malicious and have access to a router. Maybe possible. What else could we do? If we can't intercept in the internet we don't have access to capture packets across the links in the internet here what's another thing that could happen? Where could we get the value of the cookie? From the user's browser. So if somehow as a malicious user we could read the contents of their browser we could take their cookie steal their cookie. How can we do that? Well, if it's a public computer and someone logs into a website and they don't log out or the cookie is stored as a persistent storage and it's still stored on the computer then the next person who comes to that computer could get the cookie value and then they can log in as the previous user. So that's why browsers usually when you close the browser they delete the session cookies so that someone else who opens the browser does not have those cookies. So we either need to read the cookie from the browser or intercept it somewhere between being sent between the browser and server. The interception in our case we have the router in our virtual network we have a router so if we when the browser logged into the server if we captured packets here we would capture all the packets sent between the browser and server. And I've done it before and you have a printout I think towards the end of the lecture notes of the capture. So I'm not going to do the capture now I'll go direct to the capture I've done before have it somewhere. You have a summary of this in your lecture notes if you cannot see on the screen but it's just from Wireshark and I've shown, let me just check it's at the end of the slides before the OWASP document. Just a single page picture which summarizes the main packets of this capture. And it's a capture of a browser logging into the website and we'll just filter for the HTTP packets and see what happened. The first request was that the browser sent a request for the grades, the base website. The server sent back a response then they clicked on the login button to login so they requested the login.php file the server sent back the login form to fill in the form so when the user on the browser filled in the form and pressed submit the browser sends to the server this post message sending the username and password that they typed in the server checks them against some database the PHP code checks it against some program values in a database and this 302 found is not an error that's just how it's implemented it redirects back to the index page if you logged in. So it authenticated and once they were logged in it sent the user back to the main index page so they've come back to the front page and they should see the welcome message so let's look at first the cookie information in some of those packets so the post message so if you're an attacker and you could capture this what's some things you could do what are some malicious things you could do if you have this capture from a real interaction what's the first thing you'll try find the username and password the person submitted remember there was a form this packet here if we look at it if we look at the content that was sent by the server to the browser it was a form some HTML saying username and a box was displayed using this form field input and the password so this was the form the user filled in username and password and that triggered the browser to send the values of username and password in this post request so you've seen my password when I logged in my username and password was sent in this request so the first attack if you can intercept this just intercept the login procedure and you found the user username and password how do you stop that attack HTTPS so encrypt the data instead of using HTTPS for the login you should be using HTTPS so that even when this information is sent to the server it's encrypted so someone who captures cannot see the username and password what's the problem of using HTTPS why didn't I use it apart from the demo some websites not use HTTPS do all websites you visit use HTTPS many of them do not HTTPS introduces some overhead so the server must do some processing the encryption so if there's many people visiting that slows down the responses it takes some setting up on the server but not too hard it requires certificates so there is some cost involved in setting up HTTPS and it does slow down the communications a little bit so I think you know most servers don't use it but many websites will use HTTPS just for the login so the login page and the submission of the information is encrypted using HTTPS but once you're logged in the subsequent requests are using normal HTTPS because it's much faster just use the encryption on the login page so someone can't intercept the username and password use unencrypted communications for the rest okay so one attack, find the username and password there but let's say we couldn't let's say this was encrypted this packet what's the response so we logged in when the server receives this request it checks the username and password against some database so I've created a MySQL database on the server and it checks the fields if they match then everything's okay and it sends back the response and we look at the response and in the HTTP header there are two values called setCookie these are the cookies being sent from the server to the browser so once the login was successful the server sends back a response page it's actually a redirection to another page but included in the HTTP header is a cookie so setCookie, username the expiry date and the other fields in the cookie the domain and path and the second cookie there are two in this case one's username, one's ID hash in this demo website ID hash is created from hashing the password and some other secret value so it should be hard for someone to guess what this would be, to predict this unless they have logged in that's the idea there so this is sent back to the browser when the browser receives these values it stores them in its list of cookies the next request so the next request from the browser to the web server includes those values it doesn't include the expiry time it just includes the username and the value ID hash and the value there so the request now from the browser to this same website will always include this cookie value ignore cookie too, that's just something that the links browser did about the version being used but this is the actual cookie here being sent and when the server receives these values the session information that was done in PHP checks these values against what's stored for the session and if they match assume that they're logged in and send back a response assuming they're logged in if they don't match assume they're not logged in that's how it's implemented so if you if you could not capture the username and password another opportunity for an attack is to capture any of the requests that contain the cookie because each subsequent request contains the cookie so even if the login was encrypted if the other interactions with the web server are not encrypted using HTTP the cookie information is still sent in the request so someone who captures these values can set up the web browser to use those values as a cookie and login as someone else can we do it so I'll try again this is our browser we're logged in as user with all zeros five with all zeros this is the normal user if on my malicious user if I know those values then I can so this is on node two a malicious user their browser they can set their cookies now to set the cookies I need to set the file to be the same as this where the username is the values that is from here or what was captured from the TCP dump to do it quickly I'm just going to copy this file from node one to node two so assume that the malicious user the red one has learnt these values then they set up their browser to use those values and in my case on node two let's copy and links the web browser uses this specific file that's why I'm using links just for this demo and just copy and paste the values I need to select everything so on the malicious node if we have those same values save that file actually the other thing with the copy and paste these should be tabs instead of spaces the format of the cookie by this browser is that it should be a tab here so you must have it exactly the same format that the browser takes and then let's try so we have on the malicious node if we capture those values we can set up our browser to use that cookie save them and now open our browser to use the config that will load these cookies and visit our website and I'm logged in as user five or zeros so just by stealing that cookie I've automatically logged in as the user that cookie belongs to so a very simple attack and involves obtaining the cookie of someone else how do we stop that how do we stop someone stealing your cookie well if you're looking across the internet if someone can intercept any way between you and the browser then in theory they can capture and record any values so the only way to stop it then is to use encryption make sure all of the communications are encrypted so if you use HTTPS someone who could capture will not be able to find the cookie value so use HTTPS all the time not just for logins but because the overhead of using HTTPS it slows down the website sometimes so you cannot stop it in that way in theory someone can intercept and get the cookie but in practice it's often hard to intercept someone's browser's communication to a web server you need to be somewhere on the network in between the browser and server so it's possible but it's quite hard to do that in some cases let's look at some other attacks or another attack on this website so obvious one is still the cookie but let's say we cannot intercept, we're not using HTTPS but the malicious user doesn't have the ability to intercept the packets sent between the browser and web server so what else can they do any suggestions let's say they cannot physically go to the browser and open it up they don't have access to that computer what else can we do any other ideas fish go fishing, what would they do there create a fake website okay and so let's say we had a fake website here malicious user and then what would you do create a fake login so that make a fake website here that looks like our grades login you need to somehow trick the user to visit that fake website okay so there's another attack let's say send an email to the user here saying you need to log in and update the grades and there's a link in there and the link takes us to this website it looks like a link to this one but it's actually not and the user doesn't notice it's a link to a fake website so yes that's one way and we can see a demo of that but we won't do it at the moment quite easy if you can redirect them to another website that is that looks like the original one then the user may be tricked into logging in and when you log in you see there the fake website can capture the username and password now let's say that the user when they receive an email they're smart enough to log in oh sorry smart enough to check the domain when you get an email you should check the domain at least and make sure it's the right one let's bring back our firefox one log out actually today some students someone sent me an email Dr. Tanarak sent me an email okay can I zoom send me an email saying he wants me to log into the website and update but I'm reasonably smart I'm not going to fall for a phishing attack so I check the domain is this the real website http wwwmyuny.edu okay this is the real website I trust this link so follow the link I'll copy it and paste it into our browser follow the link okay log in maybe I entered my username and password wrong log in again okay I'm logged in I can view the grades okay and I can do all the normal things that I would need what happened anyone see it yeah yeah what what did you see what happened there we'll see what happened first let's see the result of that attack and it's similar to the phishing but a little bit of an extension the malicious user actually has a fake website web server here and down here the domain that they have is www.myuny.edu.gr okay it's not the real one it looks similar and you may have noticed that in the address bar I didn't as the normal user but on that node 5 it's here somewhere the malicious user on node 5 have their fake web server and one thing that fake web server does is when someone logs in it stores the usernames and passwords of the login in this file stolen logins so how did it do that the fake website was set up such that it provided a login page that looks like the grades login okay and when I typed in my username and password I press submit the website didn't do anything except store those values write them to a file and then redirected me to the real login page so as the user I thought maybe I typed in my username and password wrong so I typed in the first time I pressed submit and it redirected me but what actually happened is that that fake website stored my username and password let's try it again and see how that worked and it's a redirection attack let's bring up the email again I think some of you noticed the email the URL in here the domain is correct okay when I check as the reader of this email is this link taking me to the website that I trust yes it is because I know that www.myuni.edu is the real website for my grade system so I trust this the rest is just some parameters in the URL I'm not an expert on web browsing so ignore the rest but you may notice grades there's a PHP page called redirect some websites have such a feature that they use a page to redirect you to other links either to external links or to internal links on the same web server for example some websites when you click on a link to another website will actually redirect you to a page saying you're now leaving our website and you're entering someone else's website just to inform you that you're leaving their website so they perform this redirection so it's a common feature in some websites so this grade system has such a redirection page but what the malicious user has done is use that redirect this ID is just some fake value just to fill in the space just to make it look like to the user that there's something useful there's not but the real parameter of the redirect is the URL here which goes to this fake website which is this edu.gr ads grades.login the idea here is that the malicious user creates a URL that has the correct domain name the domain name of the trusted website so a reader of this URL would either hover over the link and see the domains correct or maybe software that checks the domains would see it as correct it's trusted but actually when you click on the link what happens we copy the link again the domain is correct but it's actually this feature of this grades website that redirects you to another domain and in this case the malicious website when we click on it it did the redirect and it redirected to now as the normal user I don't check their address bar here because it looks okay and the link was okay at the start so I log in this web page is actually a fake web page on the malicious website on this URL that looks similar to before but it's different so what happens is that when I type my username and password and press log in the PHP code behind this page just writes those values to a file so that the malicious server knows the username and password and then redirects me to the real login page so as the user I don't think anything's gone wrong maybe I mistyped my password so it just takes me back to the login and then I log in to the real page so this is an extension of the phishing attack that uses this redirection feature so many websites will include a redirect feature but if that's implemented poorly a malicious user can use the redirect to redirect you to some fake website making it less noticeable to you I think it's the 10th attack in the list so if you I'm not open it now but this redirect.php all it does really is read the URL parameter and sends you to that domain so maybe it's a page that the grade system uses to redirect to external websites but here it's used the redirect is a valid page but it's used by the malicious user to hide the fact that it's redirecting you to a malicious website there's one attack it's the 10th attack I think is it in the list we'll come back to them unvalidated unvalidated redirect and forward that's the type of attack the 10th risk in the list by the gossip is that the we have a redirect feature in the website but the URL that it's provided wasn't checked it wasn't validated so to avoid such an attack we maybe need to implement this redirect.php so that we check should this website be redirecting to this other one maybe we only have a list of sites so you need some way to stop that so it's harder for the attacker questions on that attack a redirection we've seen several simple things so far one is capture the username and password well that's normal if you don't encrypt a username and password if it's sent across the internet someone can capture it second capture a cookie as the cookie is sent across the internet record a copy of it and use that in your malicious browser and that allows you to log in as someone else and this attack was a redirection where it's combination of tricking the user into going to another website and this other website looks like the real website and in this example the trick was taking use of this redirection feature of the real website so it's less likely to be noticed so far the validation or the redirect was risk 10 on Thursday we'll come back and revisit this one but we've seen an example of that sensitive data exposure we'll come back to that but one of them is sending passwords in the clear across the internet so sensitive data exposure is making important information readable by others and one example is if you have a username and password sent across the internet you're exposing that sensitive data to others someone can intercept same as cookies if you don't encrypt the cookies you potentially expose it to someone to copy on Thursday we'll look at the first one an injection attack an SQL injection as a specific example but we don't have time to start today so let's stop there and so Thursday we'll go through and then describe in general the others but not with demos any questions to finish today you can try these attacks the demos that we're going through you can create your own virtual network and I've got some instructions I'll put them on a website soon to do those attacks and set them up let's continue those injection and CSRF on Thursday