 All right, let's see if this works. So yes, for those who don't know me, I'm Professor Adam DuPay. I is my second year here in SidSea, so I'm very excited. I teach web security, as we heard. Yeah, definitely. I also teach at the undergraduate level, I've been teaching 340, so principles of programming languages. Is anybody currently in that class and took the final earlier today? Awesome, good. Why not? But midterm, whatever. Second midterm, you know what I mean. Good, so you guys aren't looking at me really evilly, so I think this is a good sign, so that I have a good. See, I warned you, some of them would be here. So like Partha said, web security is incredibly complex and we'll kind of get into why. But that's why for this class, I wanted to focus just on cross-site scripting vulnerabilities. And so if you think, like, well, this is a really simple topic, I actually had to cut a lot of stuff to fit this into one lecture. So in my grad class, where we talk about web security, we go over, first we go over client-side scripting, so we go over JavaScript and other things for two class periods, so for like three hours a whole week. And then we talk about cross-site scripting vulnerabilities for another day and a half later on in the course. So there's actually, and that's with all of the buildup on all the different technologies that are involved in the web. So this course, I'm going to give you a crash course into cross-site scripting vulnerabilities, so you'll know the most important cross-site, the most important thing to web security, which we'll get to, and which will definitely be on a test, because I'll make sure Partha does that, or Professor Dasgupta. And yeah, see, I have a lot of power, so watch out. Pop quizzes, all that kind of stuff, OK. So how many people in this room have had their information, their personal information, stolen? So the rest of you don't have any personal information, basically? Yeah. That's why? Yeah, not really. It's hard to get your credit card stolen if you don't have one. All jokes aside, honestly, and I'm raising my hand to include me in that. So literally just a month ago, I had my credit card stolen. There were charges on there from an ink supply store of $280 that I'd never heard of before, so I called my bank and was like, this is not me. And then there were other incoming charges from match.com and a bunch of other weird stuff. Like, looks really weird if it's coming on your credit card. So luckily, they took away all that stuff. But these kinds of things have been happening over and over. So way back in 2006, UCLA had 800,000 of their personal records accessed by a hacker. And once again, I was one of those 800,000. Not because I went to UCLA, but because I had applied to UCLA way back when, and they still have your data. And so the hackers were able to get access to that data. The University of Texas had 200,000 personnel records stolen. People get, this is from my alma mater, so I went to UC Santa Barbara for both undergrad masters and PhD. And so this is an awesome story where they caught a student who was changing his grade. So he had like, quote, quote, this wasn't really a hack, but he had figured out the password of the professor somehow. I think it's because he worked at A, if I remember correctly, he worked at an insurance company who had that professor information. So he was able to look up their social security number, date of birth, all that stuff, all the security questions that the homework system asked. So he could reset the password, go in, changes grade. Of course, he did that from his work computer, so it was very easy to track him. And he got in trouble. Anybody here own Bitcoin? Did you get it before it just doubled in price in the last three months? Oh, actually, I spent it the day before the FBI. No. So I went from $200 to $1,300. So you don't own any more Bitcoins, what you're saying? I mean, I still have some. You still have some hidden away under a mattress somewhere? Yeah, exactly. So yeah, so Bitcoin's awesome. Bitcoin's very interesting from a scientific perspective, from an economic perspective, from a technology perspective. What makes it really interesting from a security perspective is it's like cash. If somebody steals your Bitcoins, those Bitcoins are gone, and there's no way, no recourse for you to get it back. Exactly. What's it much more than this? Well, this, exactly. So this was an exchange, I believe, was BitSamp that got, yeah, or BitFloor, was an exchange where they said, hey, give us your transfer, your US dollars to Bitcoin, and you could buy Bitcoin on there. So they had a lot of Bitcoin in the system. They got hacked. At the time, it was worth $250,000. I didn't look it up, but yeah. I think right now it's in the tens of millions in current value of Bitcoins that were stolen from this. And all it takes is one. So this is obviously an exchange which has a, how do you access this online exchange? Do their website, right? Exactly, yeah. And so all it takes is one vulnerability in that website to allow a hacker onto that machine to then allow them to go further to try and get at the Bitcoin private keys. And then once they have those, bam, they have $10 million untraceable, quote, quote, untraceable, but there's no way, there's no legal system in Bitcoin to get that money back to their rightful owners. That money's gone. Just like if somebody broke in and stole that cash under your mattress, there's nothing they can do. It's gone. Barnes and Noble was hacked. They had their credit card readers hacked. They, I think, Barnes and Noble was part of a big ring that was headed by a hacker named Albert Gonzalez. And him and his hacking crew caused $200 million worth of damage by stealing, I think, his $20, $30, $40 million credit cards over the span of four or five years. So he actually, if you go look up, there's a great article in The Rolling Stone about Albert Gonzalez because he and his hacker crew went on crazy, like, Rockstar drug binges. And that's what they used all their ill-gotten gains on. But it clearly did not end well, because it got 20 years in federal prison for this. All this being said, so this kind of shows you a couple of things, right? So security is really important, which I hope is why you're in this class, to learn more about security, right? So we still have breaches today, and they're happening constantly. I didn't even update this with the Office of Personnel Management breach. Anybody know what the Office of Personnel Management was? Yeah. Yeah, it's the government employee management department. Exactly. One of the employees, does anybody know what kinds of information was in there? Social security and security numbers. So security number, addresses, those are in normal dumps. What are in fingerprints? What was it? Fingerprints, definitely. All of your family's addresses. Yeah, so that gets into, why are the family addresses in there? Background checks. Background checks. So yeah, in this database, this Office of Personnel Management, they had anybody who filed for security clearance for the United States. So secret, confidential, top secret, I actually don't know all of them. But if you went through that process, all of that information that you gave the government is stored in this database. And they include questions like, tell us every bad thing you've ever done in your entire life, and we're gonna put it in this database. Tell us, give us the name of five of your associates or friends so that we can put it on there. What are the names of your children? What are their ages? Who are your family members? Where do they live? All of that information was in this OPM database. So when I first heard about this, I was like, wow, that sucks. It's like, you know, crappy for all those people because they have their information stolen. But last week I was talking with an FBI agent who works counterintelligence, and she said, or counter espionage, and she said, well, you know, it's really bad if you think about, you know, one of our biggest rivals, China. So we're pretty sure that they're the ones who stole this data. So now they have a database of every person who has any type of clearance level, everything bad they've ever done, who their kids are, who their spouses are, any mistresses that they had, all of that information the Chinese now have. And so she's like, hey, we're not worried about five years from now or two years from now. We're worried about 20, 30 years from now when kids grow up and all of a sudden they use this data against them in like an espionage type way. So anyways, these things are really important, right? And so using, you know, not all of these have web components, but if a business doesn't have a website, do they even exist? No, how many of you go to like a, I don't know, you want a new place to eat? Do you, I don't know, how do you find a new place to eat? Google, nobody use Yelp? Yelp, but then what do you do when you get to their Yelp page? Yeah, you go to their webpage, right? You go to the Yelp page to see the reviews and then you're like, hmm, but I don't trust any of these crazy people. So I'm gonna look at the actual menu myself, right? So if you don't have a menu link to go look at that menu, the business better, it doesn't even exist. Like it better come highly recommended. So every company needs a website as kind of their front-facing business. And are websites ever closed? No, you don't ever go to a website and say that it's closed, right? Unless it's down for maintenance. Unless it's down for maintenance, then you're like, that's a crappy website, right? So they're open all the time. Do you have geographic restrictions on where you can access a website from? Sometimes. Sometimes, but most of the time, no, right? You can access it from anywhere in the world and it can be accessed by anybody with an internet connection. So this works for you, it's great for you using a website but a hacker can also do that. They can access any website at any time from anywhere and so your website's open 24 hours a day to have hackers banging on it, trying to find vulnerabilities and exploiting them. Okay, before I get any further, I have to discuss this about ethics. So I do not want anybody in this room to be the next Albert Gonzalez. So it may seem like cool to be the kingpin or the kingpin of this, or queenpin I guess of this criminal enterprise but you will get caught, you'll get sent to jail and it's not gonna be fun. So only hack sites that you own or that you have set up yourself. At the end of this talk, I'm gonna give some resources where if you wanna go learn these things or dive deeper, there's plenty of information, plenty of resources on your own. Please, please, please, please do not do this. Partha doesn't wanna have to go visit you behind the plastic glass and be like, what went wrong? What could I have done differently? And you'll be like, if Adam had only talked about ethics, we would have been better. And he's like, he did. And you're like, no. Okay. So you have to have either sites you own or that you have explicit permission from the website owner. Actually, and what's really nice nowadays is popular sites, many popular sites actually have bug-mounty programs where they explicitly grant you permission to try and find vulnerabilities in their site. So things like Facebook, GitHub and Google all have these but if you're gonna do this, you have to be incredibly careful that you're doing this correctly and you're abiding by their terms of service. Facebook had a security researcher, I believe the researcher was in Turkey who found a way to post on anybody's wall even if they weren't friends. And so he reports the vulnerability to the Facebook team and the Facebook team said, well, it's not really a vulnerability but there's like a language barrier there. So he tried again, hey, no, no, really, I can do this. This is definitely a security vulnerability. And they say, well, you know, it's not really. So then to prove his point, he then posts on Mark Zuckerberg's wall without being friends with him which then caused a huge uproar. And so, you know, these bug-bounty programs actually pay you if you report a vulnerability to them. But in that case, they're like, look, you are terms of service for this bug-bounty program clearly says do not do this on any real, on the real Facebook site. They give you an awesome fake site that has all test data that you can play with. But he violated that so he didn't get his money but he did get the attention and the bug did get fixed. So the important thing is here is you will get caught. You'll get caught, don't get caught. Okay, so what are some of the technologies in the web? So who here develops web applications, websites or has for class? More people, a handful of you? What are you all developing? Mobile apps? Is that the new hotness? Games? Console applications? Mainframes? Whatever we tell you to do for class, is that what's going on? Okay, well, cool. Okay, so those that do, what kind of technology is involved in a website? Just fetching, from your browser right there, fetching a random website. Just one. HTML? JavaScript? CSS? jQuery? PHP? Python? Node.js? All right, now we're just listening to server-side programming like it is, but. It is part of it. Wordpress. Wordpress? A lot. Anything else? What's that thing that's in front of the URL? Yeah, HTTP, hypertext transport protocol? That's another one, TCP, IP. Yeah, so to be really a competent web programmer, you have to be familiar in at least, I don't know, seven or eight out of all of those technologies and to really be an expert and to find vulnerabilities, you really need to understand all of those. So that's where the complexity of the web comes from. So we have HTTP, the hypertext transport protocol. So when your browser wants to make a fetch a website, it looks at that URL, it parses out, okay, what's the domain of that website? It uses DNS to translate that domain to an IP address. It makes a TCP connection to that IP address. Then it requests a resource from the server based on the URL using HTTP. Then it returns HTML to your browser where your browser takes it, interprets it, displays it to you. And it may use cascading style sheets to style the browser. JavaScript's gonna execute to do all that fancy JavaScript stuff to make the page interactive. On the back end, I don't think anybody mentioned this, but there's gonna be some SQL, right? So the web application is gonna store data, usually in some kind of SQL database. And then some server side code, right? So either typically the typical ones, PHP is kind of the most popular, Python, Ruby, the beautiful thing about the web is as long as your server side code can spit out, speak HTTP and spit out an HTML page, nobody cares what it's written in. So you're probably interacting with websites that are written in, I don't know, Lisp or Haskell or C or Perl, all that kind of stuff. So, seems like a lot, right? Right, seems like a lot of technologies. And to me, this is one of the core reasons as to why there's vulnerabilities in web applications. Because there's so many different technologies here and the vulnerabilities really come at the intersection of all these layers. So, and when I say there's a lot of vulnerabilities, I mean there's a lot of different kinds of web application vulnerabilities. All kinds of things, from things you've probably heard of, cross-site scripting, SQL injection, more kind of things that maybe you haven't heard of that are just as severe. I don't think it's on here, but there's even remote code execution. So Ruby a few years ago had a vulnerability where anybody could get remote code execution on any Ruby on Rails web server. So that was a huge vulnerability. Up to all the way logic flaws, so let's say your web application accepts a coupon, right, the coupon code for a discount, right? Tons of applications do that. Well what if you can apply that coupon code multiple times to drive the price of your order to zero? That would be a bug and a logic flaw. So that's a security problem, right? Because they're able to purchase something for free. We don't want that, we're trying to make money. Excuse me, I have to redirect as a type of logic flaw that I named, I won't say I discovered it, but I didn't name it. So that's why really to get into all of these, you have to take a semester long awesome cool class to get in and really understand the impact of all of these vulnerabilities. But for today, we'll just go over cross-site scripting. Are you offering this class next semester? Kind of. It's a graduate class. I'm teaching 545 next semester, where I'll be incorporating a lot of these things into that class. So yeah, if you, well, you can talk to me afterwards. Okay, and the technology I'm gonna focus on, so cross-site scripting really comes at the interaction between the HTML and the JavaScript code. And so we'll look at how that is. So HTML, so HTML is the hypertext markup language. So this is a way for a web application to describe a web page to a browser. So does anybody know what hypertext means in there? Yes, so HTML itself is text, right? Just like a C program is just text, right? Or a Java program is just text. So what does that hypertext, what does hypertext mean? Is it just a really cool version of text? It's like, it's hypertext, it's awesome. Special kind of text which does something. What was that? Special kind of text which does something. Ah, special kind of text that does something. Yeah, so it's special, so. Is it text with metadata inside it in a way? Yes, so the core idea is that hypertext is text that points you to a reference to find out more information or more data. And so in that way, and so this is how, why we call it a web, right? So you get a web page, all of the links on the page are all links to other resources that you can go get. And then when you go fetch that page, that page has more resources with links that you can go fetch, and then you can go click on those and it'll fetch a new page with new resources, new links. So originally HTML had images, tables, you could specify font sizes, some other stuff that I'm not gonna get into. And the content was incredibly static. So you have to, well, I say think back, some of you maybe have to imagine what it was like in the mid-90s when the web was first getting started. So this is the Yahoo home page from 1996. You can see it in all its beautiful glory. An image at the top, an input field, and just links. Right, this is all it was. They centered it. They centered it, ah, not really. It's all the way to the left, right? The top is centered. Yeah, yeah. So Amazon.com, does anybody remember what Amazon.com originally sold? Books. Books, yeah, exactly. So this is, let me get my cheat sheet. Oh, I don't have it. Oh, 1995, when Amazon first launched. Right, compare this to the craziness that happens when you visit Amazon.com and it's like, you're back, awesome. Here's all these cool stuff. Look at all these categories. We got all these things. Look at what, you looked at this thing last week. You probably wanna buy it now, right? All that kind of stuff. Here's links to our store, buy our things. And you remember what was the hot web search engine before Google? EOL. Alta Vista, boom. Alta Vista from 1996. I don't date myself too much, but I definitely did use this. Oh, God. All right, and then one of the original Google images I could find from 1998, right? So even the famous Google with their cool web design and Google Maps, which is all interactive, right? So even Google, just an image, a box, and a bunch of logos, right? So it's kind of crappy, right? I mean, do you really think the web would have taken off if that's all we could do is just display a page and do links on a page? Probably not, right? So the HTML was designed originally to just describe the text documents with hyperlinks to other documents. So that's all it is, right? It's not anything special. Just here's a document, and some parts of the text will be links to other documents that you can then go open, which can be links to other documents that you can go open. But we wanna do fancy animations, and we want pretty web pages, right? We gotta have it, otherwise the web sucks. And it's just kind of the natural trend. But all we have is that text. We have the text of the HTML page. So there's a couple different technologies that have been tried to do interactive, basically, HTML or client-side experiences. So anyway, we wanna, what are some of the names of some? Silverlight, that's a good one. Chocolate? Chocolate, I think it's also Flash. Or maybe it was the early version or something, was it? JavaScript? You have to stop answering. These are the people I'm trying to answer from. Ajax, what about Java applets? Java applets, exactly. Yeah, Java applets, right? So Java applets are terrifying because your computer downloads Java byte code from a random website and just runs it. This is what they're like, oh, great, you want interactivity in your HTML? Well, HTML sucks, here's a program. Run this program and... That's what you do with your mobile phone. Shh, shh. Shh. That's true. It's ahead of its time, an idea ahead of its time. Okay, another thing, anybody know what active X controls are? No, no, no, I've seen it. Surprisingly, even a worse idea than Java applets. Instead of downloading a Java byte code, which kind of makes sense, because you can at least control that byte code, you can make sure it executes in a sandbox. But active X controls are binary, so they're like X86 code, assembly code, OS specific programs that are downloaded and executed on your page and in your program. So these cause all kinds of security nightmares because your computer's just downloading and executing code as soon as it gets to it. Okay, we talked about Flash, it started out as a vector graphics and animation engine. It has a scripting component, so you can make games, all kinds of cool stuff. Silverlight, which somebody over here mentioned, which is basically Microsoft's competitor to Java applets, and it was a replacement upgrade to active X. And finally, we arrived at JavaScript, which nowadays, I'd say almost every single browser supports JavaScript as a scripting environment in the browser. So really, if you were to ask me what's the key technologies to learn on the web, I'd say you'd have to learn HTML, you'd have to learn JavaScript, and a server-side scripting languages and probably SQL. So if I could boil it down to four, those would be the four. If I could add a fifth, it'd be HTTP. And so really, JavaScript is the language of the web. All browsers speak it and execute JavaScript, so it really is, whereas all these kinds of things before it, Silverlight for a long time was specific to Microsoft platforms, active X controls were specific to Microsoft, Java applets could depend on what version of Java you have installed on your computer. Okay, so JavaScript is super interesting, and I wanna talk just a little bit about the background here. Maybe I should skip some of this. So anyways, so JavaScript was originally created by a guy at Netscape in 1995. It was originally called LiveScript. So does anybody know why they changed the name to JavaScript? Yeah? Popularity at Java. Yeah, exactly. So at the time, Java, it's maybe hard to imagine now, but Java was the new hotness, and everybody was talking about Java, and so the marketing people at Netscape were like, hmm, if we call our language JavaScript, even though JavaScript looks nothing like Java except superficially, then maybe we'll be able to piggyback on that stuff. So they announced that it's a prototype-based scripting languages with dynamic typing and first-fast functions. Does any of this sound like Java? No, exactly. Yes, opposite of Java. Okay, so yeah, there's all kinds of things. There was, maybe they were gonna collaborate, whatever. In 96, when Microsoft finally added support for JavaScript to Internet Explorer, that's when kind of JavaScript was made. When now, anyways, this is a lot of stuff because I really like this history going back and learning all this is like when, who became what and how the technology became popular. But it was eventually supported by all browsers and it evolved organically, right? Because as soon as JavaScript's out there, it's not like you can say to every single website on Earth, hey, let's switch over to JavaScript 2.0 and have all the browsers which are implemented by different companies also move. So that creates a huge headache. Okay, the DOM is just a thing that allows JavaScript to manipulate the HTML. So JavaScript itself is a language, right? So that's the important thing. So JavaScript has nothing to do with your browser. The document object model allows JavaScript to interact with your browser. So these two things are distinct. Okay, so the important thing about JavaScript. So JavaScript, the web application tells your browser, hey, I want you to execute some JavaScript code when it sends an HTML page and it includes the JavaScript code between the script elements. So what is a script element? So an HTML and element looks like this, braces, the element name, closing in braces. So this tells the browser, hey, ever from this script to this end script, interpret this as a JavaScript program that I want you to execute. And so early in the days, you had to be very careful and put comments here. So you can do really cool things. You can make the web dynamic. You can say, hey, give me a name, enter a name. If the name is null, right, welcome to my site. Otherwise, right, welcome to my site name, right? Now I'm getting away from that crazy, just Alta Vista or Amazon page that just links on a page, right? Now I can actually do some really cool dynamic stuff. And there's other ways to include JavaScript. So this is what it looks like, right? I go to this page, my browser loads this HTML. So now that I know I have some of you, it's gonna be awesome. Okay, so the browser gets these bytes, right? From the starting script tag to the sending script tag. So some of you who are in my 340 or have taken 340, what does the browser have to do with these bytes to recognize this as JavaScript? Parse, yeah, it's gotta parse that page, right? There's a language, there's a grammar that describes HTML. And it parses that page according to that grammar. And when it gets to these script tags, it says, oh, at the starting script tag, everything after there to the end of the script tag is a JavaScript program, right? So it has to take these raw bytes and interpret that as a program. And so it says, hey, please enter your name. I enter my name, my name's Adam. And it'll say, welcome to my site, Adam. Awesome, awesome interactive website. With the DOM, you can do things like create elements. I'm gonna kind of skip over this a little bit here. You can create elements. Here I'm creating an element and adding a line, which is the most awesome example you can use. So I've added that fancy line using JavaScript. Yeah, yeah, yeah. Okay, all of this is background just to get to web applications. So a web application, I do have an hour 15, right? Perfect, right. So a web application, so you first have you with your MacBooks and you're right in front. Are you using Firefox? No. And Safari? Chrome. Okay, I use Chrome too. It didn't really matter. It just wouldn't be better for the pictures. Okay, so you are in your browser. You wanna access some web application that's running some PHP code and it has a backend database, some MySQL, this is kind of a standard setup. So the browser is going to make an HTML, HTTP request to the web server. The PHP code gets that request as ooh, what do they want? Does some processing, makes one or more queries to the SQL database, gets that data back and then generates ultimately an HTML page with CSS and JavaScript and then sends that back to the browser where the browser does what with this? Render, render something. Before it renders it. Parse is it. Parse is it, yes. It just gets raw bytes from the server and it has to turn that into a web page. So it parses those bytes into a web page and renders it, exactly. It's important, this is why I keep iterating it. And so this is what it looks like at the wire level. So the web client is going to send an HTTP request to the server that says hey, get me the root slash bad document, my user agent is curl and I want to get facebook.com and there's other headers that send say different things and the server responds with hey, okay. So 200 is a response code, okay. So the first one says hey, I'm speaking HTTP 1.1. This is a good response request. A bunch of headers here and then after the headers is the HTML of this page. So this is what the browser has to parse and has to turn into a web page. And so we can see the script tag in here, right? That we, I think it's from Facebook, that Facebook wrote, right? The script tag in here, right? So how does the browser know that this is a script tag? It parses it, yeah, so we should default too until we get to the same word. It parses it, yeah, it parses the page, sees the script tags, executes whatever is in the dot, dot, dot. Okay, so hopefully you've been in this class enough to know, hmm, my browser is, maybe if you don't know any better, you should be a little bit terrified at this moment, right? Every website you're going to is downloading JavaScript code to your machine and running it. That's just the same reason I was complaining about Java applets and ActiveX controls, right? Downloading some foreign code. So there better be some kind of security mechanisms in place to make sure that this code isn't just doing whatever it wants. And not only are they downloading and executing code, but how many tabs do you have open right now? Two. Two. That's the number you got. 15? Yeah, I'm about 10, a light day is five. If I just reset my browser in the next 30 seconds, it'll be two, and then very soon it will be four, and then I'll go up, anyways, yeah. So lots of tabs, right? Each of those tabs is executing some JavaScript code that came from some website, right? So it's all happening concurrently. So there's two mechanisms that ensure the security of this code that you're executing. One is that your browser uses a sandbox mechanism. Similar to, sorry, we didn't see it in Java applets, but similar to Java applets where the JavaScript can't access local files. It has no access to almost any network resources. And it can make no incredibly small windows, so this gets around all those really annoying pop-ups or pop-unders that some of you may remember. And it has no access to the browser's history. So even though it is code, so it's code, it's basically a program, right? But it can't access anything on your computer, so that's at least a little bit better, definitely better than ActiveX controls. Any questions so far? All right, the specific details of the sandbox really depend on the browser. Okay, so what this means is I have, in my browser right now, I have two tabs open, right? This one tab has Facebook. This other tab has CNN. They're both executing JavaScript code in my browser. So we just said, okay, well that code is sandboxed in that they can't access any local files, but can Facebook mess with things on CNN and CNN mess with things on Facebook? No kind of. Hard security guarantee. The same origin policy? Well, let me get that in a second. Yeah, so there's nothing, we need another security mechanism, so just sandboxing the code isn't enough. Because there are times we want, so if you had two tabs open of Gmail or whatever, Facebook, maybe you want those to communicate. And so this is the most important thing for this class, is the same origin policy. So same origin policy is a standard security policy for JavaScript about browsers. So this controls and restricts what resources JavaScript code can access. And it's incredibly important to web security. If you only learn one thing, I don't really care about the cross-site scripting stuff, same origin policy. Because as we'll see, cross-site scripting is just about subverting the same origin policy. So if you don't understand that, then it doesn't matter who cares about cross-site scripting. So it's defined as every frame or tab in a browser's window is associated with a domain. So I think about it as tabs. If you get into this, you'll look at frames. And so domain is determined by this tuple, three tuple, a protocol. So the protocol is the thing at the start of the URL. So HTTP or HTTPS, or file if it's a local file on your computer. The protocol, the domain that you got this file from, and the port that you got that file from. Everybody know what a domain is? Everybody know what a port is? So the same origin policy means that code downloaded in a frame or tab can only access the resources associated with the domain that it was downloaded from, right? So if you go to Facebook.com, well, actually we'll see an example. So this is a little subtlety here, which maybe I shouldn't get into, but okay. So on my website, if you go there, okay, I don't wanna get into that. Okay, so going back to our example, same origin policy. So when I go to HTTPSFacebook.com, what's the three tuple here? What's the protocol? What's the domain? Wait, yeah, HTTPS. Some of you stopped talking before the S, right? The protocol of HTTPS. And you know that by knowing how to parse URLs which we didn't go over, but that part of the URL. What's the domain? Facebook. No, www.facebook.com. What's the port? 443. 443, yeah, very good. So that's a default port of HTTPS, if it's not specified. What about HTTPEWW.cnn.com? What's the protocol? HTTPE. HTTPE, the domain? WWW.cnn.com. WWW.cnn.com and the port? 880. 880, awesome, perfect. So this means that JavaScript that comes from Facebook.com cannot access the cookies, the resources, the image, the page contents of anything in any other domain. So this is why Facebook.com can't mess with CNN.com and why CNN.com's JavaScript can't mess with anything on the Facebook.com page. Otherwise it'd be a mess, right? That would be any random webpage you went to could change all of your tabs and it would wreak havoc. Okay, now we're gonna get to cross-site scripting, yeah. What about like when, so if you have like HTTPEW for one site and HTTPS for the other site in two tabs? Yep, can't talk. They can't come. Correct. They can maybe communicate through the site though, right? So they can both make a connection to the backend server who could pass messages if they needed to. Yeah, but they can't access like each other cookies or local storage, anything like that. Okay, so cross-site scripting, the whole thing about cross-site scripting is they're used to bypass JavaScript's same origin policy. So what does this mean? No, so I have a more fundamental question. Cool. That existence attacks are not only about same origin policy, but in the beginning, for example, in the Chrome, you could have existence attacks without them. You could have that same origin with something else, but you can have that attack on one site instead of JavaScript and run it and then people viewing that site afterwards can have that attack on the system. Exactly, and that's a circumvention of the same origin policy. So let's think about it this way. So you're in front, you're gonna be one. You're a good website. I'm a browser, I go execute your JavaScript. You're a bad website, right? I go to you, I can still, if I go and access a bad person's JavaScript code, that JavaScript code will execute on my browser, right? So you're still, I'm executing your JavaScript code, but your code, because of the same origin policy, can't access any of our resources on this good site. It can't access cookies, you can't make requests to that site, nothing. So I'm speaking, I know. I think you know what I'm speaking about, but I don't want to. But it is same origin policy, that's the difference. So the thing is, if you had some JavaScript code, that was bad, right? Your bad JavaScript code, if you gave it to, what's your name? Caitlin. Caitlin, if you gave it to Caitlin and then she gives it to me, now I'm executing her code plus your code in her origin. So it is a circumvention of the same origin policy. So it's not a circumvention of the browser's mechanisms to determine same origin, although that can happen, but other issue. But what happens is, as we'll see, basically, you trick Caitlin into sending me some of your code that you decide what it is. Okay, let's look at an example, because I like examples. Okay, we have an incredibly simple Ph, was it PHP? Yeah, PHP-ish page. So anybody that's familiar with PHP or ASP.net, what's going on here? So what happens to everything else? So this is a program. It's called. Right, so this is kind of what's called the templating language. So the only thing that matters is everything in between these purple tags that you may not be able to see very well. The less than symbol, the question mark, and the equal sign means when you execute this program, everything outside of that, leave it as normal. And what's inside here, this dollar sign name variable, replace right here where this tag is, replace that with whatever the name variable holds. So everything outside this tag remains exactly the same. But at runtime, whatever this name variable has, that'll be substituted and sent to the browser as bytes. So if you were to access this test page and say, hey, I want test page, I want test or server, I want test.php with a name parameter of atom, it has its code. And let's say that that name variable is mapped to this value right here in the URL, this atom. And so the web server says, great, I know how to do this for class. I just take whatever this name variable, the value of this name variable, which is this part here. I'm gonna substitute that here. And now I have a bunch. So before I had a PHP program, now what I have, I have a bunch of bytes that should be HTML, that I want them to be HTML. They're really not HTML yet. There's a bunch of bytes that I ship over to the browser where the browser does what? Parse. Yes, it parses those bytes into HTML. And then it displays a screen that says, hello, atom, which looks something like this. Any questions so far? Pretty simple, right? So what if instead of that link that I had before where I had the name of atom, what if instead, let's say the bad person sends me a link, so let's say example.com is Caitlyn's site. The bad person sends me a link that looks like this, right? So like, hey, you want a free iPod? Click on this link, or iPhone, I guess. Sorry, I should update that reference. Yes, you want a free iPhone? Click on this link. Who buys iPods? All right. So it's not a link to the bad guy's server, right? This isn't the bad guy's domain. This isn't the bad guy's server. He's sending me to Caitlyn's webpage, this test PHP, but he's just set the name tag to be these script tags. And this is just a way to pass data. So there's nothing that says that you can't do this. So then I click that link. My browser makes a request to Caitlyn's server. And so what does the PHP code do? Exactly, it does exactly what it did before. It doesn't do anything different. It says, hey, look up the name value. Bam, replace this here. Send these bytes to the browser, where the browser now takes these bytes, parses them, turns them into HTML. And what does it see when it sees these script tags? JavaScript. JavaScript, and it starts executing it, right? But where did that JavaScript come from? Did it come from Caitlyn? No. Oh, it came from the, we'll just keep using malicious, because I don't want to get your solely your good name associating you with malicious content. Yeah, so now in, and what's this script that's executing, what's the origin of this JavaScript? The same origin policy. What's the origin here? The three-tubble. Oh, exactly, or HTTP is the example.com. It still works. 80, yeah, exactly, it's Caitlyn's domain. HTTP, example.com, 80. So here, our attacker, our widely attacker, has been able to trick Caitlyn's web application to having us execute our browser execute JavaScript as if it came from Caitlyn's domain, thus subverting the same origin policy. And once they can do that, now they can make this JavaScript do anything. And so if you have an example like this in our lovely Chrome browser, it's gonna pop up and say, hey, JavaScript alert, cross-site scripting. So here is exactly that. I have example.com, I have the name, and I have the script up there. You know, the browser's stupid. It just, all it sees, it's not stupid, but all it sees is bytes, right? And so it parses that HTML and turns it and renders it, displays it to the user. Questions on that? Before we go on. Dive a little deeper. Does this make more sense now, Partha? Reflected cross-site scripting, yeah. Okay, cool. Okay, so, yeah, the basic idea is, so there's a couple different ways types of cross-site scripting. This is kind of reiterating it. We have our malicious actor. He gets us to click on a link where the malicious JavaScript is inside of some URL, some parameter. And so when we make this request to the server, the server gets that malicious JavaScript, includes it in its HTML page, so that when it returns it, our browser thinks that it came from the nice, Caitlyn's nice awesome website. What's your website? What, my actual website? Oh, I don't know, any website. I actually have one, but it's k.com. Okay, what does it do, I mean? It's just like a platform. Okay, cool, okay, so, yeah, Caitlyn's website then sends us that JavaScript. So now our browser's executing JavaScript from the attacker in Caitlyn's domain. So this is what we call a reflected cross-site scripting vulnerability. Because the JavaScript is coming from the link, right? Our browser is essentially supplying, if you look here, right? Our browser is supplying that JavaScript and the web application takes input from our browser and uses it in the HTML to send to us. So the thing about is like, reflecting, our JavaScript is being reflected back at our browser. So the other way this can be done is in the case that there's a backend data storage. It can be SQL, it can be the file system, it can be a memcached, whatever, it doesn't really matter. So here, now what the attacker does, instead of first getting me to click on something, the attacker can maybe, let's say create a new forum post and set the title equal to some JavaScript, right? So just like before, where instead we were making a link, but this time we're doing some action. We're creating a new, let's say blog post. You're gonna be a blogging software. So, he accessed Caitlyn's web, Caitlyn's blogging platform that's gonna be the next blogger and get bought for millions of dollars from Google. He creates a new blog and sets the title to be some JavaScript. So the web application, right? So, how does it create a blog? Where does it store these blogs? Server. Server? Which is the database, yeah, exactly. All basically the same thing, but it's gonna store that in the database because when I go see that blog, it's gonna go pull that out of the database and show it to me, right? So if in the SQL query, that JavaScript gets stored in the database, it's like, hey, here's this blog post, bad guy made a blog post, it's title is some JavaScript, whatever. I'm just storing titles and databases, right? There's no security problem here. But now, and then they get a response back from the user. So like, hey, good job. You created that blog post, cool. Now, I'm an unsuspecting user. This time, the user, the bad guy doesn't have to trick me to click on anything. Maybe I always go to Caitlyn's blogs to see what the latest blogs are because I love that and it's part of my daily ritual, right? So I go and see like, bam, what's the new latest cool blog? And then so the database says, oh, that's a great, or the web application, the PHP code says, that's a really good question. Let me go ask the database what the latest blogs are. So it makes a SQL query, fetches some things from the database, and then is creating an HTML page where this JavaScript that our malicious attacker used to create the web application or to create the blog title gets included in the HTML page. And now comes back to me. My browser looks at these bytes, it parses it, and if it sees any script HTML tags, it executes them. So where did this JavaScript come from? What was it? Yeah, it came from the bad guy, right? This is not Caitlyn's JavaScript. This is the bad guy's JavaScript. But he was able to trick the database to store it and to send this to everyone who visits that page. So this, because we're academics, we like to split things. So this is what we call stored cross-site scripting. So here this JavaScript payload is stored, or this cross-site scripting payload is stored on the server and anybody who accessed that page gets, has the attacker's JavaScript executing in their browser. Questions? Ready for a test? No? Got a thumbs down. All right, so it may seem like, well, not really a big deal, right? So we talked about JavaScript. It's all in sandboxes, right? So yeah, maybe I can subvert the same origin policy, but I don't know, is that really a big deal? So we're gonna look at it. Yes, it is a very big deal. One of the coolest things you can do with cross-site scripting vulnerability is you can fish people. What is fishing besides the thing you do in like a pond? It's like social engineering. Trick people into clicking a link. On the right-hand side of the database. Yes. I don't know this. Exactly. Yeah, so you're trying to get, so the fishing aspect comes when you're trying to get people's credentials. They use their name passwords to go to you, to Facebook, to their banks, to PayPal, all that kind of stuff, right? And so typically what happens is the bad guys will trick you to click on a link that takes you to facebook.com and you look at it, don't realize three O's is not two O's, or maybe two of them are zeros instead of O's, and so it looks like Facebook. And so it looks like the login page, right? It looks identical, so you put in your information and it goes, oh, that's weird, you weren't logged in. That's funny. And then it redirects you silently to the real Facebook, where you actually put in your real credentials and you get in, but that first time that attacker got your Facebook username and password. So cross-site scripting attacks can make fishing even more dangerous because this malicious JavaScript that came from our awesome attacker because it has bypassed the same origin policy, it's executing in Caitlin's origin, it has complete control of the DOM in that origin. So the DOM is everything, the entire look and feel of this page. So this means that it can change what seems to be the current page to a login page that looks exactly like the real login page. It's on the real domain, but when you fill in your username and password, it actually goes to the attacker. So I did not, okay, so this is an example. I have done this in other domains, but for this example, so let's say I send you this link to Facebook, right? It's a login page, right? Everybody's seen this login page? Maybe, I don't know. Has anybody not used Facebook? I'll keep you all. And you think, well, HTTPS www.facebook.com, right? Seems legit. This is actually coming from Facebook server. And, but what you don't realize is that I sent you a link with some cross-site scripting, a reflected cross-site scripting attack. And what this JavaScript code does is when it first loads, it changes the entire look of the page to look like the login page. So we're really, this is a, what is this, lists? What this original page is probably a bunch of a list of users, or what is Facebook lists even? I don't know, a list of something. But instead of showing you that, it shows you a login page. And so when you fill in this username and password, that's coming to, well not me, to you, to the attacker, right? Because you tricked us into putting in the username and password. So would you fall for this? No, I'm super smart, everyone says. Great, then, in this, yeah, you'd like to think you would. So in this, it's pretty easy, but, everybody's seen the percent junk in URLs, right? Okay, you completely hide all of that in percents, and you'll never know by looking at it what it is, or if it's a normal part of Facebook. It just looks like a link, like every other link. Or if I'm really mean and I know you like URL shortners, I'll send you like a bitly link, right? Then you have nothing. Any questions on this phishing? This is fun. Okay, this is one of the bad things you can do. There's three kind of bad things that I like. The second one is session theft. So what's a session? Aren't you all seniors, more or less? Yeah, it's a session like when you log on, that's like one session. Yeah, so you're interacting with a system and you're basically proving that you're the same person who interacted with it before, right? So when you're using, sitting at your computer, it's very easy. It's basically, what do I say? I don't know, you're physically there typing in things, right? That's how it knows that you're there. How do you do it on the web? Cookies. Nom, nom, nom, nom. So the problem is HTTP protocol itself has no concept of session. So the thing about web servers are basically amnesiatics where every time you go to them, they're like, hey, brand new user, awesome. Here's your webpage you wanted. And then you click a link to that same server and it goes, hey, brand new user, here's that link you wanted or here's that webpage you wanted, right? So HTTP itself has no way to tie the requests to the same user. Obviously this makes for really terrible applications. So what happened is the both the server side, the HTTP side and the browsers decided to implement this protocol called cookies where the web server can say, hey, store this little bit of information on your browser and next time you make a request to me, send me that back so then I can know who you are basically. And so it describes who they are, if they pass authentication. So cookies are great. And typically without any security precautions, JavaScript has access to our cookies. So the cookies is just an HTTP header that we send to the server, right? So if I were to steal the cookies in your browser to facebook.com, I can then access facebook.com go, here's my cookie, I'm Caitlyn. Give me all our Facebook info. Our malicious JavaScript that's executing that same domain has access to that domain's cookies. So what happens is the JavaScript, the malicious JavaScript, so we've done one of the cross-site scripting either reflected or stormed. This JavaScript can now have access, get that cookie that's stored in the browser and then send that cookie to the attacker. And now the attacker can make requests to the web server as if they were me. It should be really bad, yeah. So for like, JavaScript has access to the cookies but there's a limit like, it's only allowed to access the cookies for that page, right? Same origin policy. That's like, all comes back to same origin policy. So any JavaScript can access cookies and it's origin. So that's why you'll have different cookies if you sign in with, well, there's also a whole other, yeah, anyways, so yes. You can be very tricky and you can, JavaScript code can't make TCP connection directly. It also can't make an HTTP request directly but it can, an image tag has a source to go fetch an image and so you can embed the cookie data inside of an image to a malicious person's server. So your browser, right, when it loads any page, all the image tags on it automatically get fetched and loaded. That fetch happens through a URL so I can embed that cookie into the URL and you would write a little image that's not displayable but the browser sees it and then goes to try to load that image and it sends the data over there. Yeah. Didn't you also, Ajax calls or send an email to yourself with JavaScript? You, so for Ajax calls, short answer is it depends. I wouldn't try to rely on that because Ajax, well, yeah, you can, you can't get there, what am I thinking of? Can't remember off the top of my head of the same origin policy restricts Ajax requests. There are some restrictions like I think you can make maybe an Ajax call to another domain. Now I think you have to have like a cores like the cross-origin request header on that server sent to accept those cross-origin requests. I can't remember how it works but it's tricky. You also can't review the response. It's super easy to put in an image tag. Yeah. Why does JavaScript tend to access to the cookies? What do you want to do to just to wait for it? You may want to store data in the cookie from JavaScript code but actually one of the security mechanisms to prevent this is a web application can set a header or set a flag on the cookie that says don't allow JavaScript access to this cookie. So that helps for this but it does not help. Oh, sorry I forgot to complete this. So now the attacker can make an HTTP request to the server with that cookie and it appears as if it's coming from me. So these are the two bad things so then you think well yeah you exactly that's everybody's thought, right? Make it so that JavaScript can't access that cookie then the attacker can't get it. So what you can do through Ajax calls JavaScript can make requests to the web application to at least it's definitely it's same origin. So it can make requests to that web application which is how Ajax works, how Google Maps works without refreshing where you can drag, do all that fancy stuff. Pretty much most modern websites work nowadays. But the important thing here, the JavaScript says hey I want to make a request back to the web application to fetch some new data some new resources and your browser sends along the cookie to the website on your behalf because you're making a request to your own website, right? It's the same origin, right? So your JavaScript code you're making a request to your same origin, should be allowed, should be fine and that website wants to know who you are so you give it the cookie. So it appears from the server's perspective as if you the user made that request, right? Either you click the link or filled out that form. So this means that malicious JavaScript can do the exact same thing. So this malicious JavaScript that we downloaded in Caitlin's origin can now make requests on my behalf to the web application. So it can make new blogs in my name, it can change blogs, it can edit blogs, it can comment on things, it could go to your blog and plus one it because you wanna be super popular. And so the way this works instead of now, so before we had the cookie that went to the attacker and the attacker on their own used that cookie, now the JavaScript code just says, the malicious JavaScript code says hey, make a request to this web server and your browser just sends along the cookie, makes the request just as normal and gets some response back and the web application has no way of knowing that it came from malicious JavaScript or good JavaScript. And so it just accepts that request. So if you think about a banking application, right? This is why this thing is, these are really serious. So cross-site scripting on a banking application, now I can initiate a money transfer as you, right? I could add my account as one of the accounts that can withdraw from your account, right? And you think maybe you know a little about web, so you're like, ah, CSRF. Well, with JavaScript, I can write any program I want. I can fetch the page first, get the CSRF token and then use that in my actual request. So really, in JavaScript, I can do anything that you can do on that web application. Any questions before we go into famous exploits? Yeah, these are all part of the reflection. Either one, it doesn't matter. It could be the one. Yes. But any website is giving you no script tags, really? Yes. And even if they're not, that's the other thing, right? So that's part of the problem is the browser, really the more I think about this, the fundamental problem is Katelyn's website has some code it wants us to execute, right? Some JavaScript code that she has written, that she wants our browser to execute. But when the browser gets all those bites back from the server, it doesn't know which JavaScript code came from Katelyn and which one came from our malicious user. All it sees is script tags and it just executes. And so to me, that's what it boils down to is the fact that it has no way of knowing who's the good code, who's the bad code, right? So it executes everything. But that website was a real thing, not your browser? Yes, maybe, maybe not. Maybe she generates her JavaScript dynamically. So you can have, just like I said, it's just bytes, right? A PHP script can generate on an HTML page. You can also generate JavaScript code. All kinds of fun stuff. Okay, so putting these together, especially this last one, you can do really cool things. Sorry. One of the really cool things that can happen that you're not gonna do unless it's on your own system is you can actually make worms, cross-site scripting worms. So what's a worm? That's not the little thing you put on the end of your fit hook when you're phishing in the security context. Worm? Anybody? Somebody else? No offense. Take a stab. You don't have to be right. It's okay. It exists on your system and I think it can move to other systems, but. Yeah, it exploits you and it tries to find more people to exploit and then it exploits them and once it gets on them, it tries to find more people to exploit and it spreads virally throughout the network. So it was a big problem back in the early 2000s. So. No, that's what you're telling us. We named it right. Oh, virus is different. Virus is different. Well, maybe, I don't know. Yeah. Okay, but it came back in the mid 2000s. Yeah. So what you need for a cross-site scripting worm is you need a stored cross-site scripting vulnerability so you need something that persists and you need a way to execute unauthorized actions and you need this stored, the attacker when he injects the JavaScript into there needs to be able to do it with these unauthorized actions. Because it's pretty simple, right? So the JavaScript code, the unauthorized action that it performs on your behalf is exploiting that JavaScript payload. So the best way to think about it is social networks. So you have a Facebook page. You can edit your Facebook page to say something about you, right? Yes, it hasn't changed that much, yes. Okay, so let's say there's a vulnerability in the about me section, right? So you can edit that, put in JavaScript code and now anybody who visits your page, I'm executing JavaScript code on your machine on your behalf. So what do I have that JavaScript code do? I have it change your about me section to have it put its own code itself, that JavaScript payload into your page. And then so when anybody access, any of your friends access your page, that JavaScript payload on their page changes their about me configuration and then puts the code there. It spreads throughout the network affecting everybody's machine. So there's actually a really famous example we'll look at from 2005 on, oh God, I hate asking this question. I'm gonna hate it as I keep going, but anybody actually use MySpace or know what MySpace looks like, oh, thankfully. Okay, huh? Like now or? I don't know, at any point in time? Does anybody actually use it now? Sure, hold on. Okay, so in 2005 there's a huge cross-site scripting worm that was called Sammy was my hero, so we'll look at why. But it's not just an old thing. Tweetdeck, the Twitter application, had a vulnerability where, cross-site scripting vulnerability where it would execute JavaScript in a tweet and that JavaScript would post a new tweet with that JavaScript code in there that would post a tweet when you posted it, when you viewed it. So anybody who saw that message on their Tweetdeck tweeted out a new message containing that worm and so it propagated throughout the network. Okay, so this is a old, old Google, Google search for Sammy is my hero and as part of this worm, what it did was it added to their profile, but most of all, Sammy is my hero. Most of all, Sammy is my hero. Most of all, Sammy is my hero. So Sammy is the name of the guy who wrote this worm and it also, you can see a bunch, so what's this, this, oh, it doesn't have a list here, this has 3,500 results containing Sammy as my hero and so what happened was is Sammy wrote a thing, found a cross-site scripting vulnerability in the profile of MySpace and so anybody that visited his page first friended Sammy because who doesn't wanna be friends with Sammy and then they'd update their profile with this worm, with the text and Sammy is my hero in their profile and then so anybody who visited that person's profile automatically requested Sammy as a friend and put that worm in their profile and it went through on the network until he had, I think this was like after half a day or something, he had almost a million friend requests on MySpace. And this is from him, not from me, by the way, all the additions here, yeah, this is not me. This is from his site. I think I have, oh yeah, I have the link in the lower right here, so you can go look at the whole story. So he actually has technical descriptions of how he did it, all that stuff, which is really cool. Okay, so we definitely have to talk about prevention because we've talked a lot about exploitation and how to attack. Is it easy to fix cross-site scripting vulnerabilities? There's a lot of different ones. You could prevent JavaScript from running. Huh? You could prevent JavaScript from running. You could prevent JavaScript from running. I do like that idea, but then you lose out on the beauty of the, yeah. You lose the beauty of the web. Well, one of the proofs, well proofs, that it's still a problem, so that Sammy Worm was from 2005. And I didn't look it up, but I'm, without a doubt, there's probably cross-site scripting vulnerabilities in a Google web application within the last three or four months. Like these things are still happening in all kinds of applications a decade later. And it's because it's very, very difficult to protect, prevent. And this is kind of the problem with just doing this in one lecture, is I can't really show you all the examples of why it's crazy complicated. One of the problems is every piece of data that's returned to the user, right, that can be influenced by the user's inputs to the application must be sanitized. Whether that came from the get parameters in the URL, post parameters from the user, any cookies, cookies come from the user. You could put JavaScript in there, cross-site scripting payload there. The request headers, the HTTP request headers, you can put cross-site scripting vulnerabilities there. What about if the database fetches Twitter feeds that are then used in HTML, right? It's from a third party, but if it ends up in an HTML response, you've got to make sure that it doesn't have any unexpected JavaScript. File contents, what if I can upload a file that gets included in a page, right? So the attack surface of a web application is huge. Any place that data comes in and then can go into an HTML page has to be sanitized. So specific languages, PHP, often provide, they have routines to prevent introducing code. But the problem is, so the way this works, I don't want to slide, but it's fairly simple. So the problem is that the browser looks for these tags, right, so it looks for a less than symbol, a tag name, and then a greater than symbol. The sanitization takes the less than symbol and turns it into ampersand LT less than semicolon. This is a way to tell the browser, hey, show me a text less than symbol, don't interpret this as the special HTML less than symbol. So this is what we mean by sanitization here, where now if our attacker's JavaScript, the script tags that he gives us, if it's translated to this, percent LT, oops, right, script, well now the browser doesn't see this as a script tag, it sees this as, hey, show me the text less than symbol, script. And so that's how sanitization works. The really big problem is that HTML is very complicated and different sanitization needs to be performed depending on where in the HTML page the data is used. So if you're worried about just script tags like this, this is one way to execute JavaScript, you can execute JavaScript as attributes of elements, you can execute JavaScript inside JavaScript. So like I said, if you're dynamically creating JavaScript and using something from the user, then I never need an opening script tag because I'm already inside JavaScript, I can just change it to do what I want. There's even a whole other thing I didn't even talk about, but JavaScript has an eval function which takes in a string and interprets it as JavaScript code and executes it. So now as long as the attacker can get control that string that gets executed, they can execute arbitrary JavaScript code. So this is something that I and other people have tried to study is the fact that the sanitization has to be performed based on the HTML context. It's not like there's just one thing, hey, do the sanitization, you'll be safe. So it's really difficult. So it's gotta sanitize all your input. Yeah, very important. Okay, tools, if you wanna go more into this. Oh, sorry, I'm a little bit over time. Okay, some important tools. These top two tools, you need to know what's going on in your browser to debug JavaScript, so the browser developer tools. You need to be able to look at what's happening on the wire for something like Wireshark. BERT proxy is actually a professional pen testing tool. They have a free version, but when I do professional pen tests, this is what I use. These last two are links to applications that you have free reign to go do whatever you want. The Google Gruyere, I'll say, is awesome. So this, you go here, you click a button, it launches you a fresh instance of this application, and there's a ton of vulnerabilities. So it'll tell you which ones they are, you can get hints, all that kind of stuff. So it's really fun to play around with. Thank you for having me. I'm sorry I took a little bit longer than necessary, but yeah, I'd be happy to answer any questions. I don't know. You guys just want to go, so. Thank you, I guess, thank you.