 All right, good. Can't test it. 435. Well, good start, guys. I sent out some info, some logins, and did anybody try logging in to that game? Does it work? Yeah. OK, cool. With the test game network running now, I'll keep it up for a little while, and then I'll figure out how to run a game test game network for all of you, so you each have your own team that you can log in to without worrying about something I'll log in. I'm setting up right now, homework 4, I'll be out optimistically tonight. I'm setting up a server for every single one of you, so it takes a little while. And also, to be honest, I'm having to go through and read the code that I wrote to set this up, and I last did this in 2000 and, I don't know, two years ago. Yeah, two years ago, so I'm looking at this code, and I have no idea what the computer is doing with us. Doctation. But it worked, yeah, exactly. Surprisingly, just like you guys in the great year of Node, I lost my constraints, too, so I happened to not log in. I'm redoing stuff. It'll work, it'll be cool. I'll send out a link to be able to go to town. Let's get started. So we left off talking about web security, and specifically, we were asking a question. We talked about that, yeah, there needs to be some kind of security so that when I go to hacker.com, that JavaScript that's executing on that page, remember when I say the JavaScript executed on that page, I mean that JavaScript code that's executing on your browser, on your computer, doesn't alter or mess with any of your other pages or tabs that you have open. So the idea is when we think about web security, we have this horrible diagram of the ecosystem, right? And so the idea is where do vulnerabilities exist? So this is an important thing where you get into vulnerabilities. We first need to talk about the most important thing to web security, but before we get there, we need to always be thinking in your mind when you think about, or you learn about a new web vulnerability, where does this vulnerability actually exist? Does it exist in the server-side code? Right, we'll look at vulnerabilities that allow an attacker access to your web server that you would not want them to, or in this case, it's the way I know this diagram, this would be more like the Apache level, right? Is there something in the web server itself that allows somebody to get in? Is there something in the web application's code that allows an adversary to compromise the security of your application? Or is there some vulnerability or something in the browser which either, which basically I can get your browser to do something that essentially you wouldn't want it to do, we'll call it very well. So this is kind of the three areas we're gonna be talking about and thinking about here. And this is what makes, so part of what I think what makes the web so complex is, A, you have all these different technologies which we've been talking about, so you can get started on this, you need to have five or six technologies that you know, kind of pat. Also, you have this really complex ecosystem between browsers and web sites or, and web servers and web applications and their complex interactions there. So the first thing we wanna tackle and discuss is how does the browser decide the essentially permissions of the JavaScript code. So it boils down to HTNF frames in essence. So there you go, who's done what programming has done a frame before? What does it do? In the same, yeah, you can go high frame or frame. So it's like the same window you can show multiple content. So the idea is frames allow you to tie in separate URLs together on one page so that HTML content is living together in the same visible display. And it was used in the early days to provide, I don't know if you guys have ever been to a horrible website that looks like it was designed in the 90s where you have like a navigation bar on the left that you can click links but it doesn't actually change the URL bar at the top because the other frame is changing. It's terrible, it's really bad to use because you can't link to things. Anyway, this is, there's a fan, I think they're, I wanna say it's a PhD product but there's a fan saying that like the worst of professional webpapers, the older and more established they are. I don't know if that's been through in your experiences at the time. So frames are super easy to do, a classic frame, you use these frames at tags, you then specify the different frames you want. So here we're using frame tags. The source specifies a URI, so these are relative URIs and we give a name to each frame and we can have a little tag that's displayed when the browser doesn't support frames but literally every browser supports frames now. And so if the content of frame1.html is 9.1 and frame2.html, 9.2, we'll see this layout. So we'll see this bar and we can see at the top though we don't actually know that we're on these other 8.html pages, right? All that we see is the URL are given initial page. So iframes are similar to normal frames but they don't need to be inside the frames set and the idea is they're in line. So it's almost like a transparent frame. There's no border around them. There's no way if you actually know unless you check the source that it's a different page. So we do the same thing here and we can see that it's just like this. So it's similar in line here. This is how a lot of, almost all of I would say advertisements are done in JavaScript. So when you visit a page or in JavaScript on the web when you visit a page, it gives you usually a snippet of JavaScript code which then goes, talks to an ad server. The ad server does a bunch of options to figure out how much somebody's willing to pay to deliver you that ad. Then they deliver an iframe content. They put an iframe content on your page which is the ad of the advertiser that was chosen. So it's a super relevant stuff. And so you have browsers, right? So even just in the case of frames, here you have one GUI element that has multiple HTMLs for multiple different places, right? These URIs could point to anywhere but the content still lives in the same page and more and more now we think of it in terms of tabs. That's kind of the first initial thought. I have, I think of web content from different places, right? Different tabs running in my browser but even among the same page in one tab you can have multiple frames that are executing JavaScript code and HTML from different domains. So the first thing which is what we kind of talked about is that JavaScript has a sandboxing mechanism. So I mentioned on Monday it should be terrifying that code is running that is sent from a random web server. One of the ways that it's less terrifying is that in JavaScript running in your browser you can't just open a random file, right? So the JavaScript code is sandboxed in this sense to what it can actually do and what it can touch and manipulate of your application. So similar to Java applets, we skip over Java applets for time reasons but maybe it's not the Java applets. Some of us don't know, okay? Cool. Yeah, so similar mechanism there. No access to local files, no access to LAMP. This is relaxed to most network resources. You're used to not be able to just get a random socket to a random IP and port although there are ways around that. There are additional features here like no incredibly small windows so you can't make a window in JavaScript that's really tiny. This, everybody remember the pop-up age or pop-under age when you visit a site and pop all this random crap up? It still happens nowadays. And it happens more now too on mobile, you see. You go to some crappy site that you can't link to to on Facebook and it's like popping up all kinds of stuff. I made this up. No access to the browser's history so you can't just query the browser and say, hey, what pages did the user visit, right? Why is this a good thing? Now privacy, right? Well, you know, if I go to attacker.com there's no reason that they should know about all the previous sites that I've ever visited. So lots of other sandboxing mechanisms that try to restrict what this code can actually do. And the exact details that depend on the browser, they'll kind of change slightly. There's no standard here. This is the way we do JavaScript security. But there is one thing that is standard and when it comes to web security, the same origin policy is 100% the most important thing. So one thing you absolutely need to learn from this class is what is the same origin policy? So the idea is, this is a standard JavaScript security policy. It has to deal with what we talked about of why can't the attacker.com's JavaScript access objects that are in Facebook.com script or Facebook.com's domain. Why can't it access the DOM elements there? If I put both of them in a frame then next to each other, right? Can they talk to each other? Can they manipulate each other? So, every frame or tab in your browser is associated with the domain, right? You got a URI, so there's a domain. And so, a domain here is what we do is the same origin policy domain. So it's not necessarily a domain name. The domain name factors in, but it's called a domain. The idea is this domain is determined by this tuple of protocol, port, and a protocol, domain, and port. I'll probably remove the domain. I think it was a little confusing here. From where the frame content was downloaded. And the same origin policy on the browser enforces the fact that code that's downloaded from one same origin domain can't talk to or access anything else in a different same origin domain. And this is the tuple that it uses to decide are they the same. So this means that even if you go, if you have some JavaScript running from Facebook.com on HTTP, it actually can't talk to or access anything from Facebook.com to HTTPS. So this actually seems incorrectly limiting. So I just already said that advertisements work by executing JavaScript code to go fetch things and then inject it into the downloader page. The same thing with Google Analytics. So when you visit probably 80% of websites, you're getting tracked by Google and that's happening through some JavaScript code that's executing on every page that they're visiting. And so the question is, we've seen, okay, when we include a strip tag, we can have inline JavaScript code that's very clear that that JavaScript is part of that page. It was sent literally from this same origin policy domain. It must be the same, it must be the right code. Now the question is how do we handle external JavaScript? So what is an external JavaScript? Yeah, so it doesn't necessarily have to be some other domain, but it's not inlining the page. So in the HTML page, you see a start strip tag, you see a source, that's some URI, and the browser will go and fetch that JavaScript code and execute it. Now this is the way around the same origin policy. So that code that you go and execute, even if it's from attacker.com, is technically part of the same origin of that page. So if you go to Facebook.com and there's a strip tag there that has the source of attacker.com, that code will be downloaded, executed, and run in the context of that same origin. Which makes sense because this is how we can do cool things like do web widgets and all kinds of cool stuff. We can get code for use benefits. We can use content distribution networks to distribute JavaScript code so we don't have to keep downloading the same files over and over again. There's a lot of benefits here. So yeah, so if you go to avenuebay.com, the same origin, the same origin policy domain, will be HTTP, avenuebay.com, and port 80. Why do we know it's port 80? Default port and HTTP, yes, perfect. So this would be an external script including exactly from that website. So I'm calling in jQuery, a minified version of jQuery that's hosted on Google's APIs but that version of jQuery executes in my origin. Any questions on this? Very important. It's actually a very simple concept but it forms the basis of all browser-based web security. An option in the browsers which allows us to do a cross-origin request. Yes. So is that safe or why don't we have the notion? It depends. It gets into more of the specifics of the enforcement of the same origin policy. So part of how we looked at Ajax and we looked at how we could make asynchronous requests from JavaScript. So it was decided pretty early that you don't want to make arbitrary requests to arbitrary domains because then you could enable scanning and all kinds of random stuff from JavaScript. So by default you can only make an Ajax request to somebody that's in your same origin policy. But that limits the ability of you to hit external APIs from your JavaScript code. So there's a thing called cores. Just cross-origin request something. Standard variable, sounds good. Which then the server that you're trying to talk to explicitly allows Ajax requests. So it has a policy that it says, yes, I will accept these requests. And that was to get around this issue basically. So same origin policy, very important. So we've seen so far that we can store a web application, can store information on the client's browser. We can store cookies, we can store URLs, we can store information in forms. We can use plugins. We can use local storage. So any local storage is exactly the same. Yeah, it's just storage inside the browser. What makes it different than cookies? It's not sent with every session. Yes, so it's not sent on every HTTP request. It's only JavaScript accessible and you get a bigger chunk of the hard drive. You can ask for local storage, I don't know what the limits are, but you can ask for a chunk of local storage which then allows you to write offline web applications. So I think there used to be a way to run Gmail in offline mode and it's because it uses local storage to cache a bunch of your emails locally so you can operate offline, cool. So now we get to our first, so as I've been partnering on and enough that as we were talking about all of these different ways you can store information, you all pointed out all of the security problems with this. So we're gonna look at this and this is really the first type of vulnerability that we're gonna look at in web security. So fundamentally, tampering with client-side information is an entire class of vulnerabilities because as we know, nothing prevents us from doing that. And it comes back to the core protocols. The browser just makes HTTP requests, gets an HTTP response with HTML, parses it, displays it, and then makes for the request. So everything that the browser can make as an request, we as attackers can make. So tampering, so this is an important distinction about what is a vulnerability. So if I go to Facebook.com, it's gonna send you a bunch of cookies, right? And when I log in, now those cookies are established with my session. So is it a vulnerability that I can download a cookie manager application and edit the cookies to Facebook.com? You're the first one to shave your head. Because the server's also verified a cookie information. Yes, so just the fact that we can tamper it, right? We can, fundamentally, we can tamper everything, right? So simply changing your cookies is not a vulnerability. The question is what does the server do when it receives that request, right? If I can easily change my cookies to log into the website as you, that would definitely be a vulnerability. There's a cookie called user ID and I can change it from one to two to log in as user ID two. That would be a problem. Or if there's a cookie called admin and I can change it from zero to one, that would also be a huge problem. So the question then is, how does the server-side code respond to our tampering? This is effectively what determines it to be a vulnerability. Not only that, and actually, as we've always talked about, right? Maybe I can change the language in the cookie. From English to, I don't know, German. Yes, I can tamper with that cookie, but that does not undermine the security of the application, right? So we always need to be thinking, okay, it's some kind of tampering with client-side information if the server-side code allows us to tamper it and it actually comprises the security of the application, then there's an actual vulnerability here. So this gets into what we talked about in the beginning of the semester, about what actually constitutes a vulnerability. It depends on our actions compromising the security of the application. So some cool things we can do, hidden form fields. So when we looked at HTML, we saw that form fields, you could put the hidden tag of the type attribute on an input tag, and it will not be shown in the browser at that point. So that field will be hidden from the user. So why is that useful? It seems stupid. Why would you want an input field? It's literally called an input field, and if you don't show it to the user, how are they going to give you input? This element that you want to display. Okay, so you may want to use it to store information. If you're actually in JavaScript, you can kind of do that anyways, yeah? I'm just gonna go state information. Yeah, so maybe there's some state information, maybe you're trying, because you know when they click submit, that whatever's in the value attribute of that input tag will be submitted to the server wherever this form request goes, so. Yeah, the user request. Yeah, so if you use JavaScript and then put these hidden tags in there, yeah, that's cool. Okay, yeah. You might want to show that input in some future response to the user's action. So maybe I'm storing something that I'm gonna make another request, and then it's gonna send me something else, and so we're using this to kind of pass data along the application. Yeah, these are all legitimate reasons why people do this. CAPTCHAs also are a good way of doing this, so one form of CAPTCHA to detect bots, so bots that try to crawl your website will randomly fill out form elements, and if they're stupid and fill out hidden forms, you would know that a user would not be changing that field, so if you detect any change in that field, you'd say this is a bot and not a human. C-server protection, which we'll get into later. The problem really, so this is not, putting data in a hidden form field is not the vulnerability, right? The problem is when that server-side code blindly trusts whatever was in that hidden form field, and if that affects the security of the application. So, for instance, and I believe actually in, let's see, I think there's a case at the Apple, what's the big Apple event, WWDC, what do I got? Anybody know? Yeah, I think so, right? Yeah, I think it was in 2014 or 2013 they had in their event registration page, they put the price as a hidden field on the form. So you could literally go register, change the price to zero, submit, and you would pay nothing for your tickets. So this is something that happens, and it's not a completely unknown thing. So I have here a super simple example of some checkout form. So we can see here that I'm trying to buy a laptop for $1,000 and a monitor for $1,500. Do I total the prices there? I have a credit card number here, and so I'm gonna purchase it. And so if we look at the HTML of this page, right? So we can do this in two ways, we can set up a proxy like Burp to intercept all the traffic between us. I talked about Burp, right? Yeah, okay. Instead of a proxy like Burp that's gonna record all the traffic that's going between us and the server, so we can see the HTML page, we can right click on the page and say use source and we can look at it this way. So the page looks like this, the page has a body, a checkout, whatever it lists, and then it has a form field, right? Which can make sense. So it's got a purchase button, it seems counterintuitive, right? All there is is a button. So why create a form? Yeah, so the application wants the next step of this purchase operation to be an HTTP post, and so they know if they get a post that we've actually clicked this button on this form. And we know from the spec it should be a post because hopefully purchasing something is a state changing operation, right? Okay, so the form field has this action purchase, it has a method post, it has a hidden input, so it has an input type of submit, it has this purchase button, and it has three hidden fields. So what are these? So you're testing this website, you pull this up, what do you think you are? Order ID, yeah that would be a good guess for OID. Right, it's owner ID. Could be owner ID, it could be us, our user ID, it could be the order's ID. How could we check and verify? To do. Change what? Well, no, I'm not that, I mean, we can do that, but. Do you know another card? We can try, yeah, we can try deleting this and creating a new order and seeing if that number changes, right? So this number changes for every purchase we're about to make, and then we probably have an order ID. If it stays constant, or we can log in with two different users to the site and check the value to see if it's gonna be, well no, that doesn't tell us, that should be different in both cases anyways, right? Because the order's ID will be different and the user ID will be different. And okay, cool, the second one? Price, yes. What do you think that is? The price, what about the last one? Currency. So, what do you wanna try and what are you expecting the outcome to be? Let's take the first form field. So do you wanna change that and if so, why and what are you looking for? I changed the order ID, it should not accept it because in the form was generated the order ID was something else. Maybe the order doesn't exist on the server and it should not accept it. What could be a potential vulnerability for that, yeah? Well, if I was gonna go with it, it's an order of charts and else. Yeah, that would be fine. It's an order, maybe you can chart somebody else, although maybe it'll also shift to them, so. No. Actually, that happened to a friend of mine. He's a professor at NC State. He told me that he got an email from Apple that his laptop was on its way and he went and checked and it was a laptop that was purchased with his credit card but sent to his house. So we were still not sure what the actual scam was there and he caught it in time and they canceled it. We were thinking maybe somebody would wait outside his house to like steal the package or something. I think you've got a lot of effort to go to when you should just like ship it to somebody else. Yeah? Currency. Currency, why do you want to change currency? Just because all prices are like in high enough. Yeah. What's the conversion rate, I actually don't know. 675 to 1. 65 to 1? That's pretty good. You'd want to make sure you do it carefully, right? You wouldn't want to change it to like the end or something, which is the other way, right? Yeah. Yeah, if we could make it zero, what else would we want to try as a price? Negative. Negative, what do you hope would happen there? Negative. Like refund your credit card? Yeah. Pretty sweet. Cool. So these are all the things we just talked about and these are all the things you should be doing when you see these types of behavior, right? Because this is what makes web application testing so much more difficult in my mind than in binary analysis. You can have incredibly complicated binaries, but you have the code there that you can study, right? Here, you have absolutely no idea what the source code of this web application is and what it's doing. So you have to be the one to generate hypotheses about okay, what input should I feed this web application and what am I expecting in response? So yeah, so we try to think of malicious values, right? And it's important to think about this like a tester testing. I mean, you are fundamentally a tester. You're just doing security testing, right? So that's what we talked about. We try to test the boundaries, right? Let's try price as something negative, right? But if it doesn't accept negative, we don't stop testing price because you could feasibly imagine a scenario where they check for negative, but they don't check for zero. Or they don't check for, maybe they check for zero or negative, but they're not checking at the exact same price. So maybe you can drop the price, or maybe you can do .01 and see what happens, right? So these are all the tests that you wanna do to prove to yourself that it actually is working correctly or that it actually is a vulnerability. And you always have to have that test in your mind before you launch this, right? You just, the worst thing to do is just throw a bunch of values in there and try to test different things. Because then you don't know how to interpret the results. You have to look at the results and be able to say, yes, my hypothesis was correct or no, my hypothesis was in, was it was either true or false, your hypothesis, not incorrect or correct. Cool. So, oh, this isn't, okay, that's pretty good. I have a macro for this one. Don't hold up. So it's better if it's not all the way at once. Okay, so, okay, now we need things to work out. Okay, so, we can use curl, we can use a browser to test this, we can use, we can use burp. I like using curl if you can. It's easy, it's a manual thing, I can change things. Also, you can kind of just use whatever I think is appropriate at the time. So here, we can use curl and we can make the standard. So here, what do we change? We change, I believe the, oh, there we go. So the order ID, 59.29, 2,500 USD. So we have 5,929 price currency. I make this request and I get this, I don't know who you are, go away, why is that? I'm passing all the hidden fields. Oh, I didn't get the price and the currency. That's the cookies. I'm not including any cookies in this request. You can also use the dash V option of curl, which is nice when you're doing this, that will give you the output of basically the HTTP request and response. So you can see exactly what's going on. So we're not getting cookies, so it must be some kind of session issue. So it's good, right? This is a good thing that we need in cookies. So we get that and then we can use the curl dash V command to specify cookies on the curl command line. So we see that the cookie was this PHP session ID, which is another interesting thing that we wanted to realize that, hey, this is PHP code, right? We've been using this PHP session ID. So that's it, maybe, no. Who knows, you're just trying to gather as much information as possible in the future. So we do this and then we say purchase successful, and your final order total is 2,500 USD charged to your credit card. Ooh, that's a little weird. So what should we do if we were testing this for real? Yes, fake credit card. Huh? Fake credit card. Yeah, use a fake credit card, hopefully they're checking for that. Say again? Just turn it. Yeah, but that may not be, we need to know what the correct responses when we're purchasing things right now. You sold credit cards. No. Don't do that. Don't use sold credit cards. Don't get sold credit cards. Don't use a possession of sold credit cards. Try to buy something cheaper. Try to buy something cheaper, yes. I don't believe it exists. What else, yeah? There are fake credit cards that you can set up where the amount is actually never charged, but it's a valid or... Yes, so you can actually work. So you work with the company that you're trying to test, right? And usually they can provide this for you, so usually I did some pen testing for a credit card processing company, so they gave us credit cards that specifically wouldn't be charged, but would still go through the system and go through everything they were gonna do. So yeah, these are all good strategies except don't use sold credit cards. What? Okay, so we made a successful order. Great. We always need to go and cancel the order depending on how much we trust the thing. But yeah, don't use your credit card for this. So we talked about OID, so let's track OID of one, right? It could be owner, it could be order. What do we think? What are we looking for? What do we want to happen in here? Don't switch. What's this one? How does all of this handling this change? Yeah, it's not like a hypothesis. That's like what are you gonna look for, right? A hypothesis would be I think there's a vulnerability in that if I change this order ID, it's gonna charge somebody else's credit card, right? And so how would I know if that was true or not? Difference in output. Difference in output. There needs to be some kind of difference in output or in an application. So maybe it'll say that I charged a different credit card that would be sweet. If it doesn't do that, it'll probably throw some air and then maybe we can look at it to try to create an idea of what it's actually doing, right? So it's a fail, not your order. Look at this. I guess one thing we didn't talk about. Should we try testing changing the PHP session ID? I'm just curious. Yeah, it's one of these things like maybe once just to see what it does, but if they're using PHP and they're using PHP session variables, you could look up and see are there any known vulnerabilities in PHP session variables, maybe they're using an old version of PHP that has some cryptographic weakness. You could make multiple sessions to get some of these session IDs and then there's programs you can run to compare the entropy between them so you can see if it's random in that sense. But yeah, this would be a place I would not look first. All right, this would be if you can't find anything and you start trying to dig a little bit more deeper into all these layers. Okay, price. Let's start messing with the price. So we can set the price to be one. We'll try one first. I think that's good. It's more than zero. It's not zero. It's not negative. And we're also hoping that it's going to tell us, hey, Verity, you purchased this, right? And we need an important thing. So there's a couple of important things here, right? So why when I tested this one, why did I leave price and currency the same? Yeah, change the map. So you knew what changed like, you only changing one thing. Yeah, so this is why I speak about this in scientific terms, right? I'm changing only one variable, right? If I do some new requests and change the order ID, price and currency, if it fails, I don't know why. So you always want to do these minor one tweaks to see how the application responds. Okay, so price, was that price to one? And it was like, eh, fail, not the correct price. Yeah, it was so close. It was a little bit secure, but pretty good. Also, I thought about price. That's pretty good. Okay, so currency. So we can try currency in some other currency. This is, I can't remember, it's Hungarian. Starts with an app. It's either a frame source or nets or something like that, I actually don't know. And then, let's say, purchase successful. Your final order total is 2,500 Hungarian notes charged to your credit card, right? So then at this point we say, oh man, did we actually use the right currency when we wanted to do this? And we can see that yes, when I did this, the rich here was really good. So this is way better than my 71. Yeah, so that's gonna go up to $9. Pretty good price for a TV or for a computer in a long time. What's that? Currency might just change out the output, right? It's true, we have to look at whatever credit card we're using to see what it actually charged, yes. The session ID also used to identify the liquid state. So if we use another session, and if the session never expires on the server, we can potentially use someone else's session to make the purchase. But how do we get that session? For testing, we can create multiple sessions and use the older sessions to test them. Wouldn't that be a good test? So we use multiple browsers. So you can do it, why can't you do that test? It's a good question, but I'm gonna dig in. Why can't you perform that test? Because you know your session values. Because you know your session values, because you created them. The question is, can you log in as me? Is it the request in-tester? If you can give the request and steal the session, could it be then, yes, you can. Yeah, so this was actually, there's a program called Firesheet that was written, well, gosh, I don't know. Basically, Facebook used to be all HTTP, except for the HTTP as logging page. And so every request you made to Facebook would leave your session cookie over clear text. And so what people did is they developed this tool called Firesheet, which would scan your local area network looking for anybody's Facebook credentials and then had an awesome GUI that you just clicked to log in as this person and see all their Facebook stuff. After that thing on Facebook, I got that fixed really quickly. I'll put more below today's like clear text, like session ID information. Depends on the context. I'd say very bad. If it was my ASU doing it, and I'm on an unencrypted, like, so the ASU network is encrypted, right? Now I go to a coffee shop and then I log into my ASU. Now literally any student that's there that sees that package is gonna take my session key, my session cookie and log in as me. Because remember, the server only can identify you from that session information, right? Oftentimes they can add in other things like check your IP address that you're coming from, but that actually would be incredibly annoying because it would mean whenever you switch networks you'd be logged out of every single website you were logged into. So oftentimes they don't, many times they don't do that unless it's like a bank level security. So yeah, it's a huge problem. So this is why there was that setting on cookies that the server could say, I think it's strict only or only strict or I don't know exactly, maybe it's just strict. This means that it only sends it over a GDS and it will not send that cookie over a GDS because this is such a core problem to all. Okay, hey, look at this, cookies. So when we see if we can manipulate and inform fields, right, that's one super fun thing to play with. Other things are cookies. So cookies obviously can be used to store state and we know that basically the server is requesting that the client store a little bit of information on browser. Cookie can be anything, right? And we just saw we can manipulate cookies by a curl, right? We can just change that cookie value to be whatever we want. So fundamentally anything stored in cookies is fair game and can be manipulated. But it is important for you to look at it to see, well, is it, just because it looks like gibberish doesn't actually mean that it is gibberish, right? So it may not be cryptographically secure or valid and there's actually a lot of different ways that people can mess up the way they do crypto which allows you to break them using a session operation because it's a key problem. So the other way, URL parameters, right? So if any of the inputs to the web application, the application is trusting that this information is not tampered with, it's getting it from an query parameter. The exact same thing is an inform field, right? If they click you to a link and that link maybe includes your user ID, you would want to try changing that user ID to see what that gives you, to see what else that allows you to access. The referrer, so even, so I don't think we talked about this, do we see it go straight? So what's one thing that's weird about this title? Yes, referrer is misspelled. Is it a typo on mine or a typo on the HGNP spec? Which seems more likely. You think something wrong with me, right? All you guys get back here and like, I'm gonna have to talk to this and try it myself. But yeah, just like you think there's a bug in your code first before there's a bug in your compiler, same thing here. Except that the spec actually misspelled referrer and nobody caught it. Like there's four or five authors there. Nobody caught it and now it's literally a part of the standard and will never be changed. So it's actually probably more likely that English would change first before the spec changes. So the idea behind refer, referrer, and editor, it's also weird to say. So this is probably not super important. Well, it's actually interesting. All right, I'll read it. All right, so the referrer requests header field. So it comes, if it's a request header, it comes from where? The client. It's a lot of, a lot of the client can discussify for the server to benefit the address URI of the resource for which the request URI was obtained. This allows the server to generate this blacklist to resources for interest, logging, optimize caching, all of that. It also allows obsolete or miss type links to each trace for maintenance. The referrer field must not be sent if the request URI was obtained from a source that does not have its own URI, such as input from the user keyboard. So it's kind of a weird thing. So the idea is when you type in the URI, I'll let your address bar hit enter. No referrer header. But now any link that you click on that page, when you make the new request to that new host, you will send a referrer header that has the URI of where you just came from. So this is actually one of the major ways that websites use to track you as you're browsing their site. Because they can see that you went to the home page and you click to this thing and then to this thing and then to this other thing and so on and so forth. Exactly, so it's a header field that comes from the client. It should not be trusted, right? So if the web application is enforcing some kind of authorization and say, hey, only if you first go to this page can you go to this other page and it uses the referrer header to check that, then there's something that you can definitely target. It's also, there's also an interesting thing about HTTPS versus the HTTB. When you're visiting an HTTPS website, if somebody's looking at your internet traffic, what do they know about what you're visiting? What is that? Domain. Domain, they know the domain that you're going to because you're making a TCP connection to the server, right? So they know the server that you're going to, they also know you have to negotiate with the server, I think, before the encryption. They'll probably know the host name, let's just say they know the host name, right? But do they know exactly what URL you're visiting? Where's that information stored? In the HTTP header, in the HTTPS, the TLS part encrypts everything so that HTTP request is all encrypted. So somebody listening to your traffic knows, let's say they're going to Google.com but they don't know what you're searching for. Now, let's say you search something on Google and on Google the query, the URI updates with your query parameter when you typed in. Now, what happens when you click on one of those links to an HTTP site? Yeah, the referrer would be the URI which was the HTTPS page that you were visiting. So this would be a huge leak of private information, right? Because somebody watching could know exactly what page you were on when you clicked out of that link. So it's why by default, the browsers disallow that. So if you go HTTPS to HTTP, you have no referrer link to link you back. All right, so some sites will use the referrer to control access and it is untrusted and can be manipulated. And therefore, if you're using this to assume that the user visits your website in a proper order, it's fundamentally a mistake. And you can use the dash H, capital H option of curl to set arbitrary headers. Okay, this one's a super interesting one. So we're still on the topic of client-side tampering. So as we talked about, when we talked about forms, we talked about well, when we have forms, we need to do some validation of the forms. And JavaScript is great because you can throw some JavaScript code into the client that can do this validation for us and not have all these crazy round trips to and from the server. So developer can specify HTML5 restrictions and validations on form in, but it's actually super cool. Now you don't even need JavaScript to do this. You need attributes on input fields. So you can have the required attribute, which means the browser will ensure that the things are required. You have a type equals email, you have your types. So the browser will specify that it actually corresponds to this. You can even use a regex pattern to specify the pattern you wanted to match. And you can write custom validation code using JavaScript. All of this can be bypassed, right? Fundamentally, nothing ensures that when you get an HTTP request that the client checked all of these things. So these can all be bypassed. And it's actually really cool research that what they did, they developed an automated tool to get past this form, the input restrictions and the validation. So what they would do is they would statically look at the JavaScript code that was being executed when you click submit on a form. Then they would look and for every path through the code that would return false, which means it was not valid according to the JavaScript. They would use constraint solving to generate an input that triggered that false condition. Then they would feed that input to the server to see what it did, to see if they were able to get around the bypass. So basically, they used the JavaScript code itself in order to generate malicious inputs that would fail that validation and send to the server. Really cool work. Okay, so now we need to get into more things. We're gonna talk about authentication. So we're gonna talk about some, define some concepts before we continue and we're gonna talk about attacks against these things. So there's two things I think, I can still slide so we'll see. Authentication, so what is authentication? It's credentials. What's authentication? Checking who you are, who you are. Yeah, checking to see who you are, right? Who are you? Who you say you are. So that would be like checking your student ID to make sure that you're the person that you say you are, right? And so if you break this, if you break the authentication, it would mean that you can impersonate another user, right? Depending on how I do that. What is authorization? Are you allowed to do something, right? So as I already know who you are, are you authorized to do this action? Like for instance, on the submission server, there's a whole hidden part of that website that none of you see, which is all the grading stuff. And I hope so, except for you, you're okay. So that only the admins can see this grading part when you can go in and do all the grading and put all the comments in on the website. Whereas you should never be able to see that because you're not supposed to see any other user's pages, right? Or anybody else's homework submissions. So now you can, wah, got that all into your heads. Good luck. So authorization tries to answer the question, what is the user allowed to do? And there's a whole concept about access control and role-based access control and attribute-based access control. So you can have different roles, like admin, guest, regular user. So this actually exists even on the submission side, right? So we have admins, we have more privilege, we have you all as the regular users. You can submit homework assignments. And then we have a guest. If we don't know who you are, you just get redirected to the whole page. And so if you can break authorization, you can perform actions that you're not supposed to do, right? And this is kind of a fine distinction between the two because if I can break your authentication and log in as you, I can do things that I shouldn't be able to do, right? But fundamentally that means there's something broken in the authentication mechanism, right? Whereas if the site allows meeting access to the admin, for that admin page, that would be a flaw in the authorization. So it means that I'm being allowed to do things I should not be allowed to do. Is that how it sounds? Questions on this? Super intertwined. Oh, see? Look at it. Actually, another stuff. So how can we break authentication so well one way to do it would be something we talked about, right? And you could break and sniff using all the network attacks, right? So this is actually why even though it takes a long time in the beginning to do network attacks, I still don't want to get rid of it because it's so important to both the binary security and the web security parts here. Because I can eavesdrop on either your credentials, your login, right? When I submit a form post for field, what happens with the username password that I put there? Yes, it's sent as the payload of the HTTP request to the server. And I'm using just standard HTTP with all of that is sent in the clear text. So everyone on my local network could potentially be accessing that. Which is why it's so important that HTTPS is used for your login pages. Some other ways. Yeah, maybe we can guess, right? So we can just brute force in trying to guess other people's usernames and passwords. Maybe we can use, there's been a lot of password data breaches. And so maybe we can build up some cool model of what likely passwords are for users, right? How do I guess the usernames? Email, most of the time it's email. Yeah, you can just crawl for emails. Emails are not a problem, right? So getting those usernames, if it's an actual username that's not their email, it may be slightly more difficult, but fundamentally not really. What other ways? We'll just talk all the possibilities. Yeah, we'll get it there. But without doing anything in the back. Peace, but up until, it seems like very recently, password reset things would tell you if the email that you entered wasn't email that they had instead of just saying, if this exists, then we sent you an email. Yes, so that's actually, there's a fundamental problem, a fundamental trade-off between usability and security with all, even the login forms. So maybe you've gone to a login form, where you type in your username and password, and it says the username or password you entered is incorrect or whatever. Either the password's incorrect or the user doesn't exist. And it always gives you this method, no message no matter which one. Now you can't tell from the outside which is which. But some sites, because it's better, right? They actually want to help you out to say, yeah, you actually entered your email correctly, because now we all have like 10 emails. So you entered your email correctly with the password of visiting correct. Now ask them nicely. Do you have any more concrete thoughts on that? I like the direction. Yeah, like a phishing attack, or you pretend to be someone that's in vain? Yeah, maybe I can register, I'm trying to think of a good example. I don't know. Something, take Facebook and change a letter, lace book, I don't know what it is, weird. If I send you a link to this and say, I send you an email and I say, hey, your Facebook account has been hacked. You need to verify that you're still on this account. Click this link. When you click this link, and this takes you to an HTML page that looks exactly like Facebook's webpage. The only thing that's different is the URI is slightly different, but why would you notice that? You're a busy person. You can say that's exactly why if you do full screen now with HTML5 on YouTube or anything, it says, are you sure you wanna be in full screen because otherwise you can actually make the webpage identical to the full screen page? That's actually a huge problem in local browsers now. If you click a link on your phone, usually due to the screen real estate, the bar is super tiny. It takes up a lot of the room, so the natural inclination is to get rid of it, which has horrible privacy and security implications. Social engineering? So you basically tend to be somewhat called company. That would be a good way to ask you nicely. So call them and say, hey, this is Facebook. We see that you have problems logging in or maybe this way of phrasing. You could probably say like, we're running a fake news detection thing. You can be a great person at detecting this. We need you to use the main passwords so that you can verify that you're actually, we can say you are for security purposes. You can get them that, yeah, that'd be good, yeah. Physical eavesdropping, like in this classroom, sitting here and someone watching. Okay, yeah, yeah, shoulder surfing is what we usually call that. So yeah, watching somebody log in with eavesdropping, it's actually a whole line of research that they've shown that using a camera and videotaping somebody and see what password they're typing in. That was the kind of original research. There's been all kinds of stuff of doing, but you can figure out what they're typing from listening only to the sound that they're making to your phones now are, you know, it's actually kind of crazy when you type in your password on your phone. Each letter that you're typing pops up really large. So you don't even need a good camera to actually be able to steal that. There's, yeah, all kinds of other attacks. I think there's even a recent work that used the, not even an app installed on your phone, a JavaScript running on a page in your mobile browser has access to the gyroscope readings. And so, and for whatever reason, this stuff runs in the background. So you would have, you're visiting a site and then you go to log into your phone and they can figure out your passcode or your password based on the gyroscope vibrations. Pretty insane stuff, yeah. If the server is not checking whether you're authenticating details for a particular URL, you can directly guess the URL and get that. Yes, I'd say that falls under the authorization category because that's more about checking if you're a guest or not. Yeah, that's why I said it's a really fine distinction. Yes, yes. And I was thinking of something, I think that's what I'm saying. The station checks. Did you say checking the thing or the thing? Yeah, whatever, probably not important. All right, let's see what's going on. So we can maybe bypass it. Oh, yes, this is what it was. That's right, so there was actually a bug. Dropbox had a bug for I think three hours if you logged in and just put any password in would log you in. So the authorization mechanism was fundamentally broken. And you think how many times do you do that? Never, right? You never intentionally put in the wrong password in a website just to see what it does, right? So one person found this and like alert and drop box and they fixed it very quickly. And because they have good logging in, they were able to go back and identify every customer who somebody else potentially logged in with the wrong password to notify them and so they were able to log in and stuff like that. But yeah, it's just a simple code change to the login thing that made it all the way through testing because you didn't have any test cases that tested logging in as a wrong password, right? We never do that. Eavesdropping, we talked about, is incredibly simple. Using password sent as part of the HTTP basic authentication exchange that we looked at. If it's submitted for a form, if it's a cookie, you are a parameter, all of these things can be easily eavesdropped on and stolen. All right, let's just look at your black pin. Group forcing. So if an authenticator is in a limited domain like let's say four digit pin, you can just trivially brute force that. What does that depend on though? Yeah, it depends on the functionality of the website. Does it lock you out after a certain number of attempts? Does it intentionally have a sleep on the server or something that waits a second before returning your results? All of these things can affect if you can do this. But even if you can, so the way you get around this is usually there'll be a per account attempt lock. So what I do if it's usernames or whatever, I can figure out a bunch of usernames and then I try to pin 0, 0, 0 across every single username. Somebody's going to have that. Somebody's also going to have one, two, three, four. So these are the things I would do is test this across everyone. Like maybe it's difficult in that case to break into a specific account, but if I can break into a cache generally, I can use this. You can also let's say use a network series of computers to do this group forcing. Let's say you're renting out Amazon, so it's not illegal. Okay, so if they're chosen in some non-random way, so if we have sequential session IDs, the state's going to modify the cookie values. If the session IDs, if you see them as one, two, three, four, five, super easy to break. User-specified passwords are horrible in so I've had to meet people, right? I mean, it's the, what's the thing about? It's the thing about democracy, it's like the worst form of government except for all the other ones we've tried. So it's the same with passwords, like user-chosen passwords are horrible, but there's literally no alternative, so we keep using them, right? And we know that users choose that in half a word, so that's just a fact. All right, so we may be able to try to bypass authentication. So yeah, so this bypass authentication kind of a subset is what was mentioned over here about forceful browsing. So the idea is, and this is actually something that's incredibly interesting about the web. So you as a web developer, you write an application, right? When somebody makes a request to your page, what you send them back are the links on the page that they can visit, right? And oftentimes you customize the links they can visit so that they have a certain path throughout the application. It really builds a graph that you think about, right? And that graph is different for all of the users and roles on your system. And as a web developer, it's very natural to assume that the user must click the links in this order that I give them, right? Like of course they can't visit the order page because they haven't logged in yet, because my app only shows them the order page after they've logged in. But we know that the web is built on HTTP, which is a stateless protocol, which means we can make any request at any time. And so web applications actually have to be very vigilant about this, and they have to check every single place to make sure that you can't, this is what's called forceful browsing. So basically, hey, let's just browse to the comment, to the page. Want to start it off? Yeah, like the cart page or the secrets page, or the admin console. Meet the password recovery feature, so we said. So maybe the key that's generated on this password reset is bad or weak, or maybe we can influence it in some way. Session fixation is a way it's a, on some web applications, the developers make the mistake of setting your session value to be whatever you pass in as a parameter. So you can use this to force somebody, so basically, rather than generating a random value for each user, basically I send you a link that you click on, then I say your session is one, two, three, four, five, or it could be a random value, it doesn't matter. Then when you make a request to that website, their bug forces their session value to be that value, and now I can log in with that value because I know your session ID. So basically it's rather than me eavesdropping and learning about your session, I force you to have a session of my choosing. So the ID, can we fix value? Yeah, okay, cool. So authorization attacks, so there's all types of ways that we can try to access and manipulate and break the authorization of the server. So just like, and it's actually kind of funny when you think about it, right? You think that these vulnerabilities we talked about in binaries were older vulnerabilities, they should have been known for a long time, right? The dot dot attack on applications, right? It should be like, okay, that should never be a problem. Of course, that's not true. So on web applications, they still open files, they still read things, right? And oftentimes they'll read input from the user. So if they're reading a file name that's specified in a query parameter or a form, you can change that and try to access different files outside of the directory. So you can use dot dot to get outside of the directory to try to read different files. So something like this. So there's an app that I was doing like a show.phb and had some files, so it would, the first thing I would try would be something like this to try to get evc password file. Or actually, what I'd also try is putting show.phb in there. What would that get me? Yeah, give me the source code of the application, hopefully, and if it does, then great, I can stop guessing about what this app does and I can start actually using the code to do that. Sometimes you may have to encode, so you may have to use your island coding to get around any web application firewall that's looking for these dot dot attacks. Forcible browsing, like we said, so this is why it fits on both authorization and authentication. So for instance, I'll tell you a forcible browsing attack that we found on this credit card processing company was they were using, you would get monthly statements, so you'd go to a page of the report and links to all your monthly statements and on the monthly statement, there was just an ID in the URL. I can't remember, I think it was a parameter that I don't know if it was just ID or what, but it was basically a report ID and after viewing a couple, you're like, okay, these are probably sequential. So we changed that parameter and tried to fuzz backwards and forwards and then we found out that, yeah, we can see other company's credit card reports and so then we wrote a crawler to get all of them and then we looked at all this data and they were leaking and then because of this forcible browsing thing, right, so we could access, there was poor authorization checks on there. Similar things happen, I don't, I still don't think they, I think I've mentioned this before, I don't think they've changed it on Facebook where you can right click on an image and say view image source and then that gives you a link that you can then forward to anyone and anyone can go see that link, right, when really you want that authorization check because Facebook, it should be the case that only the people you allowed to see your pictures can actually see that. So this would be another forcible browsing issue. Obviously Facebook doesn't think that's a problem, right? So this is actually a common, very common, especially on like medium-sized web applications, it's automatic directory listing, so a patching by default, if you go to a directory that exists, if there's no either index.html, index.php or some kind of index file, it will automatically show you all of the files that are in that directory. So that can actually leak information that shouldn't be accessible. So parameter regulation, this is similar to the forceful browsing type thing. So this is what I was talking about, changing the parameter's value to access different resources. So this would be one example for like a medical type application. So getting another user's profile. Okay, so parameter creation. So this actually gets back to the php feature of the registered globals functionality. So php and some languages, depending on the specifics, they will take and create a variable inside the code called admin. So for instance, so we're talking about registered globals, right? Registered globals looks at all the user, the name, value, pairs and the query parameter that will create a variable with that name. And so let's say we have feedback page that says if name and comment, file, fopen, user, name and comment. Where are we going with this? Are we gonna do this? Yeah, we're gonna do this, right? Okay, yeah, we're gonna do it. Okay, here's an actual example. So we have php code that's checking, hey, if the get password is this, so we're already doing something horrible because we're sending a password as a get parameter, right? So we should not be doing this, but whatever. Let's look at other things. But it's some secret, unguessable, random thing that nobody's ever gonna guess, right? Except for the admin. So the admin has this, they can access everything. And then if that's true, then we set the admin variable to be true. And then we say if you're admin, we should show see your admin stuff. So what's the problem here? It looks right, right? Yeah. Could you bring the course with password parameter? No, it's really random. You may not even know a password parameter exists. Could you set it in the URL? So what if we set what in the URL? We could set admin in the URL. So if we set admin equals one or true in the URL, then php will automatically create an admin variable that's true. And so what's gonna happen? Let's go through an execute. So we already created before this, essentially php has created admin equals one. And then now in this first if condition, we say if get password is equal to that, is it going to be? No, we didn't send that. So we skipped that branch. Now we go to the next condition, we say is admin true? Yes, now we do our super secret admin stuff. Things like that, yeah. And you may think, well nobody ever does this, right? Who would code in this weird way not sending admin variable? This also happens in, so with php, we talked about including other scripts. And if you include a php script, you can actually execute that php script directly. Unless it has the proper, you can execute that php script directly. So that script that it's being included is assuming it's running in this environment which has all these global variables already defined. So this is often times where you can find this and you can inject parameters into that function. All right, so there can also be issues with the server itself. So when we talked about the server can have problems. Often, well, sometimes I have to keep changing my language depending on how far along we go. But it actually does happen a lot that you have FTP servers running on the same host as a web server. And so you can actually use the FTP server to try to upload content into the web server. So you can try uploading a php script onto the server. And this is actually a super cool one, this happens a lot. If the website actually allows you to upload files and you can, usually you have to also be able to specify the file name and the file type, you can upload a file that's called something.php and the content of that file can be php code and then you can try directly accessing that file and see if your php code runs. This is actually a huge problem that happens a lot more often than you'd think. There's actually even crazy ways to get around this. So even, I've seen php shells that, because we know that the only thing that php cares about executing is the thing in between php tags. So I've even seen ones of an image. So you can take a PNG image or whatever and you can have the top header everything via PNG file and then have the php code again upload that it gets past the checks and checks to make sure that it's a pop-in, that it's an image and then it's put on the server as a php file and then you go and execute it. It's really cool stuff. And this actually happens a lot and this is how a lot of malicious explanations of php applications happen and they persist. So great, we made a lot of progress, this is awesome. We're gonna do code and data, so we're gonna get this people and process their data.