 So, we've mentioned through some demos most of the top 10 risks as classified by this organization called OWASP. So, they do some analysis and try and find out what are the attacks on different companies. Let's just summarize the 10 that we've, or some that we've mentioned and maybe a few new ones. We've seen an example of injection, the number one risk. I showed you an example of SQL injection. And the examples I show are very simple. That is, the real attacks may be much more complicated than the examples I show. I just show ones that we can do in class. So the idea is to inject data into the website and get the web server, the website, to do something that it didn't intend to do. And SQL injection takes advantage of the fact that many websites use an SQL query to extract data from a database or even insert data into a database. So the web page with PHP or some other language calls a query that gets data from a database. So the SQL injection attack we saw was if the query, so this is the SQL, which would be implemented say in PHP or some other interpreter, the query, if it's structured in such a way that when you, the visitor to the website can submit a value which is used in that query that causes the query to do something else. And the example we saw was if this was the query, select the grades where the student ID equals to the parameter ID and CID, meaning course ID, equals the parameter dollar course. Where dollar ID and dollar course come from the form. So once someone visits a website, they enter in the student ID in a form field and the course ID in another form field and press submit. So what the PHP does is takes those two values in the form and replaces dollar ID with the value the user entered and dollar course with the value they entered. That's the idea where the user should enter someone's ID and a course code. But if the malicious user constructs input, in this case the course field on the form instead of just using a course ID like ITS 335, they construct this special string, ITS 335, a single quote, or one equals one is just one example. What happens is that this string is put here where dollar course is by the interpreter. So think dollar course is replaced by this and maybe dollar ID is replaced by whatever the value of the student ID was, in this example 5, 4, 1, 2, 3. So the query that the PHP executes, the query on the database becomes this. Select star from grades where the student ID is some value, fine. And course ID is some value, ITS 335, or one equals one. One always equals one. So one equals one is true. So we have something or true and therefore the entire condition returns true and therefore it becomes effectively select star from grades for all, select all rows because if this entire condition is true then the way that the database selects those rows is it selects them all. It doesn't filter any out. So that's just how SQL works if we can have a set of conditions and an or. So or one equals one was just created here so that the query would not restrict the rows that it returned. It would not restrict based upon student ID or course ID because of or true it returns every row in the database or in the table. So this query is executed and the database returns all the user's grades instead of the grades of just that one user. And therefore the malicious user who submitted this form which triggered this query gets to see all the grades of all users which was unintended for the website. So this is an example of an SQL injection, very common and can be very dangerous. Here it's just releasing unauthorized information but in some cases you can construct queries, the attacker can construct queries that does things like either insert information into the database or even delete information from the database. So not just see all fields but in some cases and it depends upon the language, the query and even the database in some cases. You can delete data from the database. So a malicious user who shouldn't have access to modify the database and is in a form value such that the database deletes everything. So that has a significant impact on an organization. So we saw an example of that one. How do you stop it? Well it's really a programming problem. Don't program queries that will take this field value unless it's checked or matches some expected structure. That is don't allow someone to submit this special string so that this query is created. One simple way would be to say the course field must be a six character value. It must not contain any quotes in it. If there were no quotes allowed then this query would not be constructed in this way. So validate the input is one way. The input that is sent in the field check if it's valid or not. If it's not valid, don't create the query. So the code of the website should do that checking. There are some APIs or interfaces that when you create the PHP or in other languages create these queries that will effectively do that for you. To allow you to write a query and will run the query but will strip out all those unexpected characters. So not allow single quotes in the course field. But it's really about programming the website to not allow such queries. And there are different APIs depending upon the language that you're using that will do that for you. Escape special characters, check the input in some ways. Program your website correctly that will prevent this. But that's hard to do. It is on large systems programming and getting, especially when you're using systems from many different people who are developing them, to make sure that no such cases exist is hard to test for. But it just requires strong following of development procedures. Any questions on SQL injection? That's the main one, number one risk. Let's go through some of the others a bit quicker. Session authentication, session management. We know we can authenticate using session IDs and cookies. If someone can discover that information, the session ID, the cookie, then they can effectively log in as you. If they can discover your session ID, they can open their browser and pretend to be you. So don't allow that to happen. It's much harder to find session IDs from the attacker. Don't allow things like weak passwords and so on. In general, perform authentication correctly. Briefly we mentioned cross-site scripting, XSS is a abbreviation where someone, where the web page, for example, takes some value, name, it takes the value of the name field and puts it into the web page. So in this case, whatever the value of name is, the web page shows it in the HTML. And that's what this echo get name does, it get the name from the URL and displays it in the HTML of the web page. What the attacker can do is construct this name field to be not just someone's name but some special HTML, in this case some JavaScript code. So the web page which is constructed contains this JavaScript code which is between these script tags and this JavaScript code, in this example what it does is it opens up another website, this malicious website that the attacker runs, and it sends the cookie from this page to that malicious website. So it's a way for an attacker to steal your cookie and again from the previous case if someone can steal your cookie value then they can log in as you later. So just one example of allowing a script to be input into the web page. And where usually the script refers to another website, cross-site scripting. I didn't have an example of that on our demo system. If you look at the OWASP top 10 I think you'll see a few more details about, a few more examples on cross-site scripting. Again, don't allow such data when we have get name, make sure we check that the name doesn't contain some HTML tags, make sure it's a string or an appropriate structure. So escape untrusted data which means if name equals this long string, what's untrusted data? These less than and greater than signs shouldn't be in the name of a user. So have your code strip them out before the string is used. So that's what escape untrusted data means. Don't allow any special characters that could cause problems. White list input validation means that whatever the value of name is, check it against a set of names that we expect. So the web application knows all the names of the users, Steve, Tanarak, Chowich and all these other names. If the name that the user inputs is not a valid one, don't accept it. So that's the idea of white list validation. And there are actually, you can use functions or libraries that will automatically do that for you. As a programmer, you don't have to manually do this escaping of untrusted data. You can use functions that will do it for you. Insecure direct object reference sounds strange, but it's a rather simple one. First example. All right, let's say the grade system was implemented such that it takes an ID in the URL parameter. Well, if that's the case, then what a malicious user may do is just try and change the value of the ID to be someone else's and see if they can access the other person's grades. That would be a poorly implemented website if it allowed that, but that would be such an attack where normally the user needs to log in, but if we didn't use a correct cookie in session management, a malicious user may be able to just change ID to whatever value that they choose. And if the website accepts this and displays the grades for this other user, then that's a problem with the website. The user has accessed some object, a web page, indirectly via the URL in this case. For example here, which is maybe a little bit easier to see. Let's say you implement a website and you have a file download feature. So the feature is this file.php, and it takes a parameter, the name of the file, and when you click on this link it downloads lecture.pdf, that's the normal behavior. The malicious user uses this URL on this file.php, and they just change the name to some other file on your server, like the password file, and if it's implemented incorrectly then when the user visits this URL, the malicious user, the system, the file.php just takes the name and downloads that file. By download I mean it shows it on the screen on the web browser, therefore seeing the password file on the server. So again, this should not be allowed. Should check and make sure that the user, if we implement such a system, is not authorized to download a set of files. So make sure we check. Are they authorized to download this file, and they should not be. So again, how to stop this, implement the website such that it has some access control. Every time a request is maged to download a file, then the web page, or the php for example checks, is this user allowed to download this file? If not, don't let them. Another way that's common is say downloading files. Instead of having name equals lecture.pdf, have the web application generate some unique ID for that web page, and that's generated by the application. When someone clicks on this link, it downloads lecture.pdf. Why? Because the web application is programmed to map this unique ID to this file lecture.pdf. What that means is the attacker, if they want to download etc slash password, they need to know that unique ID for etc password, and you can implement it such that it's effectively impossible to guess what that ID would be. So therefore an attacker, if they try id equals something else, they cannot choose which file they'll download, and normally they would, if they just choose a random value here, it would not return a valid file. So there are ways to stop those attacks. Use post instead of get. So post sends data, yes. So here we're using get in terms of the parameter is sent in the URL. So you see in these examples, the parameter is sent in the URL, and therefore it's very easy for the attacker, the malicious user, once they know the structure of this URL is to change the parameter value. So the post, so especially when you have a form, the form values are not sent in the URL, they're sent as parameters inside the HTTP get request. So it's much harder for the attacker to find out what those parameter values are using post instead of a get. So yes, much better, but still if they can capture the packets, they can still guess what those values would be or determine them. So some of these examples, yes, there are different ways to prevent them. Security misconfiguration, for example, you install some software and you don't change the default password. An attacker comes along and logs in, they just know the default password and they log in and have access. So a very simple example. So setting up your server and your applications to be secure from the start, so configuring them correctly. Some applications, some web applications show some debugging information. If an error occurs in your application, it shows you some error messages. For production websites, that's a bad idea because usually an attacker, a malicious user can learn something about what's happening on your server based upon those error messages. So when you release your website to the public, make sure all of the debugging features are turned off. But if there's an error, then nothing is displayed to the user except, okay, sorry, there's an error on this page. It doesn't display all the values of the variables in your PHP code. It doesn't display the version of the server being used and so on. So try not to expose any information that may be used by the attacker in other attacks. That's the idea there. If you've done some PHP programming for websites, you'll know that you can run some commands or if you make a mistake in the code, it can be set up so the server will display, say, what parameters were in the PHP code, what was executed by the PHP code, again. That exposes information to the malicious user that they may be able to use. So this is a general one that, okay, set up your server so that it doesn't expose any information to the malicious user, set it up so that it doesn't use default passwords. Sounds obvious, but many people still do that. We mentioned sensitive data exposure. If the attacker can intercept some data, then that's a problem. So use encryption where possible, store passwords correctly, don't store confidential information unencrypted. I don't think we mentioned this one, missing function level access control. Quite simple examples. Let's say we have some grades website and the second URL, there's an admin part of the grades website. So for the person who runs the grading website has their own webpage where they can log in and set it up so that they can allow different users to or add new users. This admin feature of the website should not be available to normal users. It must have some authentication mechanism. If a normal user can visit this admin part of the website, then we have a problem. So this is just saying that if the website is such that it is missing, it doesn't have some access control features, then of course it can be insecure. The simple example is if someone visits this admin URL and then can perform the functions and only an administrator should be able to perform, then that's a security form. They can still use the same login page as long as, so this is talking about access control. So if, let's say Steve is the admin user, when I log in, I should be able to access this URL. When you log in and try and visit this URL, it should say no, you cannot access it. That's all. So we need some access control, say, on this page. So the code inside here should check, is the person trying to access it allowed to access it? So using the cookie to identify who the person is and using some check saying, if user equals Steve, then yes they can access, else no, display some error, don't display them, the admin feature. That's the idea there. Whether they log in from the same page or not is not relevant here. Another example, sometimes websites are implemented such that there's one general page and it takes a parameter which performs different actions. So there may be a parameter action equals edit to edit the grades. Action equals view, just to view the grades. Action equals insert to add new grades or whatever. If a user who's not allowed to edit can simply type in the URL and be able to edit grades, then of course that's a problem. So it's really about implementing the website so that the access control works correctly so that no one can or not anyone can edit. So that's about having authentication and authorization modules. So modules to authenticate users and check are they authorized to do something and make sure that they're easy to use for the programmers and consistent across the whole site. And same with any access control. Take the approach of deny access by default. Only allow them if they, in certain cases. So if you make a mistake in setting up the website and programming it, they'll be denied ability to edit. And you'll detect that because someone who should have the ability to edit will report the error. We saw an example of cross-site request forgery. The idea was that in this, in our grading system to edit grades, the logged in user could visit this URL, click on a link, this URL, which would change the grade of this student with this course, RTS 3352D, for example. That was how it was implemented. And this page checks the cookie. So not anyone can visit this URL. You need to be logged in for this URL to perform a grade update. If you're not logged in and try and visit this URL, you'll return an error. That's the normal behavior. So if your cookie is appropriate, then you can edit grades. This cross-site request forgery was such that a malicious user somehow got you, the logged in user, to visit their malicious website, some website under their control, which includes a link to this editing of grades. Because if you're already logged in on your browser, so the cookie exists for your website, but you then visit another website, say in another tab, and that other website has a link to the original grading system, then the browser will automatically send the cookie for this website when you follow this link. As a result, you are logged into the grading system, and you visit this other website, which automatically takes you to the grading system and updates the grade without your knowledge. And one common way to do it is to hide this link in an image, say an image of zero size. So in fact, when you visit this other website, you don't know that you're visiting your grading system. Because there's a link to an image, the browser automatically visits this URL because that's how it handles images. There's an image. It visits this URL. But you don't know it because you don't see an image there. You can set an image of zero pixels, zero width, zero height. So the user doesn't see it, but what's actually happening is the browser is sending a request to this URL. It includes your cookie because you're currently logged into the grading system on another tab in your browser, and therefore the server receives the correct cookie and updates the grade. So if the website has this feature and if the malicious user can get you to visit their malicious website, which has such a link, then they can update the grade without your intentions, against your intentions. How do you stop that? Make sure every request has some unpredictable values such that the attacker, when they try and construct this image link, doesn't know this unpredictable value and therefore cannot construct the correct URL. So what the webpage should do is check if this, say some token attached to this URL is a valid value, then we'll accept the update. But if it's other value, then don't accept it. So there are ways to, quite easy ways to prevent this. Many websites, they develop using other applications. You don't create the whole website yourself. You use existing software. If that existing software has bugs, then your website has bugs. So being aware of the different components in use and making sure that they are up to date, they don't have any significant security flaws is a way to prevent that. And we saw an example of the last one as well, this redirect where it was a combination of this phishing attack where we receive an email. The domain looked okay in the email, S-I-T dot th, something we trust. But in fact, the link redirected us to some evil website. So we have taken to this evil website which does some evil thing, well, whatever it is. Steals your login, steals your cookie, or even just takes you to some website whether they get some advertising money. So avoid redirects, so we mentioned that in the demo. So just be aware of those different types of attacks. If you want to know the details of how they work and especially how to prevent them when you create your own website, then read up about the OWASP top 10 and the OWASP website has many recommendations of how to implement such that these attacks are much harder. We're not gonna cover how to do that, but if you're developing your own website, then I recommend you use OWASP and other sources to learn how to implement, to avoid most of these attacks. They provide a summary saying which ones are easiest to exploit from the attacker's perspective, which ones most widespread, so cross-site scripting is the most widespread, they believe of them, others. The ability to detect and what's the impact of them. So the sum, they rank the top 10 and look at the risks involved with each of those attacks. Any questions about web attacks? I don't expect you to remember this and in fact I'm not gonna ask you to list the top 10 web attacks, but for example, in the exam if I say, all right, this is the general, here's a website and here's how an SQL injection attack would be performed, how does it work or what's the consequence or how, why does that SQL injection attack work? That's an example. So I may give you a bit of information about the attack and then ask you some questions about it. Or here's a URL that redirects to some other website. How could a malicious user use that to perform an attack? Or do we have another example? What's required for a cross-site request forgery to work? So again, I don't require you to remember all of the attacks but given some information about one or several attacks, you should be able to answer some questions, especially the ones that we demonstrated. And at the start of this topic, we discussed how cookies are used for session management so you should be aware of that. So many attacks on computer systems today are via attacks on websites. So therefore it's important to implement websites that are secure. OWASP is just one organization that described attacks, countermeasures and provides a lot of material about different attacks. Most of the attacks are due to poor programming. That is, you can prevent the attack by implementing the website correctly. So it's about making sure you're following the right approaches to programming the website. Some are due to poor configuration. You don't set up the software correctly. You install some software but leave the default password. If you're in the job of developing websites, I highly recommend using the OWASP website and a lot of the material there gives many details using different languages and different systems, how to prevent the attacks. Any questions on web security? If they have the tool that they change the password, how can they give you, what do you know, or being careful about that? Here when we're talking about the security misconfiguration and one example using default passwords, this was right, if you're setting up a website, you're the admin, if you're a non-IT user setting up a website, then you shouldn't be, okay? So in this specific case, it's about setting up a website or installing software on your web server. You must be aware and you should change the default password. The question you're talking about is about, I think, maybe other applications that use default passwords. Then, for example, your home router, maybe have a default password for configuration access. Slightly different issue. Preferably get the user to change the password upon first use. So you can do things such that after the first login, it requires you to change the password. So you can get the password to be changed or force the user to change the password. But that's coming back to our password topic about educating users about the value of using strong passwords. We covered that earlier in the semester.