 yesterday, not yesterday, Wednesday, when we did some things in the lab about accessing websites. I think you may remember what we did. We accessed some websites and then we saw in the packet capture some DNS requests. So you see when we accessed the SIT website there's a DNS request for www.sittu and so on. And in fact, what some web browsers do is that when you access this website, the web browser looks through the web page for all the links to other domains and automatically triggers requests for those. So sort of predicting that you may click on this link and instead of having to do the request then, it's done the request already. So it already knows the IP address. So the web browsers may do many requests and some students, I think in your section you would have seen many DNS requests and on the Monday, sorry on the Wednesday morning section, someone saw many different requests to strange websites and then they looked in the source code of the SIT web page and if you look in the source you'll see links to different websites but they saw a strange request and I'll show you. I've got a screenshot of what we saw inside the SIT web page. The source code for the SIT web page contains these links in there. This was in the SIT front web page. Right and this was noticed in the lab because we saw the DNS request for these websites which should not be in the SIT website. Someone had compromised the SIT website. Okay so someone had, in somehow, I don't know we only discovered on Wednesday, someone had inserted these links inside the SIT front web page. They've been removed. We let the computer center know and they've been removed since then but the topic of this attack is to look at how attacks occur on websites and how someone may compromise a website and maybe insert information onto that web page that shouldn't be there and even do more dangerous things. Delete data, steal data and do different attacks on websites. So this topic is about the different types of attacks that happen on websites. The intention is not for you to do the attacks. The intention is for you to create better websites such that the attacks are not possible. Okay so we'll go through some examples and tomorrow we'll do it in the lab so we'll do some explanations today. Tomorrow in the lab you'll do some of the things that we cover and introduce today. So let's look at some aspects of different attacks on websites. To understand a lot of the attacks we need to understand how websites are developed, the implementation. So first we'll just recap on what I mean by a web application and again I think you know this. You've created PHP based websites. Some of the examples we'll use are using PHP but they could be another language. Java, ASP, other languages are used for the websites but for simplicity we'll use PHP as some examples because I know you know that. So here's a model of a dynamic website. By dynamic I mean that the content that's served by the web server may change depending upon the request. So focusing on the communication between your web browser and web server, the web browser simply sends HTTP requests to the server. The server sends back responses. So that's what's communicated across the network. In a simple website there's just a request and if the page exists it's sent back in the response. But a dynamic website, the web server will tailor the response according to the request. So I try and illustrate that here, that the web server may use some engine, some processing engine like the PHP interpreter and maybe even a database that stores data or information and what commonly happens is someone sends a request for a web page. The web server uses that engine, say the PHP interpreter, to execute some code, possibly read some data from the database and then create on demand a web page that is then sent back. And the result is that the web page that sent back may change over time depending on who's making the request, what they've done in the past. So I know you've all implemented such websites already. Have you implemented a login based system, anyone, where someone types in their username and password in a form, it's submitted and then the PHP code checks the username and password and either logs them in or not. So you may have done that and other processing using PHP. So that's our web application. We want to see, well, how could you create that application so that it's hard for people to do a tax? That's the purpose of this topic. We know about HTTP already, the Hypertext Transfer Protocol. In the simplest view, we send a request for a web page, we get a response back. HTTP on its own we say is stateless. What that means is that in between each request that it receives, it stores no state information about the past requests. So I send a request for index.html. I get the web page coming back. Welcome to this website. The same browser sometime later sends a request for the exact same web page. With HTTP, the web server doesn't care that this web browser has contacted the web server in the past. There's no state information stored about what happened in the past. To keep the web server simple, it just treats this, this is a new, independent request, sends back welcome. That's what we mean by stateless. But that doesn't work very well for many applications we'd like to develop. We would like to have some personalization. That is, someone logs in and they get a web page back which is tailored to them. You view the website and it says your name on it. I view it and it says my name on it. So it's personalized to the user. Session management, meaning you visit the website now and then you visit it again tomorrow and it says welcome back. You were here just yesterday and it keeps track of what you've done in the past, presents something based upon your history of actions on that website. And that's also related to tracking, keeping track of what the user has done on the website. So we'd like such features. HTTP doesn't provide that. So we use, there are some extra mechanisms that provide such features. Personalization of responses, here's an example, very simple one. Browser X sends a request for index.php. The server sends back the web page which says welcome to this website. And the server then stores some state information. It stores something at the server saying browser X visited at 11 AM on the 12th of February. That's what we mean by state information. Then when browser X visits the same page again, the server uses that state information to tailor the response it sends back. And instead of saying welcome, it says welcome back to my web page because it knows that you visited previously. So the server in this case keeps some state information. It knows that this is the second visit by browser X. Three minutes later, for example. And the server keeps that state information. And if another browser, browser Y visits the same web page, then the server doesn't say welcome back because they know this is the first visit of Y. So this is just an example of state information for personalization. How do you implement this in say PHP or other technologies? How do you implement this feature? I think you may have done it. If you've developed a PHP website, whether someone logs in, you would have used the techniques to implement this. Think of a food. Anyone? We'll see you on the next few slides. Cookies, okay? Cookies are one feature that allows us to keep this state information. We'd like the server to be able to identify who is accessing the website. Is it X or Y? And have they been here before? Cookies provides a functionality such that we can keep track of what people have done, some state information. The other thing we'd like to do, and again I think you're aware or we've done it already, is to manage login sessions. So allow someone to log in, do something that only they can do. Only they are authorized to do, and maybe keep some state based upon them. For example, I log in to see my results for some course. So I visit some login page. So I send a request to the server to get the login.php page, which really presents a HTML form to me. A form with some boxes where I can enter in my username and password. So that's sent back in the response. When I type in the values for username and password and press submit on my browser, that triggers my browser to send a HTTP message to the server. But it's a slightly different type of message. This is what we call a post message. It can be done with a get message, but maybe a better way is to use a post message where instead of get this URL, post this data to this URL. So it may be encoded as a post, and inside the URL includes my username and password. That message is sent to the server. The server checks the supplied username and password with what's already stored in the server. So they must have registered in the past. They authenticate the server, and if it is successful, send back a message, welcome Steve. So now it knows my name since I've logged in. And then when I click on a link to the results page, the server knows that it's me that's visiting the results page, and it will send back results which are tailored to me. That's what we'd like to be able to achieve. So the web server knows this is X contacting us again. X has already been authenticated. There should be no need to reauthenticate, and we send back a tailored response. If someone else brows a Y tries to get the results, they may get a message back saying you are not logged in. You cannot view the results until you're logged in. So that's another type of feature that we'd like to implement. And again, cookies can be used to do this. State information at the server. So what we said is that on its own, HTTP is stateless. But to implement these features that we'd like, we need some state information at the server, and cookies provide that for us. A way to implement state with HTTP. A cookie is a data structure. So it's just a set of information, and the normal things that it includes, it's quite simple. It includes a name, a value, some date and time when that cookie expires. The path refers to the URL that it's valid for. So a directory, for example. The domain refers to the domain of the website for that cookie is valid for, like www.sittuacth. And if we're using HTTBS, or no, a flag to indicate whether we should be using HTTBS to, with this cookie or not, whether our communication should be encrypted or not. And we'll see that as we go through some attacks, what that means. How it may be used is that the web server creates the cookie. So when someone first access the website, the web server creates a cookie and sends it back in the response. So the HTTP response that comes from server to client contains part of that cookie, that information in the cookie. And the server stores that information related to the cookie. That's the session or state information we call. So what the result will be is the server knows that information. They know that browser from this IP address at this time accessed our web server, and there is some session information about that user and sends the cookie back to the browser. Step two, the browser, when it receives a cookie, it stores it in its local storage on your computer. And the next time your browser sends a request to the same domain, it will include the cookie. In that request. And the cookie is received by the server in that HTTP request and it tells the server that this is the same browser that accessed before. Because the cookie can contain some unique values which identify that browser. So the first time you access the website, the cookie is created and the server stores some session information and sends the cookie back to you, the browser. Every subsequent request from your browser to the same website will include that cookie. And whenever the server receives the cookie, it knows, ah, this is the person who accessed at the start. Because it identifies them. The cookie will contain values which uniquely identify who is communicating. It will not be the same for each user that's accessing the website. We'll see some examples of cookies. Soon. Here's this concept. So first I visit the website and I visit the login page. And the server sends back a HTML form asking me for my username and password. And I type them in and press submit or post the values. So this third message going to the server contains my username and password. It's received by the server. The server checks those values. Are they valid? Yes, let's assume they're okay. So the user is authenticated. Then the server stores information about that user. For example, they store the username, Steve, and they maybe store some unique value that identifies this user. And here I've listed in this example an ID hash, some hash of an ID. We'll see an implementation of that shortly, but some unique value for that user. So they store that, let's say, in a database or in a file at the server. In addition, the HTTP response that comes back saying, welcome, Steve, also in the header fields includes those values of the cookie. Or specifically the set cookie field says username is Steve, ID hash is this a random value. When your browser receives those values, it stores them locally. The next time your browser visits the same website, it sends a request for the results page, it includes those values in the request. Steve and the ID hash. And quite simply, the server compares the received values with those stored by the server. If they match, the server has now identified you. This is Steve accessing the website. It's not someone else. And that allows them to send back a tailored response. Questions about cookies so far? We need to know this as background so that we can understand some of the attacks that take place on websites. Any questions from the back? Do you like cookies? We will see shortly some examples and you'll see a little bit more tomorrow in the lab. Any questions? Okay, good. Everyone likes them. There are some issues with cookies. We may not discuss them so much now. All right, we'll mention them but we'll come back to the advantages and disadvantages later. When you first visit the website and the server sends back those set cookie values, your browser stores them, stores those values. There can be a lifetime associated with a cookie. So the question is, how long should you store them? And there are two basic approaches. Session cookies. There's no expiry time but those cookies are deleted when you close the browser. So a session cookie is just while you're browsing for this session, for this period of time. And the other approach is persistent cookies. There's some expiry date set and when you close the browser those cookies are saved. So that when you start the browser tomorrow then they are still there. They will be deleted when the expiry date is set, is met. So the expiry date may be set differently and in fact the user should be able to and can in different browsers delete or manually manage the cookies that they have access to. So one question then is when should session-based cookies and when should persistent cookies be used? And we'll see some examples as we go through. The other aspect is that when you receive a cookie the cookie contains a field called domain which indicates what website or what domain of the web server should it be valid for. A first-party cookie is one where the website that you're accessing, the URL, the domain of that is the same as that stored for the cookie. So let's say we have a cookie for google.com you visit google.com you get the cookie the domain inside the cookie is google.com when you visit google.com again then we'd say that the URL you're visiting the domain of that matches that of the cookie so that's a first-party cookie. But if the cookie has the domain google.com and then you visit another URL facebook.com if you send your cookie value from your browser to facebook.com then we'd refer to that as a third-party cookie. We're sending the cookie which is relevant for one domain to a different domain and generally we don't want to do that or the user may not want to do that the website may want you to send the cookie but generally that's used for other for websites to track the users to track which websites are visited and what they've been doing on the internet. So some browsers will have settings such that they will not allow third-party cookies they'll only allow you to send a cookie to the domain to a URL which where the domain matches that of a cookie and we'll see that a little bit when we come up with I'll show you example of a cookie shortly and see the values. Cookies when we're using HTTP cookies are sent in the request and response yes all right first and third-party cookie I'll explain them again now but then we'll show an example shortly so the cookie contains in when we first get the cookie okay we can think the cookie contains a domain where we got it from if I get a cookie from google.com then the domain of that cookie is google.com and my browser stores that so my browser stores the value the domain field will be google.com if I visit google a website with the domain google.com then I send that cookie to google.com then we'd refer to that cookie as a first-party cookie the domain of that cookie matches the domain of the website I'm accessing that's normal that's how we normally use cookies but if the domain of the cookie is google.com and I my web browser sends that cookie to say facebook.com the domain of the cookie is google.com the domain of the web server is facebook.com that's what we call a third-party cookie and from the web browser's perspective normally we would not like to do that because what that does is it potentially allows that web server to know what you've been doing on other websites and we'll see that of course the exchange of cookies is always automated the the human user has very little role in it so it's up to the preferences of the browser as to how to handle them let's get to an example of a cookie we'll say something about HTTPS later so the example and we're going to do this tomorrow in in the lab what we'll do is we'll set up a virtual network and we'll access and it's already got some fake websites deployed or some demo websites and we'll use the web browser to access them and do some attacks I've already set that up and I'll just show you what we have and first illustrate the cookies and how they're used not so easy to see but the network we have as five five nodes has a router in the middle I think today we'll deal with just there's a normal web browser there's a web server and in the attacks we'll see that there's another web browser what we'll call the malicious web browser some malicious user trying to do something bad and we'll also see a fake or a malicious web server so nodes one two three four and five yeah so let me set it up node three I think we don't need to look at just yet this is the node four is the website that we have and I'll show you what it does in a moment but node one is the browser so node one is our normal users running the web browser I think for now we'll just use links as a text-based browser but later we'll use Firefox let's just demonstrate the website there's a website on node four which is links has some benefits in this case because we'll see that we can easily modify cookies it's quite easy to modify when we do an attack and it's it's very lightweight in here but it's not so complex a website that we need graphics so the domain is of the normal website is my uni.edu and the idea of this website is it allows students to log in and see their grades and it allows faculty members to log in and modify the grades of students and the the policy of this website is that we'll see there are two demo students but the students can only see their own grades okay you should not be able to see other students grades students cannot change their grades okay that's that's expected if you could change your grades then it wouldn't be so good for us and the faculty member can change grades and can see the grades of all students so that's the general requirements for this demo website and I've gone to the wrong page I'll quit that there's actually a path here grades as a sub-site so my uni.edu and the grades system and here's the front page it's it's not very complicated the links down the bottom are just some help or explanation about the website but from the welcome page I asked you to log in you can't do much unless you log in so I log in and I need let's say as a student I need a username and password and I've got some and password and I click on the login link and note with links it says so links is quite strict here it says I've received a cookie so what happened when I pressed the login link is it triggered a request to go to the server and the server sent back a reply and the reply included that set cookie value username was this the student username and links is asked me do you want me to allow us to use this cookie and I would say a for always let's always accept it for that domain and it actually does some redirection and now I'm logged in so you see welcome to this student let's view the grades so there's some links here the main thing we can do is either view the grades or log out view the grades and the the grade viewing system is very simple either you you should only be able to view your grades so it's pre-populated with my ID at this stage if I want to view the grades for a particular course I'll enter the course code if I want to see all my grades I'll leave the course code empty for example and now click on submit this is a form so we'll use this to demonstrate in an attack later but this is a form that will post information to the server it will post the ID and the course code to the server and what the server should do is look up that in the database and return the correct grade and I know you know how to implement that so it gets the grades fine and if I view grades again if I delete that then I can see all my grades in this case just for two courses so that's the basics of the system let's go look at the cookie note that I'm logged in let's see another feature let's view the grades let's try and view someone else's grades there's another user that's their ID I know that I want to view their grades and the website returns an error or a message saying you can only view your own grades okay so this is this session management somehow the web server's implemented or the code that's PHP is implemented such that it checks that the right user is logged in and only they can see their grades you can't see other people's grades I'm going to quit and try it again what I'm going to do this time is do the same thing and log in the way that links works is when I close the browser it deletes all cookies so if I lock access again then I will have to log in again normally your browser may store the cookies but links automatically deletes the cookies by default so we'd need to log in so I've got just some modifications so that we can save the cookies a different config the details of this config are not so important let me get this right because we want to look at a cookie I'll log in again can anyone see my password how would you see my password how would you obtain it no here I am accessing my browser on node one the web server's on node four what would you need to find my password if you were maybe you had access to the router on node three maybe you ran the network you could capture on the router and you could intercept the packets being sent because it's using HTTP nothing's encrypted so when I type in my username and password here and press submit it sends those values in HTTP get Rick or HTTP post message to the server unencrypted with HTTP so anyone between the browser and the server in theory can observe that username and password so that's one of the web attacks intercept other people's traffic learn the data it redirects to some page after I log in and I can view the grades let's view the cookie here I can see my cookie jar it shows from my browser's perspective what cookies I have and here it is here's what the I've only got one cookie in this case we can see the domain is for www.myuni.edu the value that we have a value the name username and the value is the student ID in this case the path refers to the path in the URL so slash so anything under slash this is valid for some other information about the the web server that it's using port 80 there's no HTTPS so it's not secure this is something about the expiry time the maximum time maximum gobble date is the time when we should eat the cookie so there's some date associated with it and another one so there are in fact two cookie two values here ID hash is the other name and here's its value it's actually some hash value and similar values a similar other parameters so these are the the two cookies in fact I have two cookies in this case one is the username one is the ID hash this is story my browser every time I send a request to www.myuni.edu my browser sends these values sends the username and the ID hash and that's how the web server knows it's me that's accessing so the web server doesn't prompt me to log in again it it will use the cookies to know it's me logged in so how can I perform an attack from a malicious user's perspective do you how could I log in as someone else how could I see in other students grades for example related to the cookie here I am on node one my browser has these cookie values when I send a request to the server the server matches these values with me and shows me my information what type of attack could be used on this what could a malicious user do to take advantage of this information what the malicious user on another browser could do if they know these values so on node two for example they could open their browser and if they know these values we'll talk about how they'd know them but if they did know these values then they could set the values of cookies on their browser to be exactly the same as these the ID hash and the username and when their browser accesses the web server their browser sends these values to the web server the web server checks the received values against the session information and sees that it matches for user five with nine ohs effectively allowing that user to log in as this user so this is what's calling an attack that involves stealing someone's cookies if you can obtain the cookie values of someone else's browser then potentially you can log in from their usernames as their user even without knowing their password you don't need to know their password let me open node two and try that attack this is node two another web browser this other user can log in they're a different user they have a different user ID password and they can log in and the web server sends a tailored response back identifying that user and that user can see their grades only now i'll quit so this orange user is this one one two three four five six seven eight and the original user is the all zeros user what we want to do is the attacker this user is to view the grades of the all zeros user so what i'll do is i'll exit my browser and the way that the links browser works is it saves the cookies in a file called links cookies so these are the cookie values for this user let's change them and we need the hash value what i'm going to do is steal the hash value from the other user if the malicious user can learn this value so i'll copy it from the other cookie jar so now my malicious user has the cookie values of the original user and we'll exit that access the website again who am i logged in as the all zeros user what happened is that my browser sent those cookie values to the server the server identifies me as that all zeros user because those cookie values correspond to our original user this was the the normal user if we can learn these values we can log in as that user the question you're all about to ask is how do i learn these values that is this is someone on their computer you're on another computer how do you learn their cookie values on their web browser if you can capture capture the the the packet sent between their browser and the server the cookie values are included in those messages so you just need to capture them or if you can get physical access to their computer you could covertly copy the cookie files across to your computer okay if you have that physical access so there may be ways that you can learn the cookie values of someone else's computer and once you do that you can effectively log in as them so that's one attack on websites before we go on in general about web security any any questions about cookies we will not try now but maybe tomorrow in the lab we can try and capture the actual packets and you'll see if you do capture the packets between node one and the web server say on the router you'll see in some of those packets contain the cookie values if you can do that you can steal the cookie the other thing you could do it if in practice someone's using their browser and using wi-fi without encryption then again it's very easy to intercept and capture someone's packets wirelessly and therefore steal their cookies how do you prevent that how do you prevent someone from stealing your cookies encrypt that is use HTTPS so if you encrypt that HTTPS get requests to the post request and the responses the cookie values are also encrypted so to prevent a cookie stealing attack encryption is important HTTPS is the main technique let's log out of this user log out here so in links the reason I use links here is because it's very easy to edit the cookies so we'll get rid of the cookies file that we logged out logging out in this case is simply deleting the cookies so the concept of log out if you delete the cookies then when you try to access that website again there's nothing to send to the server and it cannot identify you so there is no cookies left so we'll see one of the attacks mentions cookie stealing and other aspects of stealing information what we're going to do is there are many different types of attacks on websites and it's it's quite complex quite difficult to develop a complex website that is secure so there are many different recommendations of how to develop a good website that is secure we will go through just a selection of different attacks and some of the mechanisms or give suggestions or mechanisms to to prevent the attacks and I've taken these attacks from some organization called OWASP what is OWASP it's actually the name of a project and or organization the open web application security project it's a group of organize or a group of companies and people that have got together and they do many things one of them is to try to give recommendations of how to develop secure websites secure web applications and one way they do that is they look at many of the risks many of the attacks and try and prioritize the efforts against defending against those attacks so there's a definition or a statement about what OWASP tries to do the website gives a lot of information they provide everything for free so all the information is there they provide tutorials on how to develop say login systems how to store passwords how to do things regarding web application security they provide some code and some APIs if you need to develop your own website security mechanism and of interest to our lecture is that they what they do every few years every three or four years they do a survey of different companies and they try and learn about the the main attacks that take place on web applications and they come up with a top 10 and what we're going to do is go through that top 10 web attacks and explain them with the intent that you'll be aware and be able to defend against them so they develop a top 10 release web application security risks and they've been released over different years so the last one I've looked at is 2013 maybe they've got a new one coming this or next year and they collect data from different companies about who has what real attacks have been performed so they get a collection of half a million different risks or vulnerabilities across many different companies and try to rank which one's the most severe when they come up with a top 10 and this is it this is their top 10 that is what they think are the most most important web security risks to address in developing of applications and we'll go through each of them some in more detail than others injection we'll explain later some of them we'll explain now briefly broken authentication and session management simply that is the login system doesn't work or the tracking of users doesn't work correctly maybe some student who got a low grade in Dr. Dr. Tanaruck's database course develops a website and they make some mistakes in the login system that allows an attacker to log in when they shouldn't be able to for example that's an example of broken authentication and session management cross-site scripting we'll explain that one in secure direct object references what else can we say security misconfiguration is that maybe you install some software on your server you're setting up a website and you don't set it up correctly maybe you forget to set some parameter value and that makes your website insecure okay you forget to enable the protection on some directory or some files which means someone can do an attack sensitive data exposure means that the data that should be confidential is made available to people who shouldn't be able to see it it's exposed for example the cookies are exposed that's an example there the cookies which are sensitive data they had data that's only the the web browser should be able to see in the server if they are exposed to people then someone can do an attack and the rest so we'll go through them some with some detailed examples and some just just briefly most of the risks are due to poor development practices the person implementing the website does something wrong or doesn't follow the standard or the recommended approach maybe they're not aware of it or they take a shortcut and that leads to the risk and poor configuration practices so that when they're setting something up configuring the software they they are not careful and that leads to a risk so to to reduce the impact of those risks you should try and follow secure programming practices when you develop websites we're not going to talk about that in this course how to do how to program websites web applications but I recommend if you and many of you will get a job that involves creating a website for some organization then find some of these recommendations and OWASP is a good starting point they have many examples and tutorials on how to develop different security mechanisms some some risks are due to the software you're using having bugs or vulnerabilities that is rather than developing the website from scratch you download some code and use that someone else's code but that code has a bug which makes it open for some attack on on your website so how to stop that be aware of what software you're using and make sure it's up to date and it's it doesn't have or you're aware of the bugs that are announced so let's look at for today with only 15 minutes left the a selection of the top 10 risks and I may just skip over some to find the easier ones to do this afternoon maybe injection although injection is the number one in the list it may be needs a little bit more time to explain and that's a good thing to go through tomorrow to see how the injection attack works SQL injection you may have heard of but in general injection attacks involve so we'll do one tomorrow but it involves really the attacks we will see submitting data to the server and getting the server to process that when it shouldn't process and do something that it shouldn't do so we'll see that in terms of queries on websites or databases but let's find an easier one to go through broken authentication and session management someone develops a website and it allows people to log in and once someone's logged in it keeps track that they're logged in but they don't do it very well and it allows an attack to take place so some examples of what can go wrong here we normally to keep track of users we can talk about a user once they log in or in a session they start a session and for when they're accessing that website it's all that maintain within that one session so we give the user some session ID okay often well that session ID should be included in cookies we saw the session ID was really the ID hash the ID hash was a hash of some session ID and that uniquely identified that user to the web server but if you include that session ID say in the URL of the pages that you're for your website like this one I've shortened it so there's some website and when you log in to the website you're given a session ID like this random value here and when you visit click on links on that website the session ID is included in the URL as a parameter when the web server receives the request for this it checks the session ID and checks that it matches the one for the logged in user in the same way that the ID hash was used in the cookie the problem with this approach is it's very easy for someone to steal this session ID they don't even have to capture the packets they just need to see the URL because what can happen if someone sees that okay Steve is using this session ID if they can learn this value then they can visit this URL and their browser will be identified as me to the web server and how that may happen let's say I've logged in this is my session ID and I want to send a link to my friend about oh you can access the grades from this website so I send an email with this link I don't realize that that link includes a session ID so I send the link to my friend my friend clicks on that link and they are logged in with my session ID so they immediately logged in as me so storing the session ID in the URL is bad it should be stored in the cookie and even better the cookie should be encrypted using HTTBS similar you develop a website and you're debugging debugging it you're trying to fix some errors and you turn on the debugging features such that the website prints out all the messages if it prints out when you have error messages the session ID some attacker could learn the session ID and use that for an attack so session IDs are one way to manage sessions they should be kept confidential for the user they shouldn't be made available to other people another simple example of something going wrong you log in you get some session ID it's in a cookie and then you leave the computer okay maybe it's a public computer in the lab you're still logged in okay the the cookie doesn't expire for another day it's you're effectively still logged in so if someone goes to that browser the browser wasn't closed the cookie wasn't deleted then they are logged in as you so there's a problem and it's due to the fact that in this case timeouts are too long that is the the server should automatically log you out after some period of time it shouldn't be too short such that you get logged out all the time but it shouldn't be too long such that someone else could steal your session what else uh the storage of passwords we've studied that at the start of the course how to store passwords we take the password we concatenate with assault value and we hash those values we store the hash value in the database if you implement a website and you just store the password in the database if someone gets access to your password database now that they know the passwords of all your users and that's a bad so the prevention there use appropriate password storage mechanisms and also get the users to select a passwords in an appropriate manner we've studied that already so that's about all to say about this it's number two on the set of risks so it's a problem but they're quite easy solutions really use cookies encrypt them preferably htbs and use passwords in the right way which we've studied already but there are other examples as well any questions on session management let's see if we can find just one or two more to finish for today just simple ones this one's a complex one to go through uh this one's easy you create a website similar to before the the website uses let's say an id in the url to identify a user so the website shows the grades for the user which users grades to show you implement your website so that the id is given in the url all right five four one two three is the id of the user well in such a simple case if you do that then someone can simply try a different id and submit that to the web server and see if that returns the grades of someone else okay so it's easy for an attacker to just change the url so if you include important information in the url then the attacker can potentially modify that and in this case try to pretend to be someone else and and get the grades of someone else so here we're using the id parameter in the url url to identify some object and some attack could involve modifying that reference value to access some other object it's referred to an insecure direct object reference another example sometimes you may create a website that allows you to download files from the server and maybe the interface is that you've got a a program called file dot php actually it doesn't just download files it shows the contents the files it shows the file so you write file dot php and that php code takes a parameter called the name of the file so the idea is that when someone visits this url it will display the file lecture dot pdf but what the attacker does is that they modify that url and they specify a different file one that you didn't think we didn't want them to access for example they set the the name to be the slash edc password file and your code the php code simply reads that file and displays it on the screen and now the attacker has learnt that password database on your operating system of your server so just simple examples of attacks there are easy ways to prevent these but just to explain the the concept how do you stop such attacks some examples you need to perform some access control so every time someone requests an object check that that logged in user has permissions to access that object so don't just do it by id in this case so in this case all right someone's logged in as id 5 4 1 2 3 then an attacker logs in well we try sorry we're logged in as 5 4 1 2 3 but we change this id parameter to something else then the website the web application should check is this logged in user 5 4 1 2 3 the same as the requested id if not don't allow them to to view that similar to what i did with my login system the users cannot view the grades of other users so the implementation of that is to do a check if the id doesn't match the logged in user id then you cannot access an example of let's say the the link to files or the way to download or view files let's say you give each file a unique id and that's stored in your database so if you want to view the lecture dot pdf file the link says the id is this maybe some hash of the file now if an attacker wants to you view that slash edc slash password file they need to guess what the id of that file is and that's hard if this value is long enough okay so if you make it long enough it's hard for the attacker practically impossible for the attacker to guess the right value for a particular file so there are different ways to uh make it difficult for the attacker to just modify the url to get something that not that they're not allowed to get let me just see if there's some easy ones to go through yes there is this one's easy you set up a website you're not going to program the entire website yourself you're going to install some software to do some parts for you for example you install php my admin or wordpress or some web uh or content management system you download it and install it usually they include include some admin console so that the administrator can log in and set the thing up from the web web page and usually they come with default passwords so a simple example of security misconfiguration is you leave the default password there so someone else who accesses your website simply guesses the password for the admin page of your software and now has admin access to your website okay so a simple case of you misconfigure your web application another one some web servers will allow you to view the set of files in a particular directory let's see if we can find an example for example when I visit this url the software page on sit what the web server does is list the files in the directory it's not a real web page i haven't written html the web server just automatically looks at all the files in the directory and shows me a list a nice list that's intended in this case okay that's how i want it to be but in some cases if you create a website and you don't want people to see the files in the directory but you don't set up the web server so that does show this then what can happen is if someone guesses the directory they can do this and they see all the files there some of them you may want not want them to see and to know that they are there then they can select the files and and download them so make sure that web server is configured such that usually by default that it doesn't show files which are in directories unless they're explicitly in a link another simple example that people may do wrong is that they're developing the application and when they're debugging they turn on a feature that it prints out all the messages all the error messages on the web page or at the bottom of the web page it prints the error messages well that can give information to the attacker that allows them to learn something about your website which may give them a chance to do other attacks so you want to hide that information debugging output error messages should not be displayed on web pages how do you stop security misconfiguration you need to make sure you go through some well-defined procedures when you deploy software and you test software don't just install it and hope that it works upgrade your software as upgrades become available keep components separate so a compromise of one doesn't compromise others where possible keep keep either parts of the website or different servers separate such that if you install one piece of software or one server if that's compromised it won't allow an attacker to compromise your other server so there's just some general recommendations for example that you you install WordPress on one site and on that same server you install some other Drupal or Moodle on there as well there's a bug in WordPress that allows the attacker to access and do bad things there you can set up your server such that it minimizes the chance that even though they can do attacks on the WordPress website they cannot attack the other the Moodle website so try to keep them separate and that involves setting up the server and setting up the applications in there's different ways to to to keep them separate not necessarily a separate server but setting up the operating system so that they the users that can access those files the permissions on those files are appropriate so that the user that accesses the the the WordPress website is different than the user that accesses the Moodle website so if someone can get and log in as that user for WordPress they still can't do anything on the Moodle website separation of functionality it can be useful but it requires effort to set that up what we'll do tomorrow and we'll do it in the lab so we'll see you in the network lab at 9 a.m. we'll go through some of these other attacks and we'll do it in the virtual network we'll get through I think three or four in the time we have so we'll explain them briefly and then demonstrate them to see them working