 Let's get started, right into it. So we left off on Friday talking about client-side cross-site scripting, right? So what, fundamentally, what is cross-site scripting? So somebody help us. What is cross-site scripting, what? What's the scripting? Yeah, what's scripting context? Yes, very close. Executing some sort of malicious code that the designer did initially design for, I guess. Yeah, so main idea is, right, in a browser, we're somehow getting somebody else's code is executing. But when we visit random web pages, right, somebody else's code is executing on our machine, right? So what's the difference between that and cross-site scripting? Is that why they cannot stay more than two minutes? Yes, the same origin policy, right? The key problem is that code came from somebody else's origin, but it's being executed in the same origin as a trusted site, right? And once it's accessed there, once it's executing in that same origin, it has access to everything. So we talked about the different types of cross-site scripting vulnerabilities. We talked about reflected and stored and client-side cross-site scripting. One of actually the really cool things that can happen with stored cross-site scripting is cross-site scripting can be warmable, which is great for. So what's a worm? You're not like the thing in the ground, but like a computer worm. Yeah? Like if you inject anything, it will spread between that board and that post in time. Yeah, so there's kind of some key properties, right? So a worm usually exploits some security vulnerability on your system. Then when it gets on one system, it scans the network looking for more systems that are vulnerable. When it finds them, it propagates to them, finds more things that are vulnerable, propagates there, right? Just like the original Morris worm that took down the internet that we looked at. And it actually may seem kind of crazy, but there are cross-site scripting worms in the web context. Mainly this shows up when this occurs in social networking web applications. That's kind of the main thing here. The idea is if there exists some stored cross-site scripting vulnerability on a user-accessible action, right? So think about my profile page on Facebook. If there's a cross-site scripting vulnerability on my profile page, I can inject JavaScript code. And then when anybody goes and visits my site, right, they're going to execute that JavaScript code. And that JavaScript code can then edit their own profile to copy itself into their code, into their profile. And then when anybody visits their profile, they're executing that code. So that JavaScript code can then copy itself to their profile page and spread throughout the network in this way. So it's a self-propagating worm. So it's actually super cool. It's JavaScript code that's able to completely copy and clone itself. Social networks are particularly susceptible. So there is a pretty famous saying is my hero case in MySpace that we're going to look at. But this also happens more recently. So TweetDeck is a Twitter application. And it had a cross-site scripting vulnerability. So you could send a tweet that contains some JavaScript code. And when the user viewed that tweet on TweetDeck, it would host a new tweet containing that code. But anybody who saw that code on their system would tweet that same code, right? And so it would spread throughout the network. So the MySpace case, anybody actually was on MySpace? Remember MySpace? Oh god, it's like Facebook, before Facebook. All right, so there is this thing. So Sandy is my hero. So this one person created a worm on MySpace, a cross-site scripting worm. And it added its code, but it also added to the hero's section of their MySpace profile. But most of all, Sandy is my hero. And this was, let's see, oh it doesn't have all that. But you can see all of the people here that had these. And then you can see the third result is MySpace got hacked, question mark, question mark. So what happened was, so this MSN, who uses MSN? All these pictures are from the person who reported the vulnerability. So this is like 3,500 pages that have this Sandy is my hero in them on MySpace.com, or HADD. And the other thing that it would do, so it would, the code would copy itself to the user's profile page, add this Sandy is my hero, and also send Sandy a friend request, because that was cool back then, right? Having a lot of friends. And so, this is a picture of Sandy's own feed. He had, what is this? 913, 919,000 friend requests from doing this worm, right? Remember, this is the crazy thing, right? You have a social network, so once, it really spreads like viral, right? Whenever anybody sees that worm, they automatically propagate it to their own friends, and those people propagate it to their friends, and those to those friends. I did not do any of these. This is from Sammy. So this kind of shows maybe the power of cross-site scripting vulnerabilities, right? If we have one of these, we can propagate it throughout the network, a sort of cross-site scripting like this, right? And this is kind of just one of the bad things that we saw can happen with cross-site scripting vulnerabilities. We also saw how we can steal cookies, how we can change the UI of the page, how we can fish with cross-site scripting, how we can make requests to the web server to all these kinds of things. So how do we solve it? Isn't that easy? How do we solve it? Turn off JavaScript. Turn off JavaScript for the entire web. That may be a good way for you to prevent your own self from running out of these problems. Does that even browse with JavaScript turned off by default? Yeah, do you actually do? With what extension do you use? Do you, like, selectively allow it on certain domains? Sometimes it is about the way that it will be enabled. Mostly you do enable it. Wait a minute. Do you name where to disable what? JavaScript or the extension? JavaScript. So you mostly do enable it, but you have done it with not. Okay, yeah, that sounds more safe. Okay. Yeah, so you can actually do pretty well, I mean browsing, you should be able to, theoretically, right? JavaScript is just a scripting language. Anybody, I know some of you have done professional web development stuff, right? So you've actually, one of the kind of theories or ideas in web development is you want your websites to gracefully degrade, right? So they should, if the browser supports all the fancy JavaScript animations, Ajax, everything, right? Then you can use that, but if they don't, right? If they're on an older machine, then your website should still be useful and usable to them. Unfortunately, that's often not the case nowadays, right? So, and it's gonna be more and more as we go further and further and developers are gonna assume that everybody has JavaScript and anybody who turns it off as a monster, you're not gonna be able to browse the web, unfortunately. And that only prevents you, right? That's only a one-person defense. If you wanted to deploy that to everyone, you'd have to disable JavaScript across the entire web, which would be a very tall task indeed. So what else, what are some of the ways we can solve this problem? Some sort of like this for what you deem appropriate as a designer and then just, I guess, and then just pretty much purify or encode everything else. Ah, so purify or encode, right? So what's the key problem? I mean, from the examples we saw with the script tags, what's the problem? Execute? Yeah, so what causes the script execution? We're all fixing up the code. Right, so the fact that we have the angle bracket, which tells the browser's parsing engine, and hey, start parsing a new script tag, right? So we've kind of already seen, well, why don't we just sanitize all angle brackets to their HTML entity equivalent, right? Why don't we just do ampersand, LT, semi-colon, right? And we've gotten rid of all cross-site scripting. So why isn't that enough? Yeah. And there's sites you're gonna break by doing that. So you have to have some kind of optional implementation. So, stay on that a little bit more. What sites are you gonna break? If I- Sites that are doing, I mean, probably valid sites out there where they're doing things that look like cross-site scripting, but it's actually valid. Yes, that could be, but, I mean, if you're letting your users upload an execute JavaScript, you've probably already lost the game by design. Well, I'm not just gonna have a look. I'm saying the developers could design the webpage to be sending that information through URLs, explaining it. Right, which is also bad. Yeah, but I guess, yeah, that actually does happen. Yeah. Yeah. KPN encoding does not be a sort of example. After programming, do you think there is an inside JavaScript code inside? Yeah. Right, so what if, let's go, writes in code, not like the calculus, right? What if I have, right, I'm inside the HTML page, right? So HTML entities encoding does what? It transforms this character to, this actually gets confusing, like this, right? Sanitization transforms less than simple to there, right? But what about inside my tag? What if the user input is here? Okay, this user input, let's say it's on there. Do we need a less than symbol now? Double quotes, right? Because we're inside double quotes here, inside an attribute of, inside a value of an attribute inside of a tag, right? So we saw that huge list of cross-site scripting vectors, right? One of those would be on, let's say, mouse over. So here, what if for a class here, we put our username as double quotes, space on mouse over alert one. So this part is our, let's see what this sign looks like, right? So this part here is everything that we put in. So is this gonna execute JavaScript that I want? Did I need any less than symbols? Did I? From my input? So if you're doing HTML entities and you're changing all less than symbols to Anderson and LT, semi colon, does this help you here? No, and in fact, I think we need to look it up maybe, but I believe HTML entities will not encode a double quote because a double quote is fine with HTML entities. It's not one of these special characters in HTML in the case like here, right? In this, here, now we need some kind of script tag, right, to start executing a script or we need to start some kind of a tag. So here we need, think about parsing, right? We need a less than symbol to transition the browser's parsing engine to start a tag and then the tag name and then some JavaScript, right? But here in this context, right, of the browser's parsing engine, here I need a less than symbol to transition to the JavaScript execution. When I'm inside this attribute here, what do I need to transition? A double quote and probably a space, right? But we saw there's actually different ways that we can do this. We can also saw that attributes can actually be single-quoted. So I can have the user input here, in which case I just need single quotes. It can actually be also without quotes, even where now I just need a space and then going back to the other point, people have written web applications. Have you ever done something like this? So what's this code trying to do? What's the purpose here? Why would it ever write some code like this? And with the JavaScript too. So essentially passing variables, passing data from the server side code to the client side code, right? At runtime, whatever that name variable is, is gonna be substituted in there so that JavaScript code will now have access to this name variable. This is actually exactly how some, oh, we just go into those again. This actually happens a lot, even in things like, what's the big Microsoft SharePoint, I think? No. Yeah. I can't remember the framework, but there's actually a lot of web application frameworks that use techniques like this to pass information to the JavaScript code. Right? So now here, now what do I need? Do I need to start a new script tag to execute JavaScript? What do I need? I'm just gonna name it. Yeah. I'm gonna semi-colon and whatever you want. What do I need? So I'm in here. So I'm an attacker. What am I gonna type in? A single code semi-colon and something. What do I do at the sub at the end? So now here, but see, I don't need, all I need is a double code. I don't need spaces. I don't need an on mouse over or any of these things. I would kind of know them to be bad, right? And why? Why don't I need any of those? What script tag just executes whatever it is? I'm already, exactly. I'm already the output, the user input is being used inside of a script tag. So it is already being used as JavaScript, right? Think about the browser parsing engine. It's already inside JavaScript parsing. I just need to figure out how to transition it from JavaScript string to something else, right? You can even do this. I did find, I was doing some pentesting work there was basically like a JSON object that was being returned. And so they weren't escaping that correctly. So we could bust out of the object in that way, but the exact same technique. So you can have, yeah, so we're like, but yeah, just all depends on the exact application, right? So when we talk about sanitization, right? That's typically the problem is, hey, we just need to sanitize and everything will be okay. The key core problem is cross-site scripting is that what sanitization do you use? There is no magic bullet use this one sanitization and everything's gonna be okay. Different sanitization needs to be applied depending on where in the HTML this output is being used. So it boils down to, to me, this is really one of the fundamental reasons of why there is so many cross-site scripting vulnerabilities on the web today. Is that it's very difficult to have a silver bullet solution that just fixes all of these in all possible instances. Basically you need to have every piece of data that's returned to the user must be sanitized. And this is everything that can possibly come from the user, get parameters, post parameters, cookies, request headers, database contents, file contents, what you're pulling things in from Twitter and including that. What if there's actually, there are cases of people who have written books on web security that included cross-site scripting examples that caused vulnerabilities on book websites, like in like the preview pages and stuff. Yeah, is that nuts? Right, there's actually, there's a lot of work on mobile phones, so a lot of your mobile phones if you have like QR code readers. There's been some vulnerabilities that people have of if you encode script tags as a QR code in some of the readers, because it's using basically an HTML based application, it will cause a cross-site scripting vulnerability through a QR code on your mobile phone. Is that nuts? There's actually a, oh my gosh. So, oh wow, so everybody remember like the Apple thing, like the case with the FBI, trying to crack the phones and all that. Actually, recently after that, there was a group of photographers that said that they actually were able to break the high message encryption, so that they were able to read messages on iPhones through that. And that is super cool. And then another group came out like about a week after that, that said actually there's a cross-site scripting vulnerability on iMessage on Mac OS X. Apparently the Mac OS X messages is just a browser, an embedded browser. And so by sending proper cross-site scripting text message to somebody, if they read it on their Mac OS X, it would cause it to exude arbitrary JavaScript, which would extract all the messages that you ever sent to anyone and send it to whoever. Just through cross-site scripting vulnerability, yeah. Yeah, so that's kind of interesting because I was wondering, it's a bit of a negative side, but are a lot of applications in the web and mobile not developed natively? Obviously we would expect the iMessage to be native, but I don't know how much research isn't your research partially involved. Yeah, so actually we've done research on that exact question of, I call them, I like to use the term mobile web apps. So they're not just mobile applications, like native applications, and they're not just web applications. I don't know the number off the top of my head, but it was a surprising number of, we had 1.1 million Android apps that we analyzed to see if they use an embedded browser. Then we tried to answer questions like, what are they going to? Are they going to a remote site? Are they going to a local site? I think it was in the 70% or something where mobile had an embedded browser. Not that that was their primary UI, that's really difficult to tell, but at least used an embedded browser. And then we found all kinds of crazy problems like, they would use SSL, so they would go to HTTPS sites, specifically because they're loading code, but it turns out that they were suppressing all SSL errors in the code, like they explicitly put code to override a method that said on SSL error, do nothing. So you could trivially man in the middle of these websites and send them any kind of JavaScript you want. There were, one actually case that I really like, we identified all the domains were being accessed, and then we did a look up on those domains, and we found that actually some of those domains had expired, and so we registered, I think, 10 of those domains and saw how many people were contacting us, which is crazy, right? I mean, we could have sent them, we sent them like a 404 or something, but we could have sent them literally any content we wanted it wouldn't have been executed on that device, right? The same origin policy would mean that we would get access to whatever that site got access to, but still, I mean it's. Then to make things even crazier, what actually drove this whole research is prior to Android, I believe 4.2, there was a vulnerability, so part of what they do, normally these embedded browsers were very dumb, like they have no additional functionality, they're just, they're not at the same power level as a native app, right? A native app can access the contacts, assuming you have permission to write all that stuff. So it's actually a functionality called the JavaScript bridge interface, which gives you access to a Java object, a native Java object through JavaScript, and this bridge is not restricted by the same origin policy. It's to the entire browser, the entire embedded browser. So anything open, no matter what frame it's in, or anything has access to these Java objects. Now that's a big problem on the first place. The second thing is, it turns out with Java, using reflection, you can get into a class object, and then you can eventually get to a system call. So you can execute arbitrary code as long as you have one of these Java objects in JavaScript. So that's what we were studying, so we could have sent these, and we actually developed some exploits of, it's actually really fun. You could go to our website and we could, so we're running as the permissions of the web browser, so we could steal all your cookies for all your sites. We could brick your phone by making you run a fork bomb. That was a really fun one. All from a web, like JavaScript code, so. Yeah. Why would iMessage, which is developed by Apple, why would it develop it like that? Is it because it's easier to do web apps? I think it's easier, right? Yeah, and it's portable, I mean, in that way, right? This is why a lot of mobile apps do this, is especially there's frameworks like Cordova, I think is one, where you write your application as a web application and then you could run it on Android, or iPhone, or Windows phone, and it's the same web application, and they do the binding so that you can still access contacts and all that stuff. So, yeah. Anyways, okay. Cool, back to the stuff. Right, so languages, right? You need to do this in coding yourself for cross-site scripting. And the key part is that sanitization must be performed differently depending on where the data is used. And this is what makes it very tricky. You can't just say, okay, I know I'm gonna use this username, so I'm gonna encode this username once, and then every time I use it, it's gonna be safe. Every specific time that it's used, and it's not the server side path, it depends on exactly where that is being used in the generated HTML output. So you have this really complex dependency between the input and where in the output that's being used. And there's actually been a lot of work by the research community into this really, it's about context sensitivity in cross-site scripting. And so, there's a whole bunch of, if you go to the OWASP site, which I know some of you did for the projects, there are a whole bunch of rules to how to never insert data and exactly what sanitizations you need inside the HTML comments, inside an attribute name, in a tag name, or I didn't put the HTML comment, yeah, HTML comment's an interesting one. You have to escape things, and it depends on, so these characters or the XML parsing, the parsing characters that you need depends on if you're inside attributes, you need different things, single quotes, double quotes, right? This is just, this is the OWASP solutions list, right? And it involves all these crazy rules that you have to keep in mind as you're doing it, right? Inside JavaScript strings, inside JavaScript variables, inside event handlers, it could be that you're using a bit inside a JavaScript code inside an event handler. Even to make it even more crazy, we didn't talk about CSS, what's CSS used for? So we'll look at all of those. It's styling, right? It shows, yeah, so the HTML is more about the content of the page, and the CSS is supposed to be the, how does that look, right, the styling of it? It's how you control all the things to do like the rounded corners on boxes or whatever kind of stuff you want it to do. Turns out you can execute JavaScript inside CSS. There are rules in CSS where you can execute JavaScript. So now if you're using any user input in your style sheets, right, then you have to make sure that those are done properly. And style sheets could be separate files, they could be embedded styles, inside a style tag, they could be attributes on an element inside there. It's crazy, it keeps going. URLs, inside URLs, we can put data inside href tags, image source, script source. So this cheat sheet has a very good list of how to actually prevent these things. And this is where this list comes from, yeah. I see a escape, escapes over, is that the way the solution, like you would deliver code swell and escapes on the reader? Do you have to prevent code? Yes, you have to be very careful. So the other alternative, which I don't see a lot of frameworks make, is you have to basically ensure that you can't just generate the HTML of the page by concatenating strings. That's the essential problem, is you're outputting an HTML response, you're creating it by a bunch of print statements, which are essentially string concatenations, right? A more principal way to do this would be on the server side, create the DOM that you want to send programmatically, and then send that, serialize it to HTML, and then send it. There has been some work done on that. I'd probably write a paper on that with using a type system in Asphalt to make sure you can actually do that, but unfortunately nobody really does that. The main way it's done that I see frameworks now is they have a specific, they use a templating language, like we saw in Ruby, that is restrictive, so it's not a whole programming language, and they automatically sanitize, and they can usually tell, depending on the context, they can perform the correct sanitization. But they always leave you the option to turn it off. Because then it gets into the case, which some of you are thinking about in your projects, what if I want to include links? What if I want to include some HTML? I want to include anchors, because I want people to comment and include links, but I don't want them to be able to execute JavaScript. So that's like this cat and mouse game of, you're trying to sanitize it or white-list it, but every possible browser could parse things slightly differently in weird, malformed cases, so you have to handle all the malformed cases, in terms of a huge problem. That's, I think, part of the reason why languages like Markdown have become more popular for doing that, is you can do that securely when you transform that. Questions? Cross-scripting? They're going to look at, we're going to look at some other web vulnerabilities that I wanted to get to if we had time, and we do have time. I just need to find out where the heck they are in all of this. Do we want to go over the same order policy again? I don't remember. Okay, and I believe I need to turn on one of my VMs. I think I have an actual example here. So, going back, right, we've seen what information does the web browser store for the server? Cookies, yeah, cookies are the main one, right? Does it store any other kind of data? Session data? Yeah, what other kind of session data is that Cookies? What was that? Cache. Cache, yeah, it actually stores, you think of the cache of the history, right, of the URLs that we've seen. What about, like, forums that are sent? So, we saw that we can have forums with hidden attributes, right? But where does that actually come from? I mean, the form comes from the server but when we submit it, where did that data come from? The user, right, from us, from our browser, it gets sent again to the server. It actually turns out that plugins like Applets, Flash, and Silverlight, these can all store additional information. And actually this is how they do, used to do it, I'm sure they still do, now have cookies that expand. Oftentimes when you get rid of all your cookies, so, like, a lot of websites, a lot of companies want to track you online, right? So, one way to do that is to use cookies, right? Cookies inherently track you online, but you can always delete all your cookies, and so the web server should see you as a brand new person. But what they do is the cookies, quote, quote, inside of Flash are different, and so they can have a little invisible Flash applet that stores a cookie, and the next time you visit that site after you've deleted your cookies, they pull that, what they call, the super cookie from Flash, and then they can link you out to your previous browser history. Right, that's a whole other area of research. There's also newer things like local storage. This actually allows JavaScript to store, I think up to like 50 megs by default, but it's configurable, per website on your browser, to actually store information on your browser, on your machine. This actually is really cool because it allows you to make offline applications, like Google Docs offline, uses the local storage to store locally your files. Yeah. This is like a Flash applet, they're a plugin that runs on the browser, so if I delete all my cookies, where would Flash store the cookie? It has its own cookie. It's not the same cookie, it's like a different storage mechanism. Like Flash allows each, I think it's origin, but it does allow applets or Flash, what do they call, turn on applets. Movies, I guess I want to say, they can store some data in like a Flash separate area. And because it's separate, when you delete cookies, your browser goes, yeah, I delete all the cookies, but because Flash is outside of the browser, it doesn't know about those data. Should also be able to track you through like private browsing though. I don't know. Cool. Okay, so the class of attacks we want to talk about is how can we, so this is all information that's stored on our browser, on our machine. So what, so we can actually change this and mess with this data because it's on our machine before we send it back to the server, right? So there's absolutely nothing that prevents us from not tampering with or changing any of this client side information, right? Everything we send to the server, we can change. We can change the URL that we access. We can change the refer, refer header that gets sent to say we actually came from a different URL. We could change any hidden forms that are stored on our browser. We could change the cookies that are stored. We can change anything, anything we want. So tampering by itself is not really a vulnerability. I mean, the fact that we can change things is built into the protocol. When would this become a vulnerability? When the tamper data is being used. Yes. If the server trusts that tamper data and uses it somehow, right? So the question is what we wanna try to determine is how does the server side code respond to our tampering? Does it reject the request? Or does it accept the request and accept that data that we sent? If it did, then we definitely have a problem, right? So the conditions are kind of if the server side code allows tampering, right? And that tampering somehow compromises the security of the application, right? If it just allows us to do nothing, like change our name, maybe that's interesting, but probably not, I mean, it has to actually compromise the security of the application. Then we actually have a vulnerability. So one of the ways this manifests itself is with hidden form fields, right? Those are sent from the client to the browser and then when we fill out the form and hit enter, the browser then sends those back to the server. So the input element can have a tight attribute of hidden and then it won't be shown in the browser. And there's actually a lot of legitimate uses for this behavior. So why would you want to do this? Anybody who's done this before or yeah? Sometimes you wanna send a unique idea of something which has no formatting which wouldn't make sense to a person seeing it on the browser. Right, yeah, so kind of like actually almost for session purposes in some way, right? We may want to send some kind of unique session tokens to them and have them submit that back to us. What else? Configuration information. Configuration information, so what kind of stuff? Any language, different stuff that the user want. Yeah, that's not important to the user but maybe can affect how your code processes that request, right? Other things, captcha. So they actually sometimes will include these as a captcha, type thing. So the idea is if the captcha system or if the bot changes that hidden form field then they know it's probably a bot doing this and not a human because a human would not change this field because they can't see it. Cross-site request forgery protection which actually kind of gets into the, specifically into the session information. We're not, I don't think we're all the time to talk about that but you can look up what that is and why it's important. And the basic problem is if the server-side code, right, blindly trust this data that's in place there. If it just accepts it as valid as the truth that's when we have a problem. If it's for some configuration changes, right, which it just doesn't really change it then we're not gonna have a problem. So let's consider, all right, we have, let's say we have some super simple forum, like a checkout, think about an e-commerce application. This is like a fake application that I've made. It actually doesn't even do anything. It's not actually an e-commerce application. This is also not my credit card number. Is it someone's? Actually I don't know. It's a good question. I made this a while ago, so we'll see. It's not long enough. It's not long enough? It is long enough. Four, four, four. I think there's one extra character here, right? It may also not pass the lease check but maybe you guys want to volunteer and throw your credit card number in here. I think he's fine with that, right? So this is like a normal, this is think about the Amazon page, right? Before you find the click that purchase button, there's the page that says has everything laid out, right? For all the things that you bought, how much you, the quantity of items that you bought and the price of each of those items and the total price, right? And so if we look at the HTML, if we look at this code, it looks something like this. So we have the stock type. We have a hidden form, e-commerce application. We have our checkout, our total price, our credit card number. And then we have that button. So what is that button? That purchase button. What do we think it probably is? Yeah, submit button, and what does the submit button need? Forms. Forms, right? It needs to be a part of a form because we need something to happen when we click that button. And we want it to be a post, right? Because we definitely don't want it to be a get request because that should be I am potent and it should never change the state of the application, right? So in order to do that, that's why all the, it should be the case that all state-changing applications are flat ones, right? It's a form, but it didn't have any fields that we could actually change. But if we look, we saw maybe a purchase, actually, let's check this out real quick. But I believe I put this code on the server. We'll see how this goes. You should probably not be able to access that, so I would probably not try. I need to figure out the IP address of my machine. It's 172, and it was hidden form example, right? So here, I have a confirmed checkout page, I have my laptop, my monitor, I'm getting a new computer who's stoked about that, and then put a fake credit card so I'm even more stoked that it accepted this, right? And so we want to try to understand what this application does, right? This is part of pen testing, part of finding vulnerabilities in applications, right? We want to interact with it to first find out what it does so we can know how to break the security. So I click this purchase, it says hey, your purchase was successful, your final order, your final order total is 2,500 USD, charge to your credit card, X, X, X, X, X, X, X, X, whatever, right? So good. Okay, let's say we go through the process again, let's look at this page. So we can right click always and say view source, which will show us the source code of this page. So here, right here is the form, it's action is purchase.php, so we know that purchase page is gonna get called. It's gonna pass in parameters with post, which makes sense. We have our input of type submit and a value of purchase, right? So that's where that purchase button came from. And then we have a series of hidden fields, right? We have some OID, right? Some price and some curve. So what do we think these are? Remember, we don't know the source code of this application, right, we're just in a black box way. So what do we think this OID probably refers to? Order ID probably, yeah, it's probably linking, right, that order that I wanna purchase this order. The price. The total price. Yeah, the total price in dollars it looks like since this is the price here. What about current? Currency. Currency, yeah. Cool, so how do I mess with these? What's the price? What do you wanna do? You wanna change the price first? Okay, so I first need to put this in developer mode. See, does the developer mode work on here? Maybe I don't have the top of that, I got more tools, there you go. Developer tools, right, so this will show me, actually it's very cool, this will show me the whole dom of the page. So this shows me the dom and I can access it just like a tree, right? So I can look at all these values in here. So there's actually a few ways I can do this, that's pretty cool. I can actually just double click in here. How, what do you want? Zero. Minus one. Minus five. All of you have very different levels of risk. Zero, negative one, negative 5,000. Yeah. That's a good one. Oh, 25? Oh, you wanna go to the opposite here? No, negative 25, negative 25, that's a good one. Yeah, that's a good one. Okay, now when we click purchase, what's gonna happen? I'm gonna go to the place. Fail, not the correct price. We change a... One dollar? We change it to USB, or from USB. One dollar, let's try one dollar. Fail, not the correct price. But we tried one dollar less, maybe that'll... So what about the order ID? Maybe we can buy somebody else's order? So then maybe what can we change? Currency? Currency? What's another currency? SEC? SEC? What is that? I don't know if we're getting a deal or not. Maybe we're getting... I was trying to look one up real quick, but that's the first one to pop up. What is SEC? Swedish? That's actually pretty good, right? If we can pay for... Let's see, if we did 2500, we got 300 bucks. We change SEC here. Pretty good, right? So the problem is that this application is trusting this information that came from the user. It's probably validating things like the price. So that actually was... I believe there's a few, I don't know if it's been a while ago, at the Apple Developer Conference, whoever was doing their website, you could register for the conference, you had to pay for it, but you could change the quantity to negative numbers, so you could get it basically for free. Oftentimes it's part of these applications to actually get them to refund money on your card, so that doesn't happen very often. But you can add, like, if I add, a negatively priced monitor, negative one monitors and one computer, or maybe two monitors, then I've gotten three monitors for the price of one. You should try COP. COP? Yeah, that's the currency. Nice, pulling me in the face of this, please. Yeah, that's a pretty good deal. I would take that back. Okay, so yeah, so the idea is we want to see what the hidden values are. We want to try to learn what they mean, how the application uses them first, and then try to see about actually creating, changing the price. We tried changing it to a negative number, which would've been cool. We tried changing it to zero. We tried just changing it a little bit, and none of those worked, right? So we had to try to do, and the key thing here when you're trying these things is you want to have some kind of hypothesis in your mind. Right, like, okay, if I put the price negative, it should A, allow me to buy it, and B, should refund money back on my credit card. That's your hypothesis. It turns out it failed, it did not work. Cool. So that was hidden form field, right? So we can change hidden form fields, but it's not actually trivial to do this, right? Absolutely nothing stops you from changing those, unless there was some, maybe you could use some crypto to change it, but even then it's, you're essentially making sure that they're tamper proof. It's also not a guarantee that they did not reuse that from somebody else, or you don't have any other kind of shenanigans that can be played with even encrypted things. Yes? You should put them inside the script list, make something. Did you put what? Inside the script list. Script tags? Yeah. Oh yeah, yeah, this I was in, this is pre, you know, this could be a cross-eyed scripting vector exactly, is the currency tag, could invent a cross-eyed script, actually. Should we try it? Here at the page, change currency. So one thing we have to do is we have to actually view the source of this page, because we don't know, yeah. So now you can see here that it is properly being sanitized, right? So no vulnerability. But we just got a laptop and a monitor for 80 cents, so I think that's pretty good. Although I wonder if we have to pay foreign transaction fees, I don't know, but that would be worth it, I think. Cool, all right. So that's what we want to get through today. It's good, on Wednesday we'll continue look at some other cool web vulnerabilities like this.