 We're looking at a set of attacks on web applications. And in the previous lecture, or actually we did it in the lab, we demonstrated two or three different attacks. And we've talked about some others before. So let's just summarize this top 10. These are not all possible attacks. They're just the list of top 10 come up by this organization, OWASP. Let's summarize and just recap on what we've seen. We did a SQL injection attack in the lab on our demo website where the web application does a query. That's a part of its normal operation. The attacker enters into one of the form fields a value that triggers the web application to do an unexpected query. The one we did was similar to this where the web application searches based upon some conditions. We enter in a field, which would normally take the course code, but we modify it to also take this SQL statement of all one equal to one, meaning all true, which causes the query, if it's coded in this way, to return everything, which is unexpected. So we saw that last lecture. How do we stop it? There are most languages which are used for web applications, PHP, Java, ASP, and others, will have things like prepared statements or stored procedures and SQL as well to have parameters to do a query. You don't directly call the query with SQL. You used an existing function that will make it very hard for someone to create that or statement in the end. So most languages support features that will make it almost impossible to someone to write an application where such an attack is possible, but it requires the application developer to use those features. If you don't, then at least you need to try to escape special characters. So a special character in this case, the course code, in this case, the apostrophe and even maybe the equals are special characters. They should not be in the course code. And what you can do is whenever you see them, escape them. So maybe either use a special character to indicate that this cannot be interpreted by SQL. This is just interpreted as a string. So enclose it in double quotes, for example, or do input validation. Again, in this case, the course code should not contain these characters. It should be selected from a predefined list of course codes. So the user cannot enter any possible string. They can only enter strings, which are the list of predefined course codes. And that means that they can't create a course field of this or statement. So there are ways to prevent the attack, but it depends upon the developer to implement. And you will be the developer. Many of you will develop web applications. And you have already, you need to start to learn about some of these techniques to make your application more secure. We've gone through broken authentication earlier, cross-site scripting we haven't seen. We'll just briefly mention, I don't have a demo. A simple example is if we have, let's say some PHP code that just echoes the value of the name variable in a URL. So when you can create a URL like this one and you can, after the question mark, you can pass in parameters. Name equals this, name equals Steve, maybe the intended purpose. And that parameter is returned from this special get variable in PHP. So get name returns the value of the name parameter in the URL. And that's used in some applications. In this case, what the attacker does is they create a URL that doesn't just contain a name of Steve, but it contains also some, they extend the string to contain some JavaScript, some script that would be executed by the browser when it's displayed and sent back to the browser. So in this case, for example, let's say the web page view.php when it takes the name, what it does is it displays that name on the web page. So you click on this link. The intended purpose is it sends back a web page with the word Steve on it, the echo Steve. But what it does is it shows Steve followed by this sequence of code which is some JavaScript code. The script indicates the browser will execute it using JavaScript. And what it does is this JavaScript loads some other website under the control of the attacker, for example, and sends the cookie, this document or cookie is using JavaScript to send the cookie to this other website. So this is an example of using some JavaScript on the normal website to send the cookie for that normal website to some evil website, the malicious users website. Stealing the cookie using the JavaScript here. And we've seen in other attacks stealing a cookie allows someone to log in as you to impersonate you. So one example of what's called cross site scripting because we use some script, JavaScript usually to send some data to another site, cross sites from the normal site, which contains the cookie to some other website that in this case is stealing the cookie. Sometimes abbreviated as XSS, cross site scripting. And again, it's about the data that's input by the user, in this case in the URL name equals Steve, it's not checked by the application. When we develop an application and someone provides input, say via the URL or via a form field, then the data that's input should be checked or validated. Otherwise things can go wrong like this. Again, the name should not contain JavaScript. The name should be a sequence of alphabetical characters, A through to Z here. It shouldn't contain these greater than, less than signs and other characters. So again, we talk about validating input or untrusted data. Anything that gets input to the web application should be checked. And escaping means if you get some special character like a less than sign, either remove it or make it such that it cannot be interpreted. So it's not processed by the browser. There are libraries that will make it easier if we're an application developer to do this, to automatically check that these things aren't possible. Input validation, the input say to a web application is what the user on the browser can send to your web application. So you run the server, you develop the application. The input is let's say someone fills in fields in a form and they press submit. Then think of that data as input to your application or someone creates a URL on their browser. They type in the URL, name equals Steve, then that value Steve is input to your web application. Your web application processes that input. And that's where security flaws can arise because if you receive this input and it's from someone malicious, they may get your application to do something unexpected. So you should check the input. Any input that comes to your application, check if it's valid. And that's common across multiple attacks. Always check the input to your application when it's coming from web browsers, for example, untrusted sources. If you have a form field, a simple example, you have a form field where someone needs to supply their date of birth, then input validation is checking that what they enter must be a date. It's not a name of someone. It's not some special characters. It's of a particular format. So you can validate that and check that it's of that format. But for some data, it's hard to validate because the data may take multiple forms. So there's similarities between cross-site scripting and injection in that the input from the user is not checked and that causes problems on that web application. I think we talked about that in the first topic here where, again, we use parameters in the URL, for example, and the attacker simply modifies. It should take the ID of the student and they change it to someone else's ID and therefore it allows them to view that other student's information. We've mentioned security misconfiguration, setting up your server in the wrong way such that there are holes in it that people can get information from your website that they shouldn't be able to get. Sensitive data exposure is releasing confidential information. If you don't use HTTBS, then people can intercept the packets and see confidential information. If you store passwords in a database and you don't store them in the right manner, if someone compromises that database and they can learn all the passwords, if you store credit card numbers in your database, it's an online shopping site, people pay with their credit card and then you save it for the next use. But then if your database is compromised through some other means, then the credit card numbers of all your users are compromised. And some locations will have laws about how to store confidential information. If you store it in the wrong way and it is compromised, then you may be fined or there may be penalties for the web application developer because of the way that they store personal information. So how do we prevent this? Different ways, encrypt sensitive data when we're sending it across a network. Everything should be encrypted. At rest and in transit. In transit means when we're sending it across a network. At rest means when we store it. So if we do store sensitive information like credit card information, encrypt it or at least store it in some way that it's hard for an attacker if they get that database to find the original value. That's at rest. Don't store it if it's not needed. So don't necessarily store the credit card for the future use. Just delete it so that if your database is compromised then you, at least that sensitive information is not released. Store passwords correctly. Some ways, say autocomplete on some cases can be used for people to learn what others have typed in. So be careful with autocomplete on applications. You start typing something in and that reveals a list of possible matches and that can reveal information that's confidential. Missing function level access control. This really means that, so some websites will have access control. Different users can do different things, can perform different functions. For example, I can log in to Moodle as the instructor and as the administrator, I can do different things from what you can do. So the access control of the website should make sure that the students cannot see the answers to the quiz before it's taken. So that's the function there. If that's not implemented correctly and the students can see the answers before the quiz is taken, then of course that's a security flaw. That's a problem. So make sure that the features of the website are implemented such that it's not possible. But it's not easy in some cases. So some examples of when, some very simple examples. The second one. For example, you create a generic or a PHP file, let's say called grades, which can do different things. And you pass in a parameter called action. The action may be view, to view the grades, edit, to edit the grades. And the normal user can only view the grades. So you set action equal to view. But if the normal user changes that variable to edit, manually modify the URL. And if that allows them to edit the grades, then of course that is not good. So make sure your access control is implemented correctly such that even if someone enters this URL, action equals edit, the web application will still check. Is this user allowed to edit? Don't trust the URL in this case. And there are more complicated cases. But basically it means developing access control for your website that is correct. So it's about applying permissions correctly. And we've studied permissions and access control in general in one of our earlier topics. Simple things, don't rely on links being hidden. That is the link, for example, to the admin page for the website. Maybe you don't tell anyone what the link is. Don't rely on that as a security feature because someone may discover it and then get access if you don't have correct access control. We saw cross site request forgery in our example in the previous lab. It was that idea where we are logged in as the, say I was logged in as the lecturer onto the grading system. And then I visited another website in my browser in a different tab. And the other website had a link to the grading system that caused me to do something malicious. In this case, it had a link, a hidden link to the system that changed the grade of our student. We saw that case. And it took advantage of the fact that when you have your browser open, the cookies are sent to that, the cookie is sent if you're logged in whenever you access that same URL, that same domain. So if someone can get you to be logged in to your website and then visit another malicious website which links back to your website, then effectively they can take advantage of your cookie and do something while you're logged in. So we saw that one in the example last week. Everyone remember, I changed the grade of the student just by following that link to free stuff? Okay, so have a look at that code. That's the best way to see that one. It's hard to fit on the page here. But the code for that shows how it worked. We said this one, sometimes you develop a web application, not from scratch, but using other people's software, other components, make sure they're secure. Floors in other people's components means your resulting web application may have flaws. Simple things of making sure all those components that you use, that you know which ones you're using, the versions that they're up to date, when there are security announcements that the component you're using has a flaw, then do something about it. So monitor the security announcements and upgrade where necessary to avoid using insecure software. And the last one, which we also saw in the demo, was a redirect. We have some simple webpage which redirects us to some external site. The attacker takes advantage of that redirect page to redirect to other websites and maybe the user thinks they're going to a trusted website, S-I-I-T, but in fact they're redirected to some evil website. So there's some aspect of social engineering happening here where the user thinks this URL is to a trusted website, but the redirect sends them to an untrusted website. So be careful when you use redirect in your web application. Check that the redirect is a valid one. We will not go through any of the others or any more detail. We've seen three in detail in the demo last lecture and explained a couple of the others before that. It just makes you aware that there are many different attacks on web applications. We haven't discussed much about preventing them. We've shown you how to prevent them. If you look at the OWASP website and it's included in your handouts, if you look through that document, each attack includes, if we scroll down, a one page, for example, injection. It explains what it is, talks about the vulnerabilities, gives some examples, and maybe most importantly for you, it talks about the ways to prevent injection, but if you're going to develop a web application, then it gives some references to some external or some other resources that show you in detail to prevent injections. So if you're coding in Java or in PHP, some of these other links, the references, lead to information of how to implement your website such that an SQL injection attack is very hard to perform. We will not go through that, but if you develop a web application, use this as a resource. OWASP has many free guides on how to program your website to avoid attacks. The last thing they do is summarize those top 10 risks from different perspectives of their analysis. First, how easy it is to exploit, how easy it is for an attacker to do that. Red is bad. Orange is not so bad. Yellow is okay. Okay, so black is red. Look on the website, you'll see a much better version. It's taken direct from the PDF on OWASP if you want to see and compare them, but it's just a summary of the attacks. What does it show us? So from top 10, so the injection down to redirects, exploitability is how easy it is for the attacker to do that, to exploit that vulnerability. So injections are easy to do because all you need to do if there is a flaw is to type in a URL and type in a form field that causes the attack to occur. Whereas sensitive data, the attacks on sensitive data are quite hard. To obtain that sensitive data are considered much harder to do from the attacker's perspective. So here, easy means it's easy for the attacker. The weakness, this column prevalence is about how widespread such flaws are in web applications. So they've done analysis of many different web applications and they've tried to classify and say, well, which flaws are most widespread? Cross-site scripting is the most common one, or the most widespread, followed by the authentication and inappropriate or out-of-date components. The redirects, the example we gave, is not very common. It's not very common for websites to use such a feature such that they can be exploited. Detectability is how easy it is for the attacker to find that weakness. So it's very easy for the attacker to find flaws due to cross-site scripting. It's very hard for the attacker to find flaws due to out-of-date or components which have flaws in them. That's what it says here, difficult. So again, red is bad. And the last thing is, well, if an attack does happen, what's the impact? Very severe for injection, authentication and sensitive data exposure. That is, a lot of bad things happen if those attacks are successful. And that's some way to rank those 10 types of attacks. Nowadays, many applications are web-based applications. So, and those websites are open to the public in many cases, so they are a common target for attackers. OWASP is just one organization that describes and talks about different attacks and the countermeasures. Most of the attacks are due to poor programming. The person who creates the website doesn't follow some now well-known rules to create the website leading to those attacks. And to avoid those flaws, to program your website correctly, I suggest go to the OWASP website and follow through their resources. If your job is to create a website in the future, then that's a good starting point. For this course, I'd just like you to be aware of those 10 attacks. Not necessarily remember all of them, but if I explain or say, well, especially the ones we've demonstrated, what is an SQL injection attack, then you should be able to maybe answer or at least match the names to some of the attacks, attack descriptions.