 So, recall that OWASP, this organization, is just some group of people who've come together to try and promote the improvement of security of web applications. And one thing they do is list what they consider the top 10 risks in terms of web applications. We started with a couple of simple examples, last lecture, first demonstrating cookies. And then we got to an example of a redirection. We'll not do it again, but just remind you that we had one where we, well, the first one we looked at was with cookies, if someone can steal the cookie then they can steal the session of another user. So if we can intercept packets between client and server then someone can take the session information. Then we looked at a redirection attack which involved someone following a link in our case that took advantage of the feature of the website, the feature was a redirection. So let's just recap on that redirection and we'll go direct to one of the slides. It's actually the last risk, the 10th one in this list, this unvalidated redirects and forwards. So the example is some websites have a page which will redirect you from that current page to some other URL. So an example is this URL on some website, redirect.php, takes as a parameter some URL, some domain or some complete URL, and when someone visits that the code inside here takes the user and sends them to this location. So that's a feature that some websites implement. Why? One thing you'll see is sometimes the redirect may show a message before you actually are redirected. So a message you'll see is if you click on a link from some organization's website and the link is to an external website then the message say in five seconds you're going to be redirected to an external website and we take no responsibility for this external content. So that's one example where you see this redirection use that the website is sent is that it has a link to some external one. Another form of redirection or is forwarding, sometimes websites implement some functionality such that to pass between different pages in the same website to forward between pages they also use some code to implement that. So an example that this website has this index.php which takes a parameter forward, FWD, and that points to another page on this website, say to the admin page. So sometimes that's used rather than absolute links then a parameterized forward is used. So that's common in some websites. These attacks take advantage of those features. So if a website has a redirect or a forward feature then attacks can try and take advantage of that by constructing URLs that redirect to some other website, some malicious website or forward to some page which you should not have access to and still using the trusted domain that the user who's accessing this website would trust. And that's what we saw in the attack. We saw a combination of phishing where we had this email. I received this email and it contained some URL and some message. So this is a combination of several issues saying a fake email from someone who I normally would trust. So I think the email is okay. I check. There's a link in here and some people know when there's a link in an email, should you trust it? Well, one way to check do you trust it is to look if you don't know anything about the details of the URL, at least check the domain. Is this domain something that I know about? So in this case, the idea from the attacker is that when I read this email, if I check the domain at least, www.myuni.edu, I trust that domain because I know that that's our uni grading system. So I trust this link and I click on the link. But of course, as I click on that link, if we look at the details, it's actually using the redirect feature of that website to take me not to the myuni but to some other malicious website. And that redirects me to that malicious website which does whatever it needs to do to perform the attack. In our case, the malicious website provided a fake login page and collected usernames and passwords. But it doesn't have to do that. The malicious website may be just some website that gets money from people visiting it. So they have many ads on there. You are redirected to here and therefore they get some money from the fact that someone else has visited this website. Well the malicious website may have some virus on it. So you're redirected to it and then that virus infects your computer. So what happens when you redirect it? There may be different results. This took advantage of the fact that the reader of the email trusts the domain. What if you got a different email? What if the email was this? Well maybe in this case, some readers would notice that it's not the real domain. Some may not. So here's a domain which is not myuni.edu but it's similar. So maybe in a phishing attack the reader of the email would be fooled in following this link. But maybe that's smart enough to realize, ah, this is not really my website, I'm not going to trust this link. Or maybe if you receive this email, well again I think this case the reader of the email may be even less trustworthy in terms of the link. That is, I see this, I don't recognize anything here that's familiar to me. I don't recognize the domain that I trust, therefore place less trust in this link. Maybe recognize this is a phishing attack. So this is about the idea that users are starting to place some trust in particular domains. Domains that they've visited on a regular basis. Or maybe this one, I receive an email and it says it takes me to some other website which I have no idea about the domain name. I've never seen it before, it doesn't make sense to me. Or as the reader I may, more likely to not trust and follow this thing. Therefore from the attacker's perspective, being able to construct a URL that contains a domain which is trusted by the reader is more likely to be successful in an attack. That's the point here. Questions? In these examples I'm including the actual URL in the email. Of course you know with some emails you can construct emails with HTML where something is displayed here, but the actual URL behind that link is different. So with a HTML email, this is not a HTML email, it's just plain text. With a HTML based email you could construct a link that looks like a trustworthy domain but is not. If you hover over the link you'd see down here that it's not the domain. So yes, that's another way of fooling the user into thinking that they trust this. But that's not about this attack. This attack is about the redirection, it's if the user does look for the domain even if they look for the domain, with this redirection attack we can still take advantage of that as the attacker. Because even if I'm the reader and I trust my uni.edu so I check this, it looks okay. With the other emails I would not trust them. I recognize this is not my website, I'm not going to follow the link. This is just some IP address, I have no idea where this takes me, I'm not going to follow the link. This one, some other website, I know that's not my grading system for my university so I won't follow the link. But with this one I recognize at least this is the domain I always visit to enter grades therefore I'll trust the link, that's the idea here. Now there are other ways to fool users into following links, this is just taking advantage of this redirect capability. Now this is just one example of using the redirect of using emails. In some cases it doesn't have to be that, that is what if there was software that was checking the domains. That is the security of the system was set up such that if there's a link in an email and if it's to a trusted domain allow that link, let's say the organization SIT is set up their email server so that any email that has a link in it, if the link is to a domain that is trusted maybe on some white list then we will allow that email, we will allow that link in the email, that is the SIT email server will not filter that. But if it's set up such that if the link in an email is to some untrusted domain, one that's not on a trusted list or a white list then block the email or maybe strip out the URL from the email so that the reader doesn't check and follow the link. So if it was automated so that software was checking only display links and only allow users to click on links that are to trusted domains then if that was the case this link would not be displayed because it's not trusted by the SIT system, the trusted ones are those that the SIT system knows about, this one would not be displayed but that software would display this one assuming that this domain myunit.edu is trusted by that organization. So if we have some software to check the links and allow links to a set of trusted domains and block links to a set of untrusted domains if that was the case this would get around that in that the attacker could construct this link, it would be accepted by this software because it's to a trusted domain but in fact it turns out it redirects the user to some untrusted domain. So it's not just about emails, this redirection is another way to get around the fact that the user or some software does not know whether ending up, so how do you stop it? Don't use redirects or forwards in your website, there's one solution, avoid them as much as possible. If they are used then the values that are supplied make sure that they are valid or appropriate for the user that it's accessing it. In our example it took a URL as a parameter but you could place some restrictions so that the page checks is the person visiting this website allowed to be visiting this especially for forwarding for example the forwarding although I don't have an example is we use this feature that it takes someone to another page in the website and this example it takes the user to the admin page to administrate the some feature on the website well that should only be available to some users, users that are logged in so this page should check if someone types in this forward to another admin page it should check whether they are authorized to do that. Another way is to have the code, the application to maintain some mapping instead of having a URL or an absolute link here that we in the URL here we include some say random value that maps back to the actual page URL. In that way the attacker cannot guess how to construct this URL so make it difficult for the attacker to construct a URL to redirect to their site because the application actually constructs the URL using their own internal mapping that the attacker cannot see. So that in this complete URL we would not see URL equals evil.com we would see destination equals some hash of the domain and then or some unique mapping and therefore the application then converts that value back to actual domain so that would be much harder for the attacker to construct their own URL pointing to their own website. So there are different ways to try and reduce the impact of this redirection attacks maybe the simplest is not to use these features just going back to what was the redirection this is our node for this is our web server our normal web server what does the redirect page to is very simple include some header it's just some PHP the main point is that this page gets in the URL the parameter it extracts it from the URL and sets it to this PHP parameter called URL and this header location is just some PHP code to do the redirection so all it did was whatever the value of URL was for example actually the examples here whatever the value of URL is in the in the actual URL then that PHP code redirects you to that value so that how it was implemented of course it can be more complex than that it's just a simple demonstration let's look at some other attacks that's just that was number 10 let's go back and see others that we've mentioned briefly sensitive data exposure we won't say much more about that so number six on the list for example if someone can steal the cookie values then they can log in as someone else we saw that last lecture that the cookie for example contains the session identifier something that identifies the user if someone else can obtain those values then they can set them in their browser to log in so that is considered sensitive data therefore we should protect it so if HTTPS is not used if we don't have encryption then it's possible for someone to intercept those cookies sent between the browser and the server and steal those values allowing them to log in as someone else but there's many aspects of sensitive data that we should protect on websites so not just cookies when someone logs in with a username and password you type in your username and password press submit it sends that username and password to the server if that's not encrypted then someone can intercept and see the username and password not just the communications but also on the server itself if the passwords are not stored properly on the server then someone may be able to perform an attack and steal those passwords so we've covered the entire topic on storage of passwords applies not just your operating systems but websites as well that password should be when they're stored you don't store the actual password you store a salted hash of the password that is you take the password attach some random value and take a hash of that and store the hash value so that even if someone can perform some attack to download this list of passwords they don't get the actual password they just get hash values and with a strong hash function it takes too long to be able to go backwards from the hash value to get the password so this is following the principles that we introduced in our earlier lectures if it's not stored like that then it's potentially exposing sensitive information to others and other confidential information say credit card numbers that should be stored in a manner such that if someone performs some attack that they still can't get access to that confidential information we'll see what shortly an SQL injection attack so how do you prevent exposing sensitive data encrypted at rest and in transit means at rest when it's stored for example if the information is stored in a database one option is to encrypt it before it's stored now there are some issues with that but so that's like with passwords or it's not encrypted but hash the value don't store the actual value and in transit that is the communications between browser and server encrypt those communications don't store sensitive data that's not needed so someone supplies their credit card to buy something don't store it after they purchased the item that is make that transaction and alright check the credit card then but don't after it's all been finished that transaction don't store the credit card any longer which would mean that the user has to supply their credit card information again if they want to buy something later so that's inconvenient for the user but it means if someone attacks your website and gets access to the database they cannot find everyone's credit card numbers so there's a trade-off that needs to be considered so one way to make sure that you don't expose sensitive data is not to store it or a store is a minimal amount as possible as minimal amount as needed now there's no one answer there is to what to store but depending upon your application alright we know about storing passwords other ways other things for example when forms the the web page is collecting private information disable autocomplete so not autocomplete from the browser's perspective but some websites you type in the first letter and the website actually the sends that letter to the server and the server sends back a list of possible strings that will autocomplete so you type in the first three letters and the website sends back okay the words that start with those first three letters so that makes it easier for the user but that potentially exposes private information because if an attacker can type in the first three letters and guess them then the website would send back all combinations that start with those three letters that are already in the database so using autocomplete on websites is a problem in some cases we will not go into any more detail about or a given more details about sensitive data exposure what else have we seen let's go back to the first attack and the most ranked number one in this list of the risks for websites injection and let's do it on our website bring up so we have our browser and remember the feature is that students can log in we have two students in this demo they can log in and see their own grades they cannot change their grades and faculty members can log in and see everyone's grades and can change grades that's that's the requirements so let's just check and log in as a student now here's an autocomplete but when I said autocomplete before this is this is the autocomplete of the browser okay so browsers when you type something in may remember information from forms and that's to do with the browser but some websites if you type in the first two letters here those characters they're actually sent to the server as you're typing them in and the website sends back a list here and it's using JavaScript sends back a list of potential values when you search Google it does that you type in the first few letters on the Google website and it sends back the potential list of the the most common strings that match that that's the autocomplete that I was talking about part of the server not part of the web browser we log in as a student and just check okay this student this ID can see their grades okay so this student has two has grades for two different courses they can view their grades how can they view someone else's grades well let's try let's go back to this form this form of viewing grades actually takes the student ID so this student we're logged in as this student with all zeros five all zeros but they know that there's another student this logged in as the student with all zeros try and view someone else's grades and know that the website checks it compares it's implemented such that the student that's logged in their ID is checked against who they're trying to view the grades for if they don't match and it gives this message saying you can only view your own grades so that's just a simple check to say compare who's logged in versus whose grades we want to see if they don't match you cannot view them how does it know how does the web server know who's logged in from last week or last lecture how does the server know who's logged in the ID of the user the session ID and the cookie okay every time we send a request the browser is sending a cookie to the server and including some information about that session and we can see it here this is the cookie for this domain my uni dot edu there's a username and a hash and the username for this cookie is this five all zeros ID so this is the user that's logged in at the moment so when we send a request to the web server this cookies included and the web server knows about okay this is the user logged in and they compare the logged in user ID against the ID of the student that we're trying to view the grades for if they don't match it returns an error so we can't see the grades of other students let's try an injection attack and an injection attack is about sending data to the server that triggers the server to do something it wasn't supposed to do we inject data into the server so that it will do something malicious preferably from the attackers point of view so let's see one so we're logged in as this student all zeros let's try and see if we can see data of other students and if we enter the course code and I've done it before so we've got auto complete here what I'm going to do and this is the injection attack I'm going to enter the course code which normally means that the grade just for that course is displayed but I've entered this this strange string here it is three three five and then the single quote or one equals one we'll come back to that but I enter that in and I submit what happened let's go back made a mistake student ID is the logged in user all zeros but I've created this special string here in the course code and now the logged in user all zeros can see everyone's grades so there are only two users in this database they can see the grades of the other user so this is the an example of an injection attack where the the user has submitted data to the server that caused the server to do something unexpected in this case and it's very common it's caused the server to display unauthorized information to this user in particular grades of other users and this is a specific and a very common called an SQL injection because it took advantage of the fact that this website was using a database using SQL to communicate between the engine and a database and it took advantage of one of the limitations in the construction of the query so let's see how that work what happened to do so we need to look at the code for what happens when we normally submit information here so normally when we submit the student ID from this query page query dot PHP we submit an ID and a course code what normally happens is that that PHP the PHP code takes the information in the form and creates an SQL query to send to the database the database then returns the information related to that query and it's displayed on this page so let's look at the PHP and the query on the server it's in the view dot PHP and without having to understand all of the code there's a few things that are of interest okay this is just a check based upon the using the session information whether the users logged in then this code the view dot PHP reads the parameters from the post so when you have a form and you click on submit that sends a post request to the server and the parameters of that post are the values of the form that you feel filled in so we had a what a student ID and a course code they were the two parameters that was submitted to the server and this is just the code for the PHP to extract those values from the post so the ID is put into the variable ID and a little bit later the course the course code is stored in the variable course so whatever whatever we enter in in the form the back whatever we enter in in this field in this field will eventually be stored as ID and course in the PHP code and then the PHP code there's some just checking will go down to the main part it creates a query it's hard to see there's a check it's hard to see this is checking about the cookie to check is the user either the faculty member Steve so the faculty member can do anything or this last one is the user name of the cookie scroll along equal to the ID so this was the check does the logged in user ID match the ID that we're searching for if so we can display the grades so if we're logged in is this all zeros user and we're searching for the grades for this all zeros user then we'll display the grades one of these lines creates a query so just an SQL query saying select star from course grades that's the name of the table select everything where the student ID equals the ID in that field of the form and actually I can just wrap that around it'll be easier just temporarily so where are we select star from course grades where the student ID equals ID and then some ordering that is or sort them by this order this is if there is no course so if there's no course field entered then it shows for all courses if there is a course then it selects star from course grades where the student ID equals ID dollar ID and course code equals the value of course order by student ID student ID is the column in the database and course code is the column in the database so that's the normal query let's just summarize that one I'll just copy and paste that to another file so we can see it so that's our our query that's executed now in the normal case when we enter in a course code here show you again so the value of ID will be five all zeros and the value of the course code will be ITS 335 so ID would be course IDS 335 therefore the actual query constructed is I think you'll know we replace this ID with the value and we replace dollar course with the value there so that's the normal case where when we enter in those values in the form it constructs this SQL query and that query is sent to the database select all values from course grades where the student ID is the all zeros and the course code is ITS 335 and it sorts them and returns them in the results and it showed on the web page and it shows simply that ID course code and grade now in the attack look what I entered in in the attack in the course code I enter ITS 335 and then the quote or one equals one so let's put that into our query here the ID is the same but the course value is ITS 335 quote or one equals one that was the value entered in on the form and let's now see what it constructs in terms of the SQL query we replace those values the ID is the same but here we're replacing dollar course with this string and we end up with ITS 335 single quote or one equals one and the closing quote so the PHP all it did is took this value and replaced dollar course with that value to construct the SQL query what does this SQL query do remember how the queries work with SQL queries you know okay this is what we select this is the table we select from and these are the conditions so the conditions are student ID equals five all zeros and course code equals ITS 335 or one equals one when does one equal one always so what's true this will be true this condition will be true always and because it's or we have this value and this or this which means this whole condition always returns true because it if the student ID is if this condition was false and this condition was false still this returns true so false or true returns true so the result is that this query will always return all all values in the database all fields and as a result it's effectively the same as a query select star from course grades or what a buy student ID because we have this or true everything's going to return true so I mean select all all rows from the table and star means all columns and that's why we get this result it submits the query and the result return is all rows from the database and as a result the user with all zeros has now seen the grades of the other user and if there are many users in the database they would see the grades of every user and this is an injection or an SQL injection attack the most common or considered the number one risk in web applications it this one takes advantage of the fact that we're using an SQL query to extract data from a database and that query was not constructed correctly it allowed the user to construct a query that was doing something unexpected in this case showing all data from the database and now we've exposed sensitive information from that query any questions on how to construct how to perform an SQL injection don't be confused by the name SQL injection doesn't necessarily mean injecting data into a database in this case we're not we're not sending any new data into the database all we're doing is selecting data from the database viewing data from the database what we're doing is we're injecting data to the server this data such that the server does something unexpected so we've sent this these two fields are sent from the browser to the server and the server is programmed such that when it receives this it will construct an SQL query that will return everything from the database how do you stop that how do you prevent such an attack sorry the detect detect what detect okay don't allow the user to submit this value to the database that's one way so detect if the user submits this string as a course code well that shouldn't be possible if it's a course code it shouldn't have all one equals one in it should be just a six letter or a five letter character so we could do some validation of the input so validate the input that the user has submitted to the server an ID for example should always be this what is it 10 digits value it shouldn't be some other longer value or shorter value it shouldn't contain letters if it were using SIT as an example the ID should always be 10 digits long so if it's not don't accept this query that's called input validation validate the input that's submitted by the browser by the user similar with a course code the course code should always be for example five characters with the first three are letters and the last three are numbers you could be even more specific and let's say that we know all of the course codes in SIT then when that course code is selected here an input then we can compare it against the known ones if it's a known one okay if it's something else don't trust it don't execute the query so input validation is one way because if you don't validate the input then it allows the attacker to submit anything to your database and if your queries are constructed in such the way like in our example then they can potentially do something unauthorized in this case of you data so this specific attack took advantage of the fact that the query the general query in the PHP is this top two lines took advantage of the fact that all we do is whatever was in the course field in the form is put here into the SQL query so by programming the PHP better we could have avoided that so input validation is one way check what is the value of dollar course don't immediately insert it in there any questions about how to do that SQL injection this one again is not injecting data into the database it's injecting data into the server to get the server to do something unexpected this is not modifying data but other injection attacks can do things like modify data in the database you can construct SQL queries that do much more advanced things depending upon the database server and the actual query format you can construct things that insert data that delete data from the database so you in some servers it will allow you to combine queries so that okay you have select star from this and then you have a second query at the end drop star from this table that is delete everything from from the database therefore the attacker could delete data from the database so back to our slides the examples which is similar to what we saw in our case the application normally creates a query from some form inputs so whatever the values are in the form creates a query the attacker enters a value into the form that causes some unintended query to be processed so in our case the course would expect to be just the ITS 335 but the attacker created this special queries this special string such that the query becomes something that returns true in terms of the conditions which means it selects all rows from the database or from the table result in this case the grades of all users are selected and therefore displayed how do we stop it well there are instead of creating the query direct like I did in the PHP instead of including this direct query you can many processing languages PHP and others will have parameterized queries we can construct a query in advance and it will only allow a certain set of parameters to be passed into that query depends upon the database and the processing language of how that's performed that's the recommended approach so things like prepared statements and stored procedures are related to different databases they can be used so that such attacks are not possible white listing or input validation when there's some input from some untrusted source so with respect to the server anything that the user submits can be considered untrusted therefore validate it check if this input is appropriate or not so you can have a white list that says that the only possible course codes are these 50 course codes for SIT if it's something else don't allow it or and or escape special characters so in this attack the special characters were the sorry the single quotes and the equals in here they shouldn't be allowed in the in the input form so you can escape them such that the the PHP would not process them as a a single quote and an equal sign that is the query would have ended up like and I can't remember the syntax if we didn't allow those single quotes it would have ended up like this which is course code the course code this is the string that it compares against it s335 or one equals one so when the database executes this query it checks in the the course code column is there a value that matches this string and it will return no and therefore this would return false this condition so if we didn't allow the single quotes in this field or if we extracted them from what was inputted then the attack would not be successful it's the fact that we allowed those single quotes and allowed us to construct a query that took advantage of that so injection and it's not just for SQL injection there are many other forms of inject injection submitting data to the server that is caused the server to do something unauthorized is considered the highest priority risk in web applications ways to deal with it really the best ways is to program your create a website correctly and again we will not go through it but the OWASP website includes many guidelines of preventing such attacks so they have what they they call cheat sheets on many different issues like parameterizing queries so that SQL injection attacks are not possible so they have maybe I won't try and load it but if you want to create your website and you've you're doing processing of database from forms then they have many different cheat sheets to show for different languages PHP Java ASP and so on how to program them so that SQL injection attacks are not possible so query parameterization is one and I think they may have a few others as well regarding SQL injection prevention how to prevent them questions about injection broken authentication and session management well we've seen a simple example of that that if someone can steal the cookie then they can log in as that that user well what if you don't use a cookie some websites use so the cookie stores something about the session whether the user logged in or not some websites don't use a cookie but instead store that information in the URL that's worse so including information about the session in the URL is worse than including in the cookie because then someone just needs to capture that URL find that URL and now that they can steal this session identifier and use it in their browser allowing them to access that particular session so if session IDs are included in the URL and someone makes that URL available to someone else then that receiving person can log in therefore use include session IDs in cookies only it makes it much harder for someone to discover what those values are even better encrypt the HTTP communications using HTTPS what else other issues okay you log in after some time the system automatic logs you out deleting the cookie but if that timeout is too long that is it the the cookie is saved on the on the computer too long that it means if you leave the computer unattended someone can walk up there and still use your session okay so you do the quiz in Moodle in the lab and on one computer and you finish the quiz but you stay logged in and you leave and then someone walks someone else walks up to that computer and they can do anything logged in as you on that system so how do we stop that the user should log out but if they don't log out we have a timeout say okay after five minutes they automatically logged out but if we make that timeout too long then it gives a chance at an attacker to get access if we make the timeout too short it means if you just stop using a website for a few minutes then you're automatically logged out and it's very inconvenient other aspects of broken authentication okay if someone can get get access to the password database and discover the passwords well that's that's not good that's a problem with your website so use appropriate password storage and selection mechanisms let's go to another demo of I think number eight cross site request forgery when I log in as a faculty member I should be able to edit grades so I log in I can view the grades of other students okay so I can view the grades of another student they don't have to be my grades doesn't make sense for the faculty member and I can click on these links to change the grades so I can see that this student has a D plus a C and an F for ITS 335 okay if I click on the link I can change the grades let's say for ITS 323 and it's just a simple scheme where I can select the new grade to be let's say C plus and if we view again ITS 33323 has been changed with C plus so this is a way for a user to modify data in the database there's a SQL query that does an update on the database how can a student change their grades well let's look and see what the student could do so I'm logged in at the moment I can see this student's grades a D plus C plus and an F for ITS 335 I'm logged in editing the grades and then I receive an email bring up the email I just receive while I'm editing I just received an email while I'm editing from a student and the student says I found this nice website okay and alright whatever the domain is and I'm interested in free stuff everyone is so while I'm browsing I'm bored with entering grades of students so let's visit this website and I know I think it's from a student that I don't know I know this student 501 2 3 4 5 6 7 8 nice student but getting an F for my course I click on the link to the website nice website it offers free stuff or whatever the website does okay fine now I would go back better continue entering grades let's view the grades again just check what's happened this student now has an A for ITS 335 how do they do that I didn't change it I don't think you saw it was an F before then I visited some website and I come back to the grading system and now the grade is an A let's see what happened in that case first note how is this changing of the grades implemented so normally when I want to change grades I select the URL and I can change by hovering over the link it's hard to see but there's an upgrade update grade dot PHP which takes three parameters in the URL the ID the course and the new grade F okay that's the URL and that submits the data to the web server which then creates a an SQL query that will update the grade in the database so that's how it's implemented so if I select F here a query sent to the server and the server changes the grade to an F and go back and check again alright it's back to an F now can a student send that query so could a student log in and try and update their grades let's try it and I'll copy the link so people can see it so update grades I'll copy the link I'll log out and log in as this student and now let's see if this student it can so that's the URL that it's hard to see but it takes three parameters ID course and new grade if we follow this link what's going to happen no it's not that bad a website that allows students to change their own grades so it checks the student logged in is this one two three four five six seven eight student they've tried to visit this link to upgrade their grade to an F from an F to an A but the website's implemented such that it checks who can update grades the only person who can update grades is the faculty member so because the server knows it's the student logged in because the cookie belongs to this student who's logged in and someone's trying to access this update grade code and it's the student trying to access that code checks can the student do this and it's got a check that says no let's have a look on the server let's go to update grade it has a check here that says if the username is Steve then they can up perform the code updates a grade but if the cookie belongs to someone else like a student then this would not pass and it returns an error saying you are not allowed to edit the grades so the websites implemented good enough such that students cannot update grades so how did it work we still saw that the the grade was changed from an F to an A what happened so we log out and try again log in we were logged in as the faculty member who does the cookie belong to it belongs to Steve at the moment but then I was viewing the grades of other students it's an F then I visited this other website free stuff okay because there was some email that I got saying go to this nice website so I went to this nice website completely unrelated to the grading system I visited and browse through there that's just refresh but let's just look at the source of this web page the web page looks fine all right there's nothing malicious on here but if we look at the source there's the title the header some text but there's an image in this web page and the source of this image is in fact our my uni website and it has this link to update the grade of this student we'll scroll across this student gets the new grade of a for this course so that's the link that means this image would be automatically loaded by the browser because what a browser does when it has this HTML it sees there's an image in here therefore the browser visits this URL the image width and height is set to zero it's so that it's not displayed in the in the browser so the user doesn't see any image there but the browser actually visits this URL the browser visits this URL and remember who was logged in in the browser the user Steve was logged in so the cookie that's sent to this URL is that that is used for the the user Steve and we know that the the website will allow user Steve to update the grade and therefore the grade is actually updated so there's several things happening there so this is called a cross site request fordry me we see what there's this other site involved this free stuff site and we've sent a request from this other site this free stuff website has sent a request to the my uni website to update the grade and because the user Steve was currently logged in on the browser on the my uni website the cookie for that was sent when this request was sent because what the browser will do is see okay a request is being sent to my uni dot edu are there any cookies yes there are there's a cookie that identifies the username of Steve so that cookie is sent in this request therefore the server receives the request with the cookie showing that Steve is logged in and executes the grade update so we've tricked the user into visiting some other website while they are logged in and that other website has a link a hidden link in this case to the the real website that does something that the student shouldn't be able to do but the logged in user can do the idea of including in the as an image why well because it triggers automatically the browser to visit this link with browsers what they do when they see an image tag they actually visit this link to try and download the image and display it there is no image here but they'll still visit the link the browser doesn't know and what shown is nothing because the image source the image height and width is zero so there's no image actually shown here there's no problem so the user that visits this website doesn't know that there was a link back to their grading system and they'd only know that the grades changed if they they check later questions about how that attack works cross-site request for now for this to work the malicious user must have some control over this website so they have this other website either they create their website themselves or they use an existing website and put content on there that includes this image maybe it's a comment in a forum so it's some content or some page here needs to have this image link to this the real my uni website so a cross-site request fordries CSRF the application allowed the logged in user to change data so Steve could change the data the attacker has some other website that they control and they include a link that's hidden from the user to make a change and they somehow trick the the victim the person that's logged in to visiting that link therefore performing a change because the browser will automatically send the cookie to that domain if they're already logged in so the victim me in this case was already logged in so there was a cookie for this website and when I follow this link the cookie is sent and therefore the server recognize it's me that's logged in and therefore the updated the grade was changed these URLs on the slides are slightly different from our demo but the same concept so it requires the attacker to have some control of another website it requires them to get me to visit that other website while I'm logged in if that works then we can perform some unintended action how do we stop it in every request that is sent include some unique some value that changes and cannot be predicted by the attacker so even if the attacker could do this the request that is sent in this case when I click on the link should be something that is comes from the the web server so that the attacker cannot construct this link if they try and visit this link that they don't have this unique token and therefore the server will recognize this is not from the actual user that's logged in make sure the token is in the cookie or a hidden field for example so hidden fields in forms can be used to include some some token some random value that identifies this is a request from the the user that that is logged in it's not from someone who's creating this CSRF attack so there are ways to do that but if you just implement the updating for example in this simple way then the attack successful so cross site request fordry again takes advantage of the attacker tricks the user to visit some page that sends a request to the real website while that user is logged in any questions on this last demo let's go through in the last couple of minutes just that the other attacks not through demos just these slides that was number eight we've seen number ten before the redirection number nine using components with known vulnerabilities so if you use some software on your website that has some bugs and the attacker can take advantage of those bugs that's the main point here so using most large websites that the people who implement them don't implement everything themselves they use software from other projects from other systems for example using other libraries other application development frameworks content management systems if you use these other systems in your website but these have bugs then again someone can try and attack your website so it's important to be aware of all the components you're using in your website and particularly the versions being used and keep up to date as to any announcements on bugs in those components and make sure you have a way to test these components if you update them on a regular basis make sure that they still work let's go backwards then let's go back to the start so number one injection we've seen number two we've seen that is if the authentication is not implemented correctly or the session management then the attacks can occur number three cross-site scripting let's say there's a web page that's constructed using some unvalidated input so some PHP that displays the value of the name parameter in the URL then that allows an attacker to create a URL that sets the value of name to some script okay so here HTTP SIT dot TH view dot PHP name equals Steve that may be the normal value but if the attacker can submit anything here is the name like Steve followed by a script and some JavaScript then what happens when they submit this is that this PHP executes or puts this script inside the page so this JavaScript would now be put inside the HTML page and when the HTML page is loaded in your browser the browser executes this JavaScript so yeah inside the the script tags is JavaScript what does this script do it redirects you to some evil website to do different things it may redirect you to some other website under the control of the attacker which has some code that steals your cookie that takes a copy of the cookie that was sent in the request and therefore that evil website then has your cookie value and now can use that cookie to do other attacks to steal your session so this is so cross-site scripting using another website to and using a script to redirect you to that other website and does whatever it can do then steal cookies just redirect you to sites that have viruses and so on again this is about there's some input in this case in URL that is not validated so how do you fix that everything that is submitted to your server check whether it's trustworthy or not so input validation if name is a is input then check that it doesn't contain any characters that are unexpected so in this case name the string it starts from Steve and ends all the way here so escape untrusted data would be to if this is a string don't allow less than a greatest than science escape then that is effectively remove them from the string so that your browser would not execute this as a script so remove all the untrusted characters in this case white list input validation again if the input is this string check it against a list of valid inputs is it valid if so it's okay if not don't process this return an error so white list means check it against known good values and there are libraries that will so web development libraries that will help you do this input validation to escape characters and check data so sanitize the input the others will go through and finish next week okay so the two or three that we haven't gone through will just discuss them we won't have any demos but some are quite simple we'll finish with them next week