 Good morning, everyone. All right, let's do this. I think we actually may be able to get through if not all of it. So let's shoot for that, and then we'll answer any questions that we have afterwards. Cool? All right, so here we get to kind of currently one of the big monsters of the web world in terms of vulnerabilities, so cross-site scripting. So this is honestly one of the most prevalent vulnerabilities in web applications today. It can stay much more prevalent than SQL injection vulnerabilities. And it's actually really helpful to kind of think about why that is, right? So when we talk about cross-site scripting vulnerabilities, I want you to be thinking, OK, but why are they still around? And they can affect basically any web application. So unlike a buffer overflow where you can say, well, move from C to Java, and now you're fine, right? You can completely eliminate that. Nothing was really analogous for web applications yet. And the whole point, so OK. So actually, the cross-site scripting name is kind of a misnomer. So we'll get into it kind of exactly why. But the fundamental problem, what cross-site scripting means, what it allows an attacker to do is it allows an attacker to bypass JavaScript's same origin policy. So let's refresh, since I talked about that was the most important part of the course. What is the JavaScript same-origin policy? What is what defines the same origin in the same-origin policy? Post-name is 4. Post-name, 4. No. That would be that every web page had a different same origin. Right? Close. Yeah? I think it would be a great job, but I want to see if it's like. Yes, but what is that origin? Like, I want to see if it's like. How do you define the origin? By the actual interest. Domain is 1, coordinate is 1. What's the third one? What was that? Protocol. Yeah, the protocol. So HTTP versus HTTPS versus FTP or even file. File is a different protocol for local files. Make sure that those are in different origins. So the whole idea is the same-origin policy is used to separate JavaScript executing in two different web pages. So that way, the same-origin policy ensures that the JavaScript you're executing at some attacker.com site cannot change an altar or facebook.com. This is the fundamental issue. The web is actually built in such a way that you should be able to go to malicious sites. You should be able to download and execute their JavaScript, but it should not affect any of the other pages in your browser. Because you could click on God knows what links. I mean, I'm sure we've all done this. We're just like, I'll send you something link. Oh, cool link on Facebook link. We could get to somewhere malicious, but the same-origin policy should prevent us. It should keep us safe. It's our nice, warm security blanket in the browser that says, ah, nobody can touch facebook.com because the script's executing from that malicious person. The same-origin policy means that it's going to be blocked. It's not going to affect facebook.com. But cross-site scripting vulnerabilities allow an attacker to bypass this. So what does that mean more mechanically? I mean, what does that allow an attacker to do? What is bypassing the same-origin policy? What does that get, the attacker? JavaScript on the end of the tabs or in the top? Yeah, execute. Fundamentally, if you're bypassing the same-origin policy, that means you're executing attacker-controlled JavaScript in the domain of an important page, or in the same-origin policy domain of that important page. So generally, if this allows you to bypass Facebook's same-origin policy, now the attacker is executing arbitrary JavaScript within that same domain. Now they can completely alter the content of that page, that facebook.com page. They can potentially try to steal your cookies and log in as you. They can even, with Ajax, what can you do? What can you make? So what do you do? Yeah, we can make requests to the server. And it's as if that JavaScript code running on facebook.com, the normal JavaScript code, is making us call them. And what can we call? We can call anything. So we can call methods. We can call functions or call pages that transfer, that add comments, that transfer money if it's on a banking site. We can fundamentally do whatever that user can do. So we kind of think about it at a high level, cross-site scripting, into kind of three different categories. The first one are, well, first, before we get on here, I want to actually show you what the cross-site scripting vulnerability looks like. So how can an attacker actually bypass the same-origin policy? So one way would be to somehow trick the browser. Like, what if I sent, let's say there was a bug on the browser, right, that if I'm accessing Facebook, where the O's are actually some other unicode character, right, if the browser thought that that was actually the same domain as facebook.com, then we could have a cross-site scripting vulnerability, even though this exists only in the, it's the result of a problem in the browser. Mainly what we talk about cross-site scripting is in terms of web applications. So bugs in the web application that allow an attacker to bypass the same-origin policy. So let's look at a simple example. Here we have PHP code, and the PHP code is setting the main variable to a get parameter. So what's the global get, what's that accessing? The query string, right? So it's gonna return whatever the value is in the URL of the query parameters. Whatever has the key name, it's gonna return the value there, right? And who controls that? The user and attacker, right? That comes from the user making the request. And so let's say we have this, this is our PHP page, right? We have this page, we say hello name, right? And so what's gonna happen at the server side? So A, first some, what does the equal sign there mean? And do what? Yes, and print. So it's gonna print out the value of name, whatever is your name. So this is, actually I think it's a setting of the enable in PHP to get to enable short tags to get this, otherwise you'd have a PHP tags and you'd have echo name, which returns the name right there. So how does this work? Well normally, let's say we're going to this page and we pass in name is equal to atom, right? So what's gonna happen, right? We have to think what's gonna happen with this code? Right, so what happens on the server? What does the server do when it gets that request? The value of that key name then sends that guy back. Yeah, so it gets that value name, right? Which was atom, it sets it into this name variable. It outputs the start of the HTML, a hello, and then what does it do here? It replaces this with whatever we sent, right? So if it's atom, it shouldn't say hello atom, right? But what does the browser see, right? So this is the web application, right? The web application generates an HTTP response, right? Which happens to contain HTML. But what does the browser then have to do whenever it sees that response? As to parse it, yes, this is absolutely the key. It all comes back to parsing just like SQL detection and vulnerability, right? The browser doesn't see this beautifully, well, beautifully, sorry, color coded tags here, right? It just sees a series of bytes that comes back from the server, right? These bytes happen to be the first byte as an angle bracket, the next byte is an H, the second, the third byte is a T, the fourth byte is an M, yeah. So you got the name atom from the client, from the person on the webpage, you're not grabbing it from the database, so I'm sorry. In this case, so we're getting it from the URL that's passed in. So from the HTTP request, basically, is the way to think about it, right? Because you wanna think about it in terms of the protocols to what happens. But yes, so the user in their browser will either type this in or I send you this link. You click on that link, it makes an HTTP request to this example.com server, pass in the URL slash, question mark, I don't know why I can't remember that. Question mark name is equal to atom and then the PHP code uses that get super global to access the atom from that URL in the HTTP request, right? So it's important to separate out what your browser does versus what it's doing under the hood is it's speaking HTTP, right? This is why you can use a command line browser to do this, like curl. Or you can even just raw connect to socket 80 and do the request yourself, right? And then the important part of that step is the browser gets shipped this and it parses it, right? And so it knows every time I see an angle bracket and then something, right, that's the start of a new HTML tag. And when I see an angle bracket slash something else, that's a closing tag of that HTML tag, right? Just like, so I think probably everybody in this room should have taken the equivalent of 340 or actually taken 340, right? That's why we learned, I mean, part of the reason why we learned about grammars and languages and compilers, right? Because parsing is everywhere, right? Your XML engine is parsing XML, the HTTP of the browser, the HTML parser of the browser is parsing HTML, right? And this is where the problem comes in. So we looked at this in our browser, and we see something like this. So let's say, hello, Adam, yay. But the question is, right, what happens if we put in HTML or what would be parsed as HTML into that parameter, right? And specifically we care about bypassing the same origin policy, right? So what if we put in some JavaScript code in here? A starting script tag and alert cross-site scripting and ending script tag. So, hey, first question is asked yourself, is can I do this? Yeah, you may need to encode some characters, right? Depending on the URI encoding, right? But you can URI encode everything in there, right? You can turn those into percent, whatever is percent encode every single thing in there, right? So you can say name is equal to this thing, right? This is one of the important things. You can pass in arbitrary information as a get parameter or a post parameter. And so then what's gonna happen here? So let's think about what happens on, so we type this in our browser, somebody sends us this link, right? It's gonna make an HTTP request to the server. The PHP code is gonna start processing. It's gonna look up in the URL, what was the value in the query parameters that had the key name, which is gonna be what, the string, start script, alert cross-site scripting and end script. And then what's it gonna do with that value? Execute it. Yeah, it's gonna just happen on the server side, right? All it's doing is sending those bytes, right? So it substitutes in that value for that angle bracket parentheses equal, not parentheses, percent sign equal, right? It's gonna substitute that in there and then it just ships it to the browser, right? We're then, what does the browser do? Executes it. Yes, it parses that response that came back from the server and it says, oh, the developer sent me a script tag. What do I do if I say a script tag? Execute it, right? It's JavaScript code, right? This is how the developer tells me to execute JavaScript code because it's inside of a script tag. And what's the domain of this script tag? The, sorry, the same origin policy domain of this script tag in this example. Three double. What is it, actually? What is it, even this example? Example.com. Example.com, 80, HTTP, right? But where did this script tag come from? From the URL, right? Which, if we got sent this link by somebody else, right? If hacker.com, whatever, sent us this link, that script tag did not come from example.com. But it's executing in the same origin as example.com, right? This is the key fundamental problem is now this code is being executed, right? The big problem is, once again, coding data makes it, right? So here I have my HTML data mixed with my JavaScript code. And when the browser gets those bytes, it has absolutely no idea to understand which of these code came from the developer that the developer intended and what was introduced by an attacker, what's extra code, right? It's just a parsing engine. It just says, okay, parse, parse, parse, parse, right? And execute. And so if we run this in a browser, I will say that you do have to get to disable some, you have to add some headers to disable some things. Modern browsers have features that will detect a very simple cross-site scripting like this where it sees scripts in the URL parameter and then sees those exact same scripts in the response page. So it will actually block this by default. But there are other ways to get around that, which is why it's still a problem. Questions on this? Yes? Oh, I'm sorry. It would seem it doesn't really cause permanent damage to that sort of one-time type of attack. Is it, are they actually still very dangerous or? Yes, okay, so question is, are they dangerous? So another related question is, what can you do with the cross-site scripting attack, right? Well, let's see where we're going. Okay, yeah. Right, so what can you do, right? So the question is, what can you do here with a direct one-time attack? So you want to give me one shot at your, you want to log in and chase and leave your account open for me? Yeah. That'd be good. It's just one time, just one time's promise. So yeah, so fundamentally what this JavaScript code can do, right, it can make any request to example.com that it wants with Ajax. It can completely change the webpage of example.com. If this was chase, I could make a login page, right? Let's say it's the normal place. I can change where that login form goes to with JavaScript. With JavaScript, I can completely control everything, right? So that action part of the form, right? Where that form goes when you type in your username password. I can change that. I can hook it with JavaScript to get those values and make it an external request to me. I can change that so it actually goes to my server and then maybe goes back. And you have no way of knowing that your credentials just got sent to me. Yeah, if you, so those are kind of more just using the JavaScript itself. Another thing I could do is I could insert an iframe or something to an exploit kit that has known browser-based exploits that would try to exploit your browser and then give me remote code execution on your machine and now I'm on your machine permanently. So I can turn your webcam on. I can do all kinds of fun stuff, right? Steal all of your accounts, not just that one time. So even that one time. Cross-ed scripting, not even once, right? But it's a good question because we'll think about stored versus, you know, there are different kind of levels. Part of what we like to do is academic stories. Categorize things and name things and think about how things relate to each other, right? How do we differentiate it from a legitimate popup that it's originates not from the same domain? Yes, the browser has no idea, right? So here I'm doing a popup, right? But this is just a proof of concept. The idea is if I can do this popup, then I can do anything, any of those other things I talked about, right? I can do anything in this origin, right? I can't mess with other origins. So I can do anything I want in this origin, okay? What if in the URL you did another and name equals, so what would actually be stored in the name parameter? It depends on the back end web server. So the question is what happens if you add, if you make a request with additional key value pairs that have the same key? That's actually, so if you're really interested in it, there's a paper called HTTP parameter pollution vulnerabilities which leverage this technique that some web servers will return, some server-side languages will return the first, some will return the second, some will actually change, some will turn them into a array sometimes which makes super weird stuff when people are not expecting that. Yeah, so there's HTTP parameter pollution is a vulnerability that takes advantage of that fact. Okay, so, right? And so for reflected cross-site scripting, right? So coming back to the question, how do we do this, right? Well, are we gonna assume that the user is gonna type in this URL with the script tags? No, probably not, right? The user is not going to type this in themselves. Although I say that, but there's actually a huge problem on Facebook of people saying, creating posts about, oh, there's this cool hidden feature in Facebook. You go into your browser and you enable the development console and then you copy and paste this thing into there and look, Facebook changes color. So people are actually self-cross-site scripting themselves because the development console executes JavaScript in the context of that web page. So Facebook actually disables the development console now. So when you go to it, you have to do certain things to explicitly enable it, which is kind of crazy. They'll actually tell you, like, if you try it, go to Facebook, I think it'll pop up a warning that says, like, you should definitely not do this. Does it do it? Yeah, yeah. So, okay, so A, we probably don't have to be worried about users typing this in themselves. But what do we need to be worried about then? Links, yeah. I can very easily get you guys to click on a link, right? I just send you a link that says, here, you're great. Every single person can click on that link, right? But even somebody who's not in a position of power, right, could get you to click on something. I could, what if I send you a bitly link, right? That automatically redirects you somewhere. You have no idea where that bitly, that short URL is gonna take you. It could take you a page that looks exactly like this. And what if I URL encode the value of that name parameter? Are you gonna know that that looks suspicious, that that looks kind of like a process scripting attack? No, not at all. We're used to doing this, right? We get emails all the time from companies that's like, hey, I don't know, coupons or something, right? And they're huge URLs that nobody bothers looking at what it is because, and then we got time for that, right? Check every link that you click on. Or, you know, that's directly sending you a link. What if I just post links on Facebook or post on a forum or post on Twitter, right? So people are gonna click on those links, right? So yes, we do have to trick somebody to click on those links. But the web, the security of the web should not be built on don't trust links, right? Because that's the fundamental part of the web. We should be able to click on arbitrary links and have nothing wrong happen with our computer. Fortunately, unfortunately, that's not the case, right? So there's important things here. So we actually kind of talked about all these. So we can access, so once we can execute JavaScript in a different origin, we can access all of the information that a user stored and associated with that site, right? So we can try to talk to the web server to extract information about that user. We can potentially access the cookie, right? If we steal the cookie, what is the cookie used for? Lot of sessions, yeah, establishing a session with the server, right? Because HTTP does not have any concept of sessions, right? So if I send you JavaScript code for Facebook, well, it's not new Facebook because they have security measures, I think. But, well, Facebook.com, right? I send you a link to a cross-executive thing. You click on it, the JavaScript code executes. It extracts your cookie, sends it to me. Now when I make a request to Facebook and I include your cookie, what does Facebook think? Yeah, it's that same session, right? It's just a new request from that same session. How many times do you take your computer onto a completely different network and you're still logged in to all the same websites? All the time. You've completely changed IP, right? You're accessing, right? HTTP only sees the IP that you're coming from. So you're coming from a completely different IP, but you're including all the session information. So it says, hey, good, I know it's you. Congratulations on your new IP, right? One of the really cool things is we can have a form appear on the site and we can steal pins and passwords. So it would be like something like this. So if I found the cross-excripting vulnerability on Facebook, right? It might be something like this. So I'll say, A, this is, it's Photoshopped. So this is not a real thing. I did not actually find the cross-excripting vulnerability on Facebook, right? But all I need to do is send you this link. So this script is doing what? Loading a remote JavaScript that I probably wrote. And so what origin, but the origin here is example.com, HTTPS, right, 443. So why does this work? Yes, for Facebook. The same HTTPS for Facebook with a domain zone match. The three tuples have the match completely. External JavaScript executes in the same origin, right? That's part of how we can include code from other places, right? That's how we can include the jQuery library from Google's content distribution network, right? And have it execute in our origin. So this specifically bypasses the same origin policy. So the question is, what happens when you type in your username password here? And it's gonna be stolen. It's gonna definitely go to me. And you may not even notice, right? I can do this in a couple of ways. I can change the action, right? So you send the username password to me, and then I redirect you transparently back to Facebook, and it would say, oh, maybe you just think like, oh, I didn't type in my username password. So I type in again and it logs in correctly. Or I could hook this. I could make an HX request to my server with your username password, and then let the original request go through to Facebook after I get a response. And now you're logged into Facebook, you have no idea that your browser is coming to second request to my site. So this is an incredibly powerful technique. And of course, I would also super encode this link. Like who's gonna check that this is not actually the login page for Facebook? And this could be any page for Facebook. It could be a comment page or something, right? If you suddenly see this page, you're gonna be like, oh, I need to log in. I'm logged out. It's really cool. It's actually super fun to do. I mean, not like two people, but a fun exercise to do. So the opposite of reflected cross-site scripting is a stored cross-site scripting. And really the key idea of who executes the JavaScript, we still want the user's browser to execute the JavaScript. The question, the differentiation here is how did that JavaScript get to the user's browser? What did, what happened to get that data there? Oh, and so does everybody agree that this is a problem of, that this is a problem in the server-side code of this application, right? Exactly on this line here, hello name, right? There's a cross-site scripting vulnerability because their name comes from the user, comes from potentially hostile, untainted, untrusted user input, right? It is being used just as is without any sanitization or any transformation here. So the idea of the stored cross-site scripting is, you can kind of think of it as like a two-stage attack. So we basically are going to try to trick these, let the server-side code to accept our input, store that input in the database, and then every time somebody visits the page, they're going to include that JavaScript in the response, our JavaScript. So the idea is first the JavaScript code by the attacker is stored in the database as part of some message, right? And then later the victim is then going to go to a page. So if you think about a blog page with comments, right? Comments are stored in the database. So if I write a comment with JavaScript code, that gets stored in the database. It doesn't get returned right away. It's not a reflective thing. But once that's in there, anybody who visits that page, right, is going to have that code be executed. And this is a key difference. So any website that, so if you store user content and you don't sanitize it when you use it, it's the same fundamental problem. We're using input that came from the user unsanitized in our HTML output. It can be vulnerable to the tech. So there's a lot of other, I mean pretty much every web application allows you to, and this could be any data. This could even be your username, right? Your username on some sites, or your city, or whatever. Any place where your input goes to the system, right? And stored and shown to other people is a potential vector for cross-site scripting, stored cross-site scripting. There's actually a lot of different ways to carry out these attacks. One of the best resources is the cross-site scripting cheat sheet, which I believe is at a... Let me see if this is the correct link. I wanna make sure. This is important for everyone to have, so. Okay, I guess it like this. There's just a redirect on it. Okay, so this is pretty good. So this is, I think, where this became and how this evolved is this is the series of tests. So there's different types of ways to execute JavaScript in the browser. So the basic idea is with script tags, right? It's very clear. If you're telling the browser this chunk is JavaScript code, right? But there is, oh man, there's so many more, though. We can include an image tag, and inside the source attribute of an image tag, we can include JavaScript. And we can say, so that JavaScript can do anything we wanna do. Also, it also depends on what the browsers accept, right? So fundamentally, even if the HTML spec says, hey, you can't do this, if the browser does it, then this is a potential vector. It may not work on everybody's browser, but it works on enough. So our snake was the first person to go through and collect all these different vectors, and that's what ended up in this OOSP list. So, let's see, I don't really need, so like here, it does all kinds of weird stuff, like malformed tags on mouseover, that's a good one. On error, this is actually a really good one that I use often. If you give an invalid source, and then this on error handlers automatically triggered when that image can't be loaded, and so this JavaScript will be executed in there. This is actually a good technique. Fixing slides on the fly. All right, don't tell anyone, it was here all along. Right, so this is actually a really good resource you can go through and pour through, and it kind of makes you realize, oh my gosh, there's so many different ways that browsers can execute JavaScript, right? It's actually pretty insane. So the simple would be script tags that normal one would be talked about, right? Script tags alert something. We can, so, why don't we just always try this? And if it doesn't work, we just say, game over. There might be partial sanitizing. Yeah, right, so, how, so, okay, let's go back to our original example. So how would you fix this? What would you need to do to fix this? And what is your goal in fixing this? How? Specifically how sanitize. Escape the input. What was it? Escape the input. Escape the how? With backslashes? Yes. 99% of the framework would change the smaller-than-scient with ampersand LT. Yes, okay, so, what's that? So the ampersand, right, is the ampersand LT semi-colon, that's HTML entity encoding, right? Which says, hey, I want a visual less than symbol, not the actual parsing important less than symbol, right? So if we throw this name, if we first, before we output it, we pass it through the HTML entities function, right? That'll completely solve this specific cross-site scripting vulnerability, right? Because here in the HTML page, how do we transition the parser to JavaScript? Yeah, we need to use the script tag or we need some kind of tag, right? Either like we saw, we can use image tags, but we need some kind of tag, right? And so if we're encoding all those as HTML entities, the browser is never gonna parse any of those as tags, right? So by doing that here, we can completely solve and fix this vulnerability. But what if you supply a greater than sign? So you are closing the tag that this browser is expecting and then you provide your... So, exactly right here in the HTML page, what tag is this expecting? So, like currently it is expecting a less than... Yes, exactly, it's expecting a less than. So that's why in this specific example, that's all you need. We'll talk about the other stuff in a bit. Yes. Okay, so that's the way to make this specific instance 100% secure, right? But oftentimes we actually want to, if we're writing a blog software, we may want users to add comments. I mean add links in their comments, right? But we actually want the users to use maybe some part of the HTML. So the partial sanitization problem is that people do it in a bad way. They maybe detect and look for a starting script tag and an ending script tag, right? They say let's just strip all of those out, right? So, and sometimes depending on where this happens, right, if it happens at the web, like a web application firewall or maybe Apache is trying to do this before it gets to the backend server side code, right? We can encode using URL encoding the tags and then what happens on the wire, right? We don't see in that HTTP request, we don't see angle brackets or angle script, right? We don't see any script tags, so we think it's fine. But it gets to the backend web server as an angle bracket, right? This URL encoding is translated. We can also use event handlers, which are very handy. The onload event handler does not work with every single type of element, so you need to do some experimentation to figure out exactly what it is. We're gonna inject this body tag, this means when that HTML loaded, this JavaScript executes. We can do other tricks like this. We can use an onmouseover event. What does this do? The web developers, when does this code execute? Yeah, when your mouse, when the user puts the mouse over this link, our JavaScript code is executed, right? So you, what if I change that text and send it over and click me to, you want an iPhone? Click here to redeem your prize. You're at least gonna hover over it to see where it goes, right? Maybe. We can add, this is one of my favorites, like I said. We add an image tag, we set the source to be something that does not exist. And that way, we know it always will not exist, so that onerror clause will be triggered and this will be executed. And we can do crazy things. We can do like an image tag with the source as JavaScript as we saw. We can try some browsers. So if they're looking for the keyword JavaScript, we'll use this percent hash X41 and actually translate that into an A at some point because browsers, right? I mean, if you put a website and your browser's like, whoa, whoa, this website did not properly close this tag. This is invalid HTML. No, right? It silently tries to do its best job to parse any crappy HTML page that's existed from the dawn of time of the web, right? They're parsing engines, even the newer engines like Internet Explorer will try to detect if it sees weird things, it will actually try to parse it as if it was like IE6. It has whole other cases in there, so rather the parsing engines are really complex. So sometimes they'll do this. Sometimes you can rely on weird behavior in certain browsers. We may or may not be able to use quotes depending. So here we're actually, we may not need quotes in our source and our onerror depending on here. And here, notice I haven't input any like single quotes or double quotes, right? But I'm still alerting, I can still alert this old alert Adam in here. Okay, so these are the two traditional types of ways that we think about cross-site scripting. We're gonna talk about a third way which actually has nothing to do with the server side code at all. But it's really important to talk about this because it really is the same fundamental problem. Fundamentally, you're executing JavaScript code that came from somebody else. Yes. Which I wanna get my understanding correct. Sure. So on one tab, I have Facebook open. On the second tab, I have a blog. All right, and blog has comments. Yes. So even I can add a comment. Yes. Now a malicious, sorry, an attacker has posted a URL. All right, so now. On where? The bottom of the blog. Okay. The previous one. Okay. Now I read the blog and I happened to click on that particularly. So can I take my cookie from Facebook? No, no, you can only steal your cookie from the blog itself, right? I mean, unless the link is to a cross-site scripting vulnerability in Facebook.com. No, you're saying that the link has to be present in the same domain. No, no, no, no, I'm saying that depends on where that link goes. Where does that link take you? To this side. Yeah, that's fine. I need you. The JavaScript code needs to be executed in the same domain as Facebook.com, right? So it's got to come from Facebook.com. So you have to end up on a Facebook.com page. So they either have to send you a link to Facebook.com, right, where there is either stored cross-site scripting or there's a reflected cross-site scripting in that link that they send you. Then their chosen code will execute in Facebook.com. But by default, just by visiting some other site, they can't get Facebook's cookies. Any other questions before we go on a Dom-based cross-site scripting? Okay, so Dom-based cross-site scripting this actually has a couple different names. It's also called third order, which is very confusing because it has nothing to do with, it's not related at all to second order SQL injection vulnerabilities. It's third order in the sense that the first would be reflected and the second would be stored cross-site scripting. And so the third would be, apparently they didn't realize that to give it a name. I actually haven't, so yeah, reflected would be first order stored second order. I actually really prefer the term client-side cross-site scripting because I think it's more indicative of what is actually happening here. But so you can see literally any of these terms. And the core idea is this is because there's a bug in the JavaScript code itself, right? Whereas before in reflected and stored cross-site scripting, the bug is in the server-side code, right? It's in the PHP code or the Ruby code, right? User input is being used to generate HTML response that's not properly encoded. But here as we'll see, the bug actually exists in the client-side code, which is kind of crazy. So this is what I like to think about it. I'm actually kind of trying to bucket reflected and stored into server-side cross-site scripting. And then I like to think of like DOM-based as client-side cross-site scripting. Because it also can be very confusing if you can, I think you could have DOM-based cross-site scripting. They're also kind of reflected in a way, but also not so anyways. It's very confusing. I understand. Okay, let's look at an example. So here we have a completely static HTML page. Just HTML and we have some script. So where does this script come from? The server, from the developer, right? The developer of this application wrote this HTML page and wrote this JavaScript code. And it does something super simple. It gets the name from the location.hash. What's the location.hash? What part of the URL? Backman, yeah, the hash. Remember, so URLs, URIs, right? They are, ooh, just make a test, right? Protocol authority, path query, and then after the hash mark, fragment, right? And so what was the, I remember the fragment was used for, what is supposed to be used for traditionally in URIs? Yeah, the specific sub-resource in that page, right? But actually an incredibly important detail, right? The server doesn't care about the hash, the fragment, because that only, the server only cares about accessing documents, right? And so your browser actually does not send the hash or anything after it to the server itself. When it makes an HTTP request, it only sends everything before the fragment, which is kind of crazy. And it makes sense though, from the server's perspective, the hash doesn't mean anything. It's the same page. No matter what you put there, it's gonna give you the same results so it doesn't need to know that. Okay, so what this JavaScript code is doing is it's getting the name that's in the fragment. So it's specifically using the fragment to get as the name. So it would be like hash Adam, it would just get Adam. Storing that in a local variable name and then it's using the DOM access to write out to the document hello name, right? So just like we saw in the PHP, let's think about, okay, what's gonna happen when I access this test page with hash Adam, right? So first thing, what response I'm gonna get back from the server? The page, this page, this exact page, right? Every time I request test.html, it's gonna give me this exact HTML page, right? Now my browser gets that, it does what? Parses, it parses that HTML, right? And then it starts executing this script when it sees this script tag, right? So when it looks up location.name, it gets Adam, then it passes this to this variable name, right? And then it writes out. So document.write writes out hello, Adam, right? So this is DOM's way to change the HTML of the page. And so if you run this, it'll go hello, Adam. And the crazy thing is the server never saw Adam, right, that never got to the server. So question is what happens when I do document.write? What happens if I include HTML in document.write? Or would? Exactly. So the key question is does the browser parse that again as HTML? It turns out it does. So if we do example.com test.html with a hash sign and then script alert cross-site scripting, the exact same thing happens, right? The server does not see any of this. It only sees up to test.html. It sends us this page and then location.hash is used from here, it gets passed the name, it's written out to the document, where then the browser reparces it as HTML and it sees, okay, wow, this is a JavaScript code so I should execute this. And so it pops up in alert. And so the core idea here, right? So any place in JavaScript code that can turn a string into JavaScript can potentially be vulnerable here. So this includes document.write. It includes eval, it includes the function keyword, right? It includes all sorts of other stuff that I can't remember off the top of my head. But if you look up DOMXSS, there is a huge list of all types of DOM cross-site scripting vulnerabilities. All right, so let's see where we're at on time. Okay, we'll stop the cross-site scripting talk here because we're actually almost to the end. We're gonna talk about how to, when we get back on Monday, we'll talk about how to worm cross-site scripting and then we'll circle back and cover some other cooler, not cooler, but other types of vulnerabilities. So, and we have questions on Final CTF stuff. Any other questions? Is it that if no one packs my server, I get more points? Or if someone actually got my server, I get less points? Not quite. It's more in the sense that if you, well, if you fix everything or nobody hacks you, then other people get less points, right? So if you break something, right, you can attack all N minus one other teams. But if somebody else has fixed that service, then you're only gonna get N minus two possible points. But I will say, the design of the system is designed more towards attack. You'll get much more bang for your buck by spending your time attacking other people, finding vulnerabilities, creating exploits. Cool, yeah. No, no, no, no, no. I'll provide this. The services will be provided the day of, so you'll know them the day of. Yes? Yes? Yes? Would it be, would it be here in this box? Yes. Ooh, I got a look. I think it is in this room at the final time. I believe it's in this room. I think I did look. And then, oh, but, okay, yeah. So we'll get. Sigh, did you create the registration form yet? Okay, good. Can you add, sorry, can you add on there that we want like a marker or something, like a checkbox if the team needs a computer? So if you need, if people on your team don't have access to a computer that they can bring, let us know so we can host your team in one of the server, the computer labs. So that way your team can compete from there. Cool, question. Yes, you'll be able to, you'll have groups on your machine so you'll be able to do what you want on there, but you have to do it basically like they, you can't like, you know, you wanna spend your time wisely, but yes, we'll do a lot of that. Cool, all right, there we go.