 All right, folks, let's get started. One more week. Plus, like, about half a week. Let's go. Do you have notes? Yeah. No, it'll be over when it's over, just whether you pass or not. Hey, failure is fine. Once people fail. All right, any questions before we start? I don't think it's going to be super long. So now I'll get to the crown jewel of web security that we've been hiding from you up until now. So, cross-site scripting is the most prevalent vulnerability on the web. OWASP, the Open Web Application Security Project, so they're an organization of security people, and they come up with every year a list of top, or every few years of the top 10 most prevalent vulnerabilities on the web. Of course, there's all kinds of controversy surrounding those, but cross-site scripting is usually always near your top. So, this is why I said that the same origin policy is one of the most key things to web security, and that is because, fundamentally, what cross-site scripting means is that an attacker is able to bypass the same origin policy. So, what would that mean? Upload code from a different site. So, just if they're able to bypass the same origin policy, so what would that mean that they can do? Send some payload to their server, which is supposed to be on the same order. Payload? Request, or whatever. Request. So, let's think about this. What can some JavaScript code running in the same origin do? So, what can, let's say, Facebook.com's JavaScript do? It can send responses back to Facebook.com? What else? Access files on its server. And try to make requests to files on that server. Access all of the, access all the HTML that was returned from that page, including any types of tokens or forms. What else, what else are you going to look for? Cookies, it could read the cookies, right? So, the core thing to think about is, okay, now if we're saying that JavaScript, that an attacker controls, is now able to execute in the same origin as Facebook, what capabilities do they have? And it's all of those things, right? So, the attacker could completely control the DOM of Facebook.com and completely change the layout. The attacker has access to the cookies that Facebook.com has access to. It can make requests. So, we'll see all kinds of cool stuff. So, this is the core. So, at the core, if you can bypass the same origin policy, that really is what cross-site scripting is. We'll see that the name cross-site scripting is a bit of a misnomer. It doesn't really mean anything. The core is being able to bypass the same origin policy. So, you can even do cool stuff, like getting back into the day, you used to be able to trick the browser by using Unicode or something to think that the iframe you were loading was in a different same origin, right? So, you can try to find bugs in browsers based on how they compute the same origin to exploit those. That would be, I guess you probably wouldn't call those a cross-site scripting attack, but they would definitely have the same result of bypassing the same origin policy. So, if you guys were assigned this, you'd like to classify things into neat little categories and boxes. So, here for cross-site scripting, we categorize them in two different ways. Cross-site scripting attacks, which is basically when, so we think about how, so now the question is, so we know the result is that cross-site scripting attacks bypass JavaScript's same origin policy. The question is how? So, how does the browser, how does the browser assign an origin to JavaScript code? So, which website? Isn't it always? So, it depends on where the page comes from, right? So, let's say, so this is why it's a little tricky just thinking about the JavaScript there. So, let's, oh, no. Oh, yeah, that's nice. I promised I won't drop. Okay, so, an HTML page. So, because we're good people, we'll use example.com as our domain. Why do you use example.com? Can I just use any random name if I just want something that's not worth the value? Yeah, so example.com is actually an RFC, so the camera crew, but somebody guarantees that example.com will never be owned by anyone else, and you can actually use it. I think they own .com.org. So, there's an RFC that specifies this, so you should always use example.com in your examples. I've heard of cases where, like, people use a different domain and then somebody buys that domain, and they get a lot of people running stuff in their command line, like taming that address or doing random things, and it's super annoying. I think somebody has a test.com or something like that and they get a lot of emails from test systems. So, and this is the domain that I go on, and I have, what type of JavaScript is this? Inline. Yeah, okay, inline. So, this JavaScript is an inline JavaScript. What is the same origin domain of this JavaScript? Example.com, AD, HTTP, right? So, port, post, and... and a post named port and protocol. Cool. So, this definitely makes sense. Somebody said, hey, the JavaScript wherever I sent from is here. Now, what happens if I do... So, this is going to then go... and your browser is going to do what when I see this tag? It's going to... It's going to make an HTTP different request to this Google.com. Let's... This is a bad example. I'm sure this file doesn't exist. Right? And this returns... This returns this. So, what is the origin of this code? So, in a script, in external script, this is the way to circumvent the same origin policy. By the developer including this script in the Example.com page, they're saying, hey, go fetch this code from somewhere else, execute it in my origin. So, this code will be downloaded from Google.com, but we execute it in the domain of Example.com, HUE, and PortAid. So, this is the fundamental way to circumvent the same origin policy. Now, the browser... When the browser gets... Let's say this is the HTML response that the browser gets. Right? How does the browser know which... the inline JavaScripts and the external JavaScripts? Yeah, how does it know? I mean, it's a... It's not a complicated answer. So, what's that? It has a parsing engine which... HTML parsing. Yeah, it all comes back to parsing. I keep parking on that because it's actually important. So, it hasn't parsed this HTML page. When it sees this script tag, it says, okay, I'm executing the script, and I know it's an internal script, so it's executing the same origin. Great. Then, we get here, it says, okay, there's an external script, but set this origin. When we've touched this, there'll be this same domain. So, the same origin domain here, v, hdv, ad, example.com. So, what happens... So, okay. So, fundamentally, the way an attacker... Sorry, sorry. The way we can circumvent the same origin policy is essentially either through external JavaScript code. Right? The key question is, what JavaScript code did the developer of example.com want us to execute? Can you tell? So, I'm trying to... I'm trying to build that somewhere, but... I can't tell because there's just a link there. Right. So, fundamentally, the browser has absolutely no way to know which script tags the developer intended for there to be versus which ones were maybe injected by a... an attacker. So, let's say v... Let's say this is a PHP script. It looks something like this. Super simple. Echo. Okay. So, this is now the PHP code. I mean, it's a terrible program. I guess... So, fine. So, we'll be... It's not very good. We'll just throw it on the HTML tags to be good people. Right. So, it's super simple, but it's something that just hopefully will illustrate a point. So, this is the code. If we access user foo, what HTML are we going to get? Something like this. So, this one likes foo. Now, when we look at the PHP code, what JavaScript did the developer want us to execute? None. Zero JavaScript code, right? There's absolutely no JavaScript code in this PHP function, right? Now, what if we wanted to execute some JavaScript code? What can we put in as the value for the foo... for the use variable? Yeah. So, we give you search tags. Now, is this correct? Can we just send this? What do we need to do? Yeah, I'm going to view our own code just view parameter. Well, let's send it to the party button. Right. Then, now the question is, what exactly is this PHP code going to do? Yeah, replace the foo with whatever you have in here, which is this script tag. And then, when your browser gets this response, what's it going to do? It's going to parse it, and then it's going to execute the things inside those script tags. And then it's going to show an alert box. So, that JavaScript code that got executed, right, it's executing in the origin of hdpexample.com 80. But where did that code come from? Did it come from the developer of example.com? No, it came from, well, here it's coming from the parameter, but I wanted as an attacker to get you to execute code in the domain of example.com. What could I do? And then, how do you get me to execute that? Send the URL to me and trick me to click on it, right? So, send me an email that says, hey, I found some students cheating in your class. And then, link me to this. Immediately as I said it, I was like, yeah, I would get me to click on it. Right? So, this is an important distinction here. So, and would I click on a link that looks like this? Hopefully not. So, what would you do to obfuscate it? Do you use a shortener, like Vickly or something like that? What else? Encode everything, including the script. And the alert, everything, right? That would actually super you. You're actually used to getting these emails from websites that are just these URL encoded, huge garbage strings. And then, let's get on with that. So, this is an example of what we call reflected cross-site scripting. So, the idea is the cross-site scripting payload is taken from a URL parameter and is being used and displayed back to the user. So, in order to, so I guess we should, so do you guys, as an attacker, do you think you could get somebody to click on a reflected cross-site scripting link? Yeah, pretty easily. So, that's part of the way we think of the threat model of the web. An attacker can basically try to force you to go to any website, right? I mean, it's not really forcing, but eventually they, I've seen crazy things. This is actually how they did some of the attacks. I think it was the Aurora attacks against Google, is they figured out who worked on the team they wanted to get on, then they figured out where their Facebook accounts were, created somebody who was an account of somebody that they knew who was not on Facebook and then friended them through there and then sent them a link during work hours to their Facebook, of course they're on Facebook, and then they clicked on that link on their work computer and then went to a site that infected their browser through a drive-by-download attack and executed malware on their machine, and that's how they originally got into the network. So yeah, clicking links is bad. It also works the other way. So there have been cases of people, law enforcement and the FBI, finding out who bad guys are because they infiltrate like IRC in different organizations and then get people to click on links that then expose their IP addresses. So yeah, they were careful out there. But it's part of the threat model of the web, right? So we can essentially get anyone to click on the link at any time. So, and normally the way you think about these are some kind of error message or a search field. I mean, this is the kind of standard ways that these reflected cross-site scripting can occur. Anything that includes the server's response, the includes the cross-site scripting payload that's parked on the request to the web server. Now, what would be the flip side of reflected? I mean, not literally the opposite word of reflected. I don't know what that is. Yeah, so what would be a typo? How would you describe something that is not a reflection? Transmission. Injected. Yeah, so describe it. What would it be? Is that injected? That's it? A thought, a one word thought. Stole the script in a database speed and when the data speed is loaded on a gateway, it will execute that script. Exactly, so think about like any, let's say a web page that is what am I thinking of? Web page, vulnerable, it's gross. Oh, oh, oh, like a comment page on let's say items on Amazon, right? When you make a comment, that comment is stored by Amazon and every time somebody visits that page, that comment is going to be displayed. So let's say there's a cross-site scripting vulnerability there. Now you as an attacker, inject your cross-site scripting payload, the web application stores that and sends that to every single person that requests that page. So let's step back for a minute and let's think, how do we fix vulnerable.php? How do we fix this code? What did the developer likely intend? Did the developer intend for people to be able to input arbitrary HTML tags here? Probably not. Yeah, sanitize, how, what kind, yes. So the key problem is, so anybody in php? Is it just HTML entities? Yeah, it's just a special shot, a special shot. I'm not having any. So it doesn't have that functionality yet. So by doing this, now what will be the output if I drag this payload? What does HTML special character do? Is this going to change? So it's going to replace, it's not going to interpret the script tag, it'll just interpret it as that tag. By escaping all the HTML characters. So less down the greater down. And so on and so forth. Just those actually. Right, so the web application, the php code is making, essentially doing a string replace on any of these special characters with the HTML entity encoding version of those special characters. So now when the browser gets this response and it sees this ampersand LT semicolon, what does it do? Does it interpret that as, does it say that's a start and a start tag? What does it say? This is the start of the less than character, right? This is text as the less than character. And it'll keep going. So you will actually see in the HTML of this page will look, it will be a start script tag, it will say alert tick, XSS tick, and then an ending script tag. So you will actually see that as text. We get the distinction here, but it's super boring. So stored attacks are very similar. So the payload is still going to be the same. The difference is in how it gets transmitted to the users. So stored cross-site scripting, basically the ejecting code is permanently part of the web application now. So it is part, it's not part of the application's code, it's part of the data of the application, and it will get sent for every single request. I actually remember seeing these, gosh, way back in the day on GeoCities, I remember the GeoCities had like guest books. And I found out at some point that if you put in like HTML tags, it would completely just ruin the rest of the guest book, but I never knew what that meant until much, much later studying this and being like, oh, that's essentially what was happening. Like, if you did an end HTML tag, it would basically ignore all the other guest book problems. So the other third way, so the important thing here, the way I like to think about these, these first two, where is the vulnerability in this code? The server side, in the PHP code, right? And again, if we go back to here, this is exactly the same problem that we had in cross-site scripting, right? In cross-site scripting, we had PHP code concatenating together strings in order to send to a SQL query, but here we're concatenating together strings to send where? To the browser, right? As part of the HTTP response. So here we're essentially concatenating strings together and we're doing it in an unsafe way where the user's data, what should be data, will be interpreted as code by the browser. So it's an important distinction and it's important that in both cases the vulnerability exists on the server. So I can go back a couple to the server side in cross-site scripting because that's where the vulnerability is and because that contrasts with the third type of cross-site scripting vulnerability and that's DOM-based cross-site scripting, which is, well, so the idea is so JavaScript, as we talked about, has lots of different functionalities. One of these is an eval function. What does the eval function do? It takes string, which is, you know, a string text and turns it and executes it as code, interprets it. And so now if the attacker can control that JavaScript, right? Like let's say it grabs one of the parameters and takes that and then injects that into the page or just calls eval on it, right? Now we can put arbitrary code in that parameter and now that is in cross-site scripting vulnerability, but where is the actual vulnerability like? Can you fix this with changes to the server side code? No, because the server side code isn't vulnerable, right? The server side code is not the thing that's turning text into actual code. The vulnerability exists on the client side, so I like calling these client-side and cross-site scripting because to me it makes much more sense because it takes a completely different mindset to think about these DOM-based cross-site scripting. I'll give you an example. Okay, cool. A little bit of another example, maybe a DOM-based XSS. So reflecting cross-site scripting, we saw it like this as we saw. When we go here, we have Adam. We can see him here. If we do reflect in XSS, it'll say XSS here. So by sending out that page, you put your clients at risk or... Which page? This page? Like in a client-side cross-site scripting vulnerability, you're putting your clients, the kinds of your site at risk to getting attacked. Yes, so for any cross-site scripting vulnerability, the end people who are going to be affected are your users. Okay, so the question is where does the vulnerability exist? Does it exist in the server-side code because it is incorrectly generating an HTTP response or does the vulnerability exist in the JavaScript code? Let's go over your example. I actually don't remember. We're going to have an example. So that's where I go on. So I'm going to go to this page and it's going to give me a constant output. Okay, so it's going to give me nothing fancy. There's nothing in here. It's not doing any server-side processing of code. It's always giving me a constant output. But let's say this one does something silly and it doesn't necessarily need people's help. What is it, locations? I think it's just locations about hash, right? Let's say this is a search chart. So let's say here it's like this. So we're talking about which part is this in the URL, in the URI, the fragment? What's interesting about the fragment? What is it used for? Sub-resource identification. Yeah, so identifying, so remember, a URI specifies a resource. The hash, everything after the hash represents the fragment which is the sub-resource. So what part of that resource? Realistically, it's used mostly in your browsers because there's an element with the same ID. So if you have a DOM element with an attribute ID equals food, it will automatically scroll down to have that be where food is. Now, the super interesting thing is browsers, because they know that the fragment is only meant for the client side, right? It only affects the user agent. Your browser never sends the fragment part to the server. So when you make a request for this page, the web server is only going to see a request for example.com.nom.html. That's it. So what this means is, so now if I want to execute code, do I do this? I hear no, why no? You don't need the script tag. Why? Because this is not valid JavaScript code, right? This is the HTML to start a JavaScript code. Everything between these tags is valid JavaScript code. So how do I change it? Get rid of those script tags. So now here, the problem is there's a vulnerability in the JavaScript code I'm sending to the client. And the super interesting thing part about here, and it's kind of a fine distinction, but when I sent this request, what did the example.com see as the URI they're trying to access? The entire thing with the script tags, right? So the example.com could actually be looking at their logs to try to see if there's any types of attacks like these. And actually, on the flip side, they're going to be attacked like this all the time. So it's kind of a fool's errand to look at all of them. But at least you have a log of this happening somewhere. What does example.com see in this case? DOM.html and nothing else. So they don't see any of this attack on the user. There's also other interesting distinctions here. Is there a question? Yeah. Apart from the URI, is there any other way for which we can take some script in the event? Yeah. Act. Oh, you mean from here? Yeah. Yeah. So this could be anything. This could be, I've seen, there's crazy examples of like getting tweets on a topic. Like taking a tweet or something and then calling eval on it. Or getting your user preferences as a JSON object instead of parsing it as JSON, calling eval. And maybe they're not encoding your value correctly when sending it back. I've actually seen that one in a pen test that I did. Was they, your preferences were, they posted, I think, as like an object, but they weren't validated as an object. And you were sent back whatever you sent back and they called eval on it. So you could create this object that had additional code after it so it would do basically two things. That was a really fun one. So in order for this to be vulnerability, you'd want to get something to pick on that. Correct. Just like in the reflected case. So you could, and that's also where it brings down a little bit. So you could have a DOM-based XSS that is stored because the JavaScript code is fetching it from a server. You could have it where it's reflected, where it's getting those parameters. You could have, you could, there is kind of this category of what they call self XSS where, like let's say it was the cookie value, right? Like to set a cookie, you have to be JavaScript executing in that same origin. So it'd be very difficult to get somebody else to set a cookie on your behalf unless you found this other weird functionality in the website that allowed you to influence the cookie value. I mean, that could be possible. Yeah, cross-site scripting is a huge deep rabbit hole that you can go down into. I think that's important here. We'll come back to it. Okay. Reflect the XSS so you can see something like this. Oh, that's a good one. So if you try this in your browser and you're using a modern browser, it will most likely not work. Why? Could you do something wrong? Probably. But then once you fix that, it still doesn't work. Yeah, they're doing something incredibly simple, which is they look at the URLs. If any of the URL parameters have script tags that are exactly the same as script tags in the response, they'll block that script tag from executing. So yeah, they do have very basic protection mechanisms against these super simple reflected cross-site scriptings, but not always. I mean, not all browsers, and not in the same way, and there still can be ways even around that. So you can try to evade those in various interesting ways. Sweet. I think we did all this. Oh, yes. So the other thing is, so we'll talk about attacks, right? We talk about, okay, what can the attacker do with this capabilities, right? So if you think about from the attacking perspective, do they want to send you inline JavaScript? Why or why not? What was that? It could have a lot of text. It could be really large, depending on what you want to do. Yeah, that would be one. What if it would be another one? What if they made a mistake? You guys never make mistakes? Yeah, so if we do, if we inject instead of an inline JavaScript, we inject an external JavaScript to something that we wrote, now that will be fetched and executed from each of the browsers that we exploit, we also may be able to get their IP address that way and may be able to get other information about that. The downside is it gives them a place to kind of lock and stop our attacks because we have to put some kind of source that we get in here. But maybe we can point it to like a, you can use like a GitHub gist or something like this, like a random one or something like that. There's probably ways to get around that. Okay, so what do we do, right? So we can, as we saw, we talked about we can steal cookies. If we steal cookies, then what? Because that user... We can try using those cookies to authenticate to that user to the website? Exactly. What else can we do? That's it? We can try to access some information in the database using their... Don't you mean in the database? Can we talk to the database directly? No, but we were, they had their user credentials. But we don't have their user credentials, but we're executing in JavaScript. Yeah. Can do basically anything the user can do? We can do anything the user can do on that website, exactly, right? Because we can inject requests to that website, asynchronous request, and every asynchronous request we make to that website, the browser will automatically send along the cookie, and so the server says, hey, it looks like this user is pressing this link or is requesting this resource, great, give them whatever they want. So we can fundamentally perform any action on the website that the user could perform. So this is insane, right? So this means any JavaScript code executing on your browser, we could... Any JavaScript code that's executing in Facebook.com could do anything that you could do on Facebook. You can post on your wall, it can post on people, it can message people, it can literally do anything you can do. The same thing with in your bank, if any JavaScript code is executing there, they can transfer money, they can do all kinds of nasty things. And it's coming from your IP, too. If you steal their cookie, they may be checking IPs. What if I wanted more permanent access? We have more permanent access, what are you talking about? You could get their password... How? You can make by using... Browser stores... Browser may store it, but you probably can't access it from JavaScript. You can access to the data. What was that? Get access to the data. What data? You can steal their cookie. You can steal their cookie, but that's not... Maybe they're going to wipe out their session, or maybe the session's only for like a day. I could create a pop-up with an Oscar password and then crack a pop-up. So you could create a pop-up that asks if they're using a password. That's good. What else? You can request for the reset password. And the reset password page usually asks what an email ID or who sent the reset password. But a reset password would have to go to their email address. So I don't think you as an attacker would be able to see that unless you can somehow influence where it got sent. Maybe you could use the application and change their email address associated with their account and then reset their password. Could you log their keystrokes if you got the script on the login page? You can definitely log their keystrokes on the login page. But to go up with... So to follow up with the pop-up, pop-up's a good starting point, but a pop-up would be suspicious, right? Because a pop-up, you know, no website pops up for using passwords except for terrible like SharePoint sites in ASU. But what you could do, you have total control of the DOM. So you can change the DOM of the page to be exactly like the login page of the website. And what's even more insane because this is happening over, let's say, HTTPS, you'll still get the green lock because all of that code is actually coming from that website, right? I almost said the name of the website but we're gonna just do it. Right? But the page will look like the login page. The only thing that will be different will be the URL bar at the top. Right? And again, you can encode that so it looks maybe more legitimate. Right? So imagine somebody sent you a link to, let's say, Facebook.com. You click. You go to something that's Facebook.com but it has the... But it's a login page, so you log in, you fill in the form, you hit Enter, and when you hit Enter, the JavaScript code now goes, or maybe it's key logging in, it goes in, it looks in the form, grabs your username, passwords, sends it to the attacker, and then goes and submits the form to the real login. So now you're actually logged into Facebook once you get in. All kinds of fun games for you, but in that way, and now if you're using a password, you can get in forever. It's not limited to a certain time frame. So yeah, I can send. So I have done this before now for Facebook.com but for another domain. It is super cool because it looks exactly... I mean, it literally is. You use the HTML content and all the style sheets of that website to make a login form that looks 100% identical to their own site. And then... Oh, I have my email address. That's nice. It's been my career. And then... So all I have to do is basically encode this here and URL code all this and it would look like kind of random gibberish. And maybe I can put something before this, like login.php and then something, right? Or I can change the URL link. So you can do really cool stuff here. So sort across that scripting. The idea is essentially as we talked about a two-stage attack, right? So you first, the JavaScript code that the attacker wants to be executed then an attacker themselves sends it to the server in an HTTP request. The web application stores it usually in a database but it could be a file or anything like that. Then the victim downloads and executes the code when another person uses that page. So all kinds of things are vulnerable to this. Stored XSS are really, really bad. And you actually get into this really interesting circumstance if you mix a social platform with a stored cross-site scripting vulnerability. So there was a case a long while ago back when MySpace was actually still a thing where a security researcher found a stored cross-site scripting on the profile pages of MySpace that anytime you visited an infected profile would change your profile to include that code that would infect people. And it would also add this and Sammy is my hero to the bottom of the page. And so you see in the span of 24 hours like how millions of people had this and Sammy is my hero at the bottom of their profile. So this thing's spread throughout the network. This also happens with Twitter, cross-site scripting vulnerabilities that are once in a while so Twitter will have something like this and it will just spread throughout the network because of course the first thing you do is you write a tweet that includes this thing, right? And then anyone else who sees that that's vulnerable writes a tweet and then it spreads vitally throughout the network. Okay, so JavaScript so actually getting to JavaScript execution is not always as simple as we have here a script text. So often web applications perform some kind of filtering or sanitization mechanisms and if they're the only way to be 100% secure to use something like this HTML special characters. There's a lot of different ways that we can execute JavaScript. So we can... there is now a... there is a cross-site scripting cheat sheet that you can go to that has a bunch of different cross-site scripting payloads each that have different characters and different types of things. You may not be able to use single quotes or double quotes so how do you get around that? All kinds of cool filters out there. There's also very interesting when we started digging around in there because some of these payloads are specific to specific browser versions so why is that? Yeah, so each browser implements HTTP... sorry, HTML parsing differently. So depending on what browsers do in the case of errors maybe they do something that you can actually take advantage of. And so this would be a simple type of thing. We can code it so any coding we can get around there may also be a web application firewall in the way. We can inject so the other cool thing is we may not even need script tags at all so if somebody is filtering on script tags like the script keyword we can use body so the body tag has an onload event and attribute that that value is JavaScript so whatever is inside there will be interpreted and executed as JavaScript when the body tag loads. Super interesting one so let's say maybe we can use bold tags if we use the on-house over event this is a JavaScript event that will fire when the mouse goes over that part of the page and so then whatever is inside the value of that attribute will execute. What's the downside here? You have to mouse over it so how can you help them? Make it span the whole page? Yes, this is actually a super cool thing to do. You can use CSS style sheets to make that element be the entire width of the page and you can even make it transparent so they can still look at the rest of the page and then as soon as they I think right when you go to the page if you don't move the mouse it won't fire but you move the mouse any pixel and that thing will fire which is a lot of fun to play with and then you can even have this JavaScript get rid of this element now so you don't have multiple events firing so you can do anything in JavaScript so you can then move that away and then the page will see exactly the same. This is actually one of the easiest ways of doing this that you get this auto-loading behavior so the idea is you create an image tag you create a source usually you want to you can put it to some file that doesn't exist and then image tags have an on-error handler which will trigger whenever there is an error loading some of the content and so that is JavaScript code in there that will run when there is an error so you want to basically include the image source to something that doesn't exist because when it doesn't exist that's when the error handler gets triggered and so this will happen automatically yeah you can even sometimes use interesting like you can try utf8 encoding part of this JavaScript you can even do this with so it seems like you need single quotes or double quotes but you can actually execute arbitrary JavaScript without like you can do without any single or double quotes in here so here I'm creating a string from a regular expression in JavaScript so it's turning this into a string atom and then it's alerting that up so lots of cool stuff and this is like I said this gets really really complicated okay DOM based so yeah the other term is third order I don't know we talk about that necessarily but I prefer client-side XSS so this this is an interesting different example so here we're setting the name to be the location on hash and then we're writing out using document.write hello name so what does document.write do it writes what ooh yes so it's it's writing to the document and what does the browser then do with what's written parses it as HTML yeah so it means any script types and then it will be it's a lot so we're going to something like this example.com test that HTML hash tag atom it when we go here into name and then it will print out hello atom so it will write out to the document hello atom now if we go to example.com test that HTML hash the script now why in this case did we need to use the script tags versus in the previous DOM we needed to just do the alert was it yes because we're using document.write the HTML parser is parsing the page whereas eval assumes that it's going to be JavaScript code that is parsing so the warble crossline scripting that I talked about so there's a case in 2005 was the sandy as my hero face a tweet deck there was a vulnerability in the tweet deck application in 2014 that allowed a warble crossline scripting vulnerability oh so this is cool so so the sandy as my hero had a he wrote a blog post all about what he found and so if you look this is a screen shot from back then if you look you'd see all these examples of this sandy as my hero and then you can see this one here is tech support got forms my stick it's got hacks and then even on NSN search which is a huge blackjack is sandy as my hero and so the other thing that they would do with them is they would all friend him sandy so all the JavaScript code would not only propagate themselves but also friend him and so he has also millions random requests here almost as popular as Tom so crossline scripting is a huge rabbit hole actually we're trying to close here now we may well we'll talk about it in a second but we may go more into depth in here we can look at all kinds of cool weird types of XSS payloads and those kind of stuff but fundamentally crossline scripting is incredibly difficult to prevent why client side is incredibly difficult so even thinking about client side crossline scripting is incredibly difficult but even just server side crossline scripting why is that difficult? yeah any every just like SQL injection every time you use user input in a query it must be sanitized similarly whenever you're using user input in an HTML response back to the browser back to the browser which is almost all the time right a lot of your content is going to be made based on user input now any of that can be used as a crossline scripting attack incredibly difficult to prevent because every single piece of data that came from the user right and this is where we talked about the injection vectors in a web application not only all the parameters but also post parameters cookies request headers anything from the database content anything from a file actually found back I don't remember I think it was probably I don't know there used to be this web music service that was eventually bought by Apple which eventually became Apple music it was this streaming music service and so I was using it and I found out that they had this functionality to upload your own music file and then I saw it get included in the website so I was like I wonder if I make a name of a song as script tags like an alert and I did it and it worked and so I got code execution there playlist so that I could send people the link to that playlist and then it would be basically a store cross-eyed scripting on anybody who visited that playlist and then I emailed them and I literally never heard from them ever and then they were bought by Apple so I'm sure they could care less and that entire website went away it was actually a really cool model because they had this thing where you could stream music for like 10 you could unlimited you could stream buy albums for dollar or so I don't know it was an interesting model anyways so this goes into the file content literally any place that user input is used and it doesn't need to be to that application it could be anything else they're pulling in any third party content languages so this is actually what gets to be incredibly difficult so let's go to the so we go here so the solution here is pretty simple we talked about it HTML special characters so let's think about a different name let's say like this let's say we'll do this so is this safe your instinct at first should be yeah right because I took something that was safe right I'm using the correct sanitization function and I just moved it right I didn't move the code itself where did I move it I put it into the ID attribute of a div tag maybe but let's let's try to force it to do can I add different attributes to this div tag what character would I need in order to do that double quote double quote so what is is double quote an HTML special character I'm actually getting an unknown character because I don't actually know what it does it almost keeps single quotes so single quotes so I can change my example there we go I'll go to the manual we also learn that in my class once again actually I don't have any question on me okay oh it doesn't do that only end quotes it's set because unless it's set wait it replaces it unless oh this one but only one yeah okay so it's a special option yeah so let's do change this because we know to HTML these are exactly the same right so if I try to do too much if I try to use our previous payload it will look something like this is this across that serving order movie no definitely not so now what character do I need to escape from outside of this attribute single quote and then what do I need based on the HTML spec to start a new attribute space well we'll be awesome there since we all know how to read you are not coding now percent 20 and then let's say I want on mouse over and then is equal sign in here no equal yeah the second single quote that's going to be added there but actually we try out the browser first but a lot of browsers are very tolerant of extra errors in there so it will just probably ignore that second one so now when we have HTML special characters applied in here does anything get changed so now the HTML that gets sent back to us is going to be this and now how do we execute a JavaScript on this page yes so we successfully perform a cross-site scripting attack even though they're using sanitization what seems to be correct sanitization so what's the problem yeah so fundamentally well the ID so the problem is right when the user input was being output in between tags right here what the attacker needs to execute JavaScript is an opening script tag right fundamentally you can actually fix that by just changing every less than symbol to ampersand LT semi-colon maybe that may not be 100% secure can't remember but anyways that's the character they need they need a less than symbol in order to transition the parser to start interpreting a script tag but here now when I move that exact same what does the attacker need to break out of where I wanted that to be a single quote which they may not be which the sanitization that I'm using may not be encoded correctly so this is actually I really believe is the fundamental reason why cross-site scripting is still so prevalent today and still occurs even on Google products right I believe it is not only that you need to sanitize all of the user inputs but you need to sanitize them for the context they are used in the HTML that you're generating so things that are used in an attribute need to be sanitized differently than things that are in between tags let's look at another example because I actually really like these examples so what's the purpose on this code why would somebody write code like this it's easy it's easy to do what but what's the why are they doing what is the purpose of writing code like this I know in this style it's easy yeah so I think the general concept is to put some value that the server knows into your JavaScript code to make it more dynamic exactly so the idea is like the username like putting the person's username into a JavaScript variable that JavaScript can use to manipulate or do something like this the good ish way to do this is to have a JSON endpoint or some JavaScript object that you can fetch to get all these values as we'll see but here this is a very natural thing to do you're essentially passing some data that the server side code knows and trying to pass it to the client side code that's going to execute on the user's browser correct so this cannot go on right so that when the user fetches and requests this page right the PHP code will be at whatever the view parameter is of get so like let's go over a a non XSS who do you guys think that's not so when we make this request is this what we're going to get back no why not the PHP code executes at that point then it gets this parameter here csc545 gets the value here passes it through the HTML special characters function which doesn't change at all and then it passes the echo function which means this entire thing is going to be replaced with this so this is the result that our server our browser will see that right the server doesn't know about any of the PHP code that's happening and now this job is going to add like a dot dot dot here this is not interesting but there's something else actually like this so let's think about this can I do this can I do this HTML special characters will make sure that all of my script tags are turned into HTML entities exactly but this would not work so we get I mean I don't want to do it and do all the other ones but you can you can write this code you can actually run these programs it's not it's not very difficult so that's not going to work so that's what I do can I just do this what do I do with this it's going to crash about this pretty well sometimes if you ask questions you don't know the answers to get good results exactly some name will be this string in here just like this right the important thing is now we're not talking about the HTML parsing we're talking about the JavaScript parsing because JavaScript is going to parse this and it's going to say okay we have a variable name and it's being sent to this string great so now how do I get it to actually execute my workshop then yes we're using something inside eval and close with new single code and plus so we've got cabinet something with eval but what are you doing I don't know what it is so this is like single code plus eval and then your JavaScript code and then ended with plus and single code like that let's get this in here and put this in here so what's going to happen so are we going to call alert 1 it's not this string though yes we'll still call it first though so we'll try to mechanic these strings together we'll call the eval function but before we do that we'll call alert 1 which I think return null or undefined and so we'll try eval the string undefined which I know will probably do nothing so we actually don't even need this eval here right but because why why don't we need the eval yeah it's going to run alert 1 as a function because it's JavaScript because we are injecting into JavaScript code exactly we are already executing JavaScript so we get rid of this get rid of this we also need to no not you again we also need to make sure that the URL includes these pluses otherwise they would end up as spaces so this would be something super important but we would see something like this and so now we'd be able to execute so let's say we don't want to do alert 1 we don't want to do the pluses we want to execute some arbitrary statements what would we do yeah use semicolon so oops I use a semicolon I can do alert 1 I can do alert 2 but then what do I do afterwards so just like single injection everything that I put would be appended to my query yeah so I can comment it out that would be a super easy way to do this so I would go into here and so oh let's see this isn't going to fail right because we have this well it'll have this single quote all the way over to here right so we didn't actually execute anything but you know I didn't include that here okay the name is there alert 1, alert 2 alert whatever we want as much JavaScript as we want here and then this will comment the rest of this code and so we're going to go so this is kind of what I consider as dynamic JavaScript so you're so this is not a DOM based cross-site script and why exactly the JavaScript code itself is not turning a string into code where is the problem then PHP PHP code exactly and this PHP code needs to know that this context that it's in is not in between two text two HTML tags it's not inside of an attribute tag it is actually inside of a JavaScript variable which means different escaping than all of those other ones combined all of these is this kind of set in much more verbose way of what I just said here so all of these different this kind of lists all the different contexts that context context context that you can have JavaScript and that sorry you can use user input in HTML and different characters that must be escaped depending on the context yeah super interesting so there we go all right so the other one there is a really good prevention in Gigi the key about preventing JavaScript is you should never try to do it on your own so you should go back to the so part of the problem is often times people want people to use some HTML not people to be able to write bold tags or write links or something like that but they don't want them to be able to execute JavaScript but that's a very difficult problem and it's very hard to get right so you're much better off working with black lists okay cool any questions on the processor thing stop all right what do you want to do on Monday review what do you want to review well how do you I'm not going to you can ask questions so this is what I was thinking we can either do I could either prep something about let's say XSS or Siebel Injection or maybe I could talk about current modern defenses against all these things I could talk about like click jacking or frame jacking I could talk about attacks like this or we could do maybe in class web hacking or something like I can send something up and we can try that I think that one sounds fun right less work for me and lots of fun for everyone okay so bring and that could be good prep for the midterm so bring bring your laptop I'll try to send an email but bring your laptop install docker on it if you can because I have the vulnerable web app I wrote for the the the that we can use and play with so that should be so we'll do that on Monday