 All right. Oh, you're supposed to plug these in my keyboard. And technology. Glad that was recorded. OK. Great. OK. So we've been talking about JavaScript. So what is the role of JavaScript in the lab? And you do the fact-take? Again? I think that I mean you do the fact-take. Yeah. So it's a way you can think of it actually now as our applications being distributed. So not just that there's code that runs on the server side that answers our HTTP requests to form an HTML response, but part of that HTML response I get sent to the client sends some code with it. So now your code is being split not just on the server side, but there's also going to be a client-side component as well. And there's a trend among modern programming languages to take that 100% so that there's actually almost zero code on the server side and all of it's on the client side. So we've actually come full circle from where we wanted to get away from desktop applications, GUIs that run code on your computer. Now we just ask a remote server for the JavaScript code that runs on your computer, but it has different uses. So we were looking at one of the use cases of JavaScript. And this is kind of one of the original examples, just to drive home why it's so useful to have some code we can execute on the client side. So what do I mean by form validation? Why do we need to validate forms? The input's correct. So what are some things that we would want to make sure we were correct if we were doing, let's say, an e-commerce site? Yeah, why do we need an item? So what would be a good validation that you would put in? Just integers, no. OK, just integers so you don't want to buy 1.5 or something? What's that? No negative numbers? Yeah, so I don't want to get a refund for buying negative 1 or something, which allows me to buy other things for free money. Yeah, all kinds of cases. So we definitely, when we think about it, this is an application. And so who should be enforcing this validation? The server, right? Everything goes to the server, then it goes into the database. The server side has to validate the user input. And how this happens, we've learned and we've talked about it on a little bit on Monday, right? We've got an entire round trip that has to happen, actually three round trips. Because we have to establish a three-way handshake, right? We have to send one round trip. They send a SIN Act, two. We send the Act. And then we send our HTTP requests to them. We'll have that as part of the three. And then they have to send their HTTP response back to us, which is four. So we send four round trips. And then to get the form, and then when we fill in the form, it takes another four round trips to establish the connection to send them for them to tell us, no, that's not a valid input. You can't purchase negative one or something. So if we have here some PHP code, we're checking if the get parameter. So if in the URI this set, there's a query parameter named submit. If it is, then we get the student variable that's set. We get the class. We get the grade. And we check if neither of them are empty. Then say error, like you didn't fill out all the forms. Otherwise, check. So here we're checking to make sure the grade is essentially an E note. So you can think of it as either ADCD or F, or apparently ASU uses E, which still is weird to me, but whatever. But the grade, so the grade, so this is all form of validation, right? This is all living on the server side. So the server side D and P code is checking to make sure this input's valid before it sends it into the database. And then you can think of this ELF. ELF actually connects to the database, puts the data in, but we're not gonna deal with any of that. And so the form is gonna be a basic form that we talked about. It's gonna have an input type with a named student, a class with a named class, and an input of grade, and then finally a submit form. All right, so we have this nice form. We can fill out the name and the grade. So what's gonna happen when I now submit this? It's gonna tell me back, hey, you didn't fill out all the forms, right? You need to fill out each of these three. None of them can be empty. So I can fill it out, and I can put the grade in as G, and it's gonna again tell me your grade must be ADCD or F. Finally, I can do that and it'll say grade successfully submitted, right? But if we think about how much communication had to occur in order for this to happen, right? We had to make, we had to get the form validation page, which gave us the page, and then we had to, we put in an empty class field and the server told us. And again, these are slightly more complicated. Sometimes HDD connections can keep the connection alive if you multiple requests, but fundamentally, you have to make an HDD request to the server either if you ran the HDD connection or you're reusing your old one. Fundamentally, you have this massive round trip for every style of interaction. And then we say, wow, we did it, but now it's the wrong grade format. And now finally, I have the correct submission and this took a lot of actual time with data being transmitted to the server when the server knows the validation, right? The server knows what is valid input. The problem as we currently have it, the client has no way to check that. So this is where JavaScript comes in and one of the areas where it shines is, so here I'm giving the form an ID called very imaginatively the form and the on submit handler tells the browser when you click this submit button or you submit this form by the enter, call this JavaScript, actually let's execute this chunk as JavaScript. And so it's gonna call the check underscore form function, which is a JavaScript function that we'll have to define above. So we have our handy script tags, we're gonna define a function called check form and now we're gonna do this checking. We're gonna get, so we're gonna use the DOM and we're gonna get the element that has an ID of the form. So it's gonna return us an object that represents this DOM element. We're gonna check if the form student value is empty or the class value is empty or the grade value is empty, then we're gonna say error must fill out all of the form and then return false. So return false tells the browser don't make that issue here as west you're gonna make from submitting that form. And then we can check the grade. So we can check the grade. We can check if the grade A, B, C, D or F, if it is then alert and say, hey, you failed the validation, your grade must be one of these things and then return false, otherwise return true. So now what is that same workflow that we just went through look like? Well, we have our nice form, we fill it out without the class field, we hit enter, and now immediately after we hit enter that JavaScript function that we just wrote executes it fetches all the values in that form and says, ah, you didn't, you must fill out all of the form, you can't have an empty form field. So then we fill it out and we change the grade to G and now we enter and we pass all these empty checks and we says, ah, the grade must be one of A, B, C, D or F, so we fix it and finally actually submit the real grade. And now if we look at the HTTP request, we made one request for the form validation page, the initial page, got back that HTML page and every single one of those attempts, none of them talked to the server at all. That was all code running locally in our browser and so the only other request we made with the request was the actual correct submission to the server. Cool, questions? JavaScript, wow. So now that we've done this, right, we've moved all those checks into Java from the HTTP code to JavaScript. So we just get rid of all those HTTP checks that we wrote because that's just stupid code that's executed twice and checking the thing that the JavaScript code was already checking. It seems like a huge redundancy and huge waste. No, why not? So one thing that JavaScript can do is send one of the blanks, right? Yes. So JavaScript can disable, the user can disable JavaScript in a browser. And second, is you can manually go to the server. Yeah, so if you look at, let's say, the HTML of this page, can you even manually write what is the HTTP request that will get generated when you fill out these values in this form? You can manually write that. You don't even need something like curl to make a request. You can just use netcap to netcap to port 80 and send the raw HTTP request to the server, right? So that should give you a good indication that there's nothing that says you have to execute this JavaScript before submitting to the server, right? So this is actually a thing that people kind of get into where they think, oh, we have this client side validation. So they even don't even write the server side validation. You probably wouldn't get rid of it in the first place. The problem is relying on it as a security mechanism. So this is, so essentially, so one of these things where client side validation is a super useful feature, but it's not something you can rely on as a security feature. Why is that? So why can't you rely on that as a security feature? Because the code is already with the... What was that? Because the code is already present on the page. Because the code's present on the webpage, so you're trusting that who's gonna execute that code. The user's browser. What can you trust about the client? Absolutely nothing. Just like cookies. You can't trust that they're gonna expire them when they expire. You can't trust that they're going to execute JavaScript code that you want them to execute. You fundamentally cannot trust anything that you want the client to do. And the other interesting thing is what happens when you hit, whoop, what did I do that? Another issue that occurs is that now you've written essentially the same code in two different languages. Has anybody ever been reading some legacy code and you read a comment and then you read the code and the code does something completely different than the comment? Yeah. Yeah, why does that happen? Where's that, what are we doing, copy and paste? Yeah, our comment's executable. What actually gets executed? The code. The code, right? Is actually a school of thought that says comments are equal for that specific reason. Because the comments, as soon as you write them, are essentially out of date when they could be wrong to begin with. Because there's nothing that ensures that the comment actually matches up with the code. Here you have a case where now you have exactly the same functionality written in two different languages in JavaScript and in PHP. So you have a similar problem where what happens if you change the code in the PHP? Do you always update the JavaScript code? How do you know that they're actually checking the right things? Right, so these are, yeah, super interesting problem that has to be dealt with on the web. So there's all kinds of ways to try to deal with this. OK, so now we have to get into why the web is so awesome. So part of it, as we saw this evolution, is we've got basic web pages with HTML and images and some styling. And then we have JavaScript to do fancy animations and to do client-side validation. But we still, fundamentally, what we talked about so far doesn't really enable us to do anything really dynamic. It doesn't allow us to, we still, when we talked about who want to create an email client that would display emails as they came without you hitting the refresh button, there's fundamentally no way to do that. Until the introduction of the XML-HGVRequest object. So if people heard of Ajax, yeah, web 2.0 to use an old term. So that's all thanks to this crazy object. And the history here is super interesting. So does anybody use, for their ASU email, use the exchange servers? Some of you? So if you use the exchange or out of 365 or whatever, there's a web interface. So exchange is a web server, it's an email server. A lot of you in the corporate world, you'll probably be forced to use some kind of exchange server. And so as part of that, they wanted an outlook as an email client, right? But due to an interesting historical accident, they used to be in completely different teams where they exchanged the email server was completely different than the email client's outlook. But the people making the server said, well, what about those people? Shouldn't they be able to use a browser to look at their email and not necessarily always use an outlook? So as they were doing this for exchange 2000, they wanted to try to create this prototype of how to do email client in a browser. Oh, that's an old example, it's retired. But the problem is that normal applications are going to scale because every link you would click, it'd be an entire thing. Every time you want to refresh your inbox, you'd have a full request of the server which would generate all the entire HTML page with every email you got on your inbox on that page and then send it back to you. And so there was a lot of scalability problems and they really couldn't get it working. And what they did was they created an active X control so maybe you know what's an active X control. So it's a way to execute custom code, like an extension, but like a binary extension that was under computer and toxic JavaScript. Anyways, they're a bad idea, but they're mainly not used. But the idea is they created this active X extension and they basically forced as we'll see and they made it a way to asynchronously fetch some content from the server. So that that way when you clicked on like an email and you could just fetch from the server, what's actually the content from that email, send it back. And from a super weird historical coincidence, because it's like this weird thing where they were feature complete at the time, which meant that they couldn't add any new features to exchange. So they convinced the XML team to like shoehorn this active X control that they developed in, which is why it's called XML HTTP request, even though fundamentally it has nothing to do with XML per se. And then so it shipped in Internet Explorer 5 in March 1999, and then exchange 2005. So then again, you have this ticking the egg problem. If you have the server, you essentially have a web developer wanting functionality that needs to be on everybody's machine. So what do you do? You shoehorn it into Internet Explorer to make sure it gets on every single Windows machine. And Netscape, because this was kind of a browser war where they're trying to implement everybody's functionality, Netscape introduced their own version. There's a really good story here, if you want to follow this link from one of the people at Microsoft who was actually involved in this. So, and the reason why I talk about this, and maybe some of my Microsoft bias shining through, but even though the Ajax, everything's literally coming to prominence until Google started using it heavily with maps and with Gmail. Before that, it was actually Microsoft that we really had to thank for creating all of this. And basically, the whole idea that it is now, so what do we do by asynchronous here? Who's we? Yeah, so the browser specifically, the JavaScript, HTML, and DOM do not stop processing to make this request. So what they do is they can kick off a request, fetch some content from the server, process that data, and then update the DOM accordingly. So they can have a thing that runs every 30 seconds paying the server and says are there any new messages? And the server can say no until there is, and then it can change the GUI to update based on that. So annoyingly, and this is like a brief glimpse into browser differences is there's, depending on which browser there's different ways to instantiate this control. You use, the way you have to do this is you have to instantiate this object. We're gonna call it HTTP request. You then have an onReadyStateChange function. So there's different stages in this XML request lifecycle where first it's, I think it'll be next, it says basically, so this function onReadyStateChange will be called before we are going to prepare to make the request, before we make the request, after the request is successfully made. And by interrogating the parameters here in this method, we can see exactly which one it is. And then we can call HTTP request.openGet, the URL, and then a variable, I believe this says, if it's asynchronous or not, then sending the request, yes, okay. So this may seem, it wasn't asynchronous that all JavaScript on our page would stop until we got that response, which is not really the dynamic interactive environment we're looking for. Yes, so zero is basically, so this is the lifecycle, initialized, loading, loaded, interactive, and complete. So basically you just write this function, you wanna wait until it's complete, which means you have all the data, then parse it and do whatever. And so we can access it. So this is the XML part comes from this method where you can get the, if it's XML as in return, you can use this XML, response.xml. And we're gonna look at a super simple example here. So this is our kind of boilerplate page. The important thing in here is the div with the id and insert here. So basically we're going to wait for some JavaScript content on the server. And we're going to create a new HTTP request object in our script, we're gonna check, and this is, so this code is gonna look really weird, I wanted to show that this actually works in old browsers, so this code works in Internet Explorer 6, I didn't have the time or the will to try it in Internet 4 or 5, but if any of you do send me screenshots, that would be cool. So you have to do things like I wanna use console.log to show the output here, but I'm checking if there is no console, then make a console object with a log function that does the alert box instead of logging into the console. We set the onReadyStateChain function, we log the readyState, we save the readyState to four, we get the text, we create using the DOM a new text node, and we insert it into the insert here as a child. And then we log the before request, we make the get request, we send it, we send the after request, and that's it. So this is all the code we need to do an asynchronous request. And if we run it in kind of one of the latest and greatest Chrome's, I set break points at various parts here. So here it's right before the before request. So we can see it's logging inside here, the before request. It is then, so right when it opens, so it didn't even get all the way to the next levels. It's at readyState one, and then it's logging after request, and at that point just did readyState two, three, four, finally readyState four, where now it puts the content in there of testAJAX. So this is kind of standard stuff. And the cool thing is, if we look at the network tag, we can see that our page, aJAX.html, made a request to aJAX-text.txt, which was the URL that we wanted, and we made a get request that maybe everything we wanted, all without us having to do anything, completely in the background. Yes. Is port 32, what's channeling AJAX? No, that is AJAX.html line 32. So that means that's the initiator, so this means that's what JavaScript code made that request. So you can do things like debug that, and yeah, do all kinds of fun stuff. And if we look at that, it's called testAJAX. And so we can do the same thing in Internet Explorer six. Yeah, it took me a long time to figure out how to run this, but so now we don't have a console, so you just have to do alerts. So it says, before request, one, two, three, four. Why didn't it do after request? Let's say it did after request at some point, and then it'll change the thing to say testAJAX. So we get the same behavior even on super old, and super old browsers. Oh, and then it did after request. I feel a little skeptical about that. But yeah, this is Internet Explorer six that this runs on. I don't know, it's kind of crazy that you can run the stuff on this code, these browsers that are so old. But what you should be really using is never code this by hand. You should always do something like jQuery, which I tried to stress earlier, because the scripts are gonna fetch in the jQuery library, our script, we're gonna do dollar sign, which is the global jQuery object.getAJAX.test.txt. We have a function that gets passed in the data, and we use the jQuery object to look for the thing with the ID of insert here, and set its HTML to whatever that data is. So, which code is simpler? Yeah, it fits on one slide instead of two, so that's your first hint. Yeah, so we can do the same thing here. I'm not gonna go through it step by step, but you can see we fetched the jQuery, the jQuery library, and then did the aJAX request. And we actually, so the super cool thing about jQuery, is they are discontinuing support for IE6 at some point, but I don't remember exactly the current status there, but it does work in the example that I used. So whatever, what's this? Oh, I guess I didn't put the version number in there. One 112, so anyways, it works in both, and now we can make web applications that really do make a gooey application, that asynchronously fetch things, update and respond to our actions. Cool, okay, questions on aJAX? All right, sweet, we're almost there. Okay, so really, when you think about how, so what we need to think about now is how people normally create web applications, so we can think about how to break web applications. Because we don't understand how that actually made, then we're just basically random guessing. Is anybody like randomly guessing? Yes, some of you. And you do it quickly, then get on you, but if you're randomly guessing, and to the layout of a normal PHP application, you're gonna have a really bad time. So, this is kind of what I think as natural kind of PHP code. And this is, I mean, we'll be talking about it in a second, but the main idea is PHP was really designed to be this templating language where you show what the page should look like and you interpret some HTML code. So, you'll do things like start a session, you'll set the session's username to admin, you'll get some username parameter, check it, check it against admin. This code I took for a long time ago. Anyways, and part of what you're doing, so let's say you're writing something like Facebook and you have a PHP file that outputs their comments or the user's wall. And so, in that code, you fetch from the database all of the posts on the user's wall sorted by time. That returns you an object you loop over and as you loop, you output the HTML and you're dispersed with the output that you received from the database. Maybe you make multiple queries to the database to fetch that information about the individual users. And really, PHP has this very natural style where you can be dispersed like HTML content. So, here we have HTML content, here we have PHP content, here we have a database access where you were using SQL Lite to access elements of database and looping over all of those responses to output entries. So, what's one of the benefits of this style of coding application? So, you don't need to just run the page, right? This is your home page, you go to the home page, you test it, it doesn't work, and then you're done, right, when it works, it works. And you need to update it, you just go in, edit the file, and you revisit the page. It's not maintainable, why not, it's so easy. If you want to edit the comment page and you need to edit the query, you just go right to comment.php, and you edit that query, that's gonna be... You gotta reuse it. What was that? You gotta reuse it. Yeah, that's it. You need to use it. Ah, why did I reuse it? Thinking that I'm gonna go to the latest and ask there are comments if you want to use the comments. Yeah, so, I mean there, and PHP definitely has this functionality, so don't misunderstand me in that I'm saying PHP doesn't have all these things. And even modern PHP has crazy things like classes and it has things like, actually all kinds of crazy functionality as we found out recently, but, but the, especially the way you get started, right, the easy way to develop a PHP application is like this, so if you don't think about defining functions that return your comment objects that you can call from anything, right, you just issue the SQL queries right in line. So now you have these crazy, like almost spaghetti code where the HTML is mixed in with the SQL queries, which is mixed in with authorization checks, you're checking if somebody's an admin user or not. And now what if you wanted to output the comments, let's say, in JSON format so that you have a mobile app that uses it at the back end, right? It's incredibly difficult because your HTML is tightly coupled to your logic, like your application's logic. Yeah, so, yeah, it's actually kind of crazy if you ever wanted to maintain an application that was written this way, because let's say you want to even do some nice refactoring and change, break your comments into a, I don't know, author, like, maybe you want threading in comments now so you have comments, replies to other comments. I need to change every single place in your code that ever issues a SQL query for those comments. It gets to be insane. The other thing is you have this tight coupling of the URLs of the string, because if you want to go to the homepage and slash homepage.php, if you want to go to comments slash comments.php. And that maps directly to the file system. Add comment, view comment, users, viewusers.php, which maps directly to the file structure. But, from what we've learned so far, is this necessary? Stop directly querying the files to send them to a one-level program. So, as soon as we can build our program on those abstractions and modify them, we'll just stop. It'll be very easy and scale a little bit. Right, so, we think about it, right? Yeah, we're going to look at the HVP specification that the URI is the servers along with the servers that, right, and gives that meaning. So, the URLs can be anything. They don't have to be which PHP files they executed. And now let's say if I want to add new functionality, I want to rename one of these PHP files. If I do that, all the existing links that are pointing to that from my website, which I could change with careful care and deliberation. But, anybody else's links that are linking to that content could potentially break. So, now I even need to put a rule in my web server to say, okay, now it's actually, instead of view comments, I want to call it view all comments. So, I need to make a rule that says if you see something called view comments.php, actually redirect it to view all comments.php. And, I have to maintain all of these rules over all the lifetime of my application. I think it would be interesting if somebody looked at old Facebook links, for instance, and see if they still work, and still take you to the right content. That would be something interesting. Could those PHP files be made asynchronous requests? Yeah, possibly, exactly. So, we may want to talk to these different endpoints, and do different things depending on if we're going to it directly, or hitting some kind of asynchronous endpoint. So, this is another thing that can throw you off, if you, and I've seen this happen sometimes, or you go to a website, and you're like, oh, it's very clear that you're using PHP because every URL ends in .php, but when you look at the headers, it's actually like Ruby or Python or something, and they're doing some URL rewriting that changes over. So, it's fundamentally a bad thing, because nobody cares that you're running PHP, right? So, the user's no care. It's just that this is the default, so it's easy, and so everyone does it. Cool? Okay, so the web ecosystem that we talked to, so we've looked in-depth in here, we have the client making an HTTP request to the web server, which makes some kind of, whatever request to the web application, which does the processing, which talks to some database, and then sends the content back to the web server, which then sends back content as an HTTP response back to the client. In reality, things are super complicated, so even notwithstanding the proxies we talked about, you can make a request to one server, one web server that then talks to its backend web application. You can have a lot of more applications now will have a web server in front, and that talks to multiple backend services that need to provide some functionality that the server in the application kind of falls up and sends back. You can have, yeah, okay, cool. All right, so you can have super complicated things where you have one web application is actually fetching data from another web application, which I haven't called in time. You go to a website and you see that they're pulling in Twitter content or any kind of other third party content. It can have it on the server side as it's happening here. It can happen in your browser. So one thing I want to ask them to have a touch about is, so we're looking kind of how each of these pieces work, right? How the web server works, how the HTTP works, how the web applications work, how HTML works, how the browser interprets HTML, how the browser interprets JavaScript. But what does security mean here? What do we even, you know, what are some notions of security here? Is it changing the database in a way that it isn't programmed? Yeah, well, maybe not programmed, but is it meant? Yeah, right, so you have the same idea as we talked about, confidentiality, integrity, availability, applied to the database and the data there, right? So what would confidentiality be applied to the database or what application? What does that mean? The binary data. Yeah, so if you have data that should be private for one user, other users shouldn't be able to access it. That would be one instance. Integrity would be my bank account, balance is stored in the web server, nobody else should be able to change that, unless they change it up, right? And availability is, you want that database to be accessible. Okay, that's not a one area, what else? The web server, email, mail server, that's the database, even the client itself, and the browser, and the security of all this browser. Why is the security of the browser important? For example, you know, the web server has been, you know, application has been exploited, and there's some kind of, it's quite minor, it's not that system, so the RPC will GPU power, JavaScript on the whole system, on the whole browser, I don't see the information in there, you know, getting money on the whole source. Yes, that's actually interesting. I don't know about that, which part of the CIA that actually violates, maybe a little bit. There are people that, they have to get the GPU, so like if you don't want to see ads on your website, they just find it good, it's a bad one. Ooh, is that what you're saying? Did you agree with that? So they, they show all the, like people want to see ads, so I think it should be my, they want to see ads. Yeah, I know that's interesting, that's why I think that's a very tricky question. Okay, let's think about this in a little bit of a different way. So, does anybody browse with more than one tab open? No, it's like if you just one tap people, you just keep clicking through when they've done, you're done, you feel like that, or is it more like me, where you have like 50 or 100 tabs open, and then you get lost sometimes in that open? Yeah, like a lot of tabs. What else is rapidly open? What else is rapidly open? Yeah, exactly, what else is rapidly open? So the question is, when you're on, let's say something, so would you consider your Facebook account to be something important to you? Does it have it? And, so you want to give you a password for your Facebook? Sure. I mean, is that extra credit? No. Absolutely not, you know what I'm saying? I'm not even saying not in here, actually. No, you think about it, I guess the question is, if you turn it over to a criminal, right, if you turn it over to your Facebook account to a criminal, would you want your criminal to be contacting your friends and family on Facebook to say that you're stuck in some jail in some country and you meet them to wire you money, or if it's hand that happens? Would you want to be shilling Ray Bands or whatever fake products on Facebook by messaging people, right? So, or would you want to not only have your Facebook anybody use any other sites, and they log into that site through their Facebook account, so now if they get into your Facebook accounting and log into any of those other sites that you've enabled that on, right? So you can replace that with email though, I don't know. I mean, Facebook is one of these things I think is more, I mean, depending on how you're using it or if you have it in the first place, it's more of a security critical than you often think. So, you know, Facebook open the tab on your browser, Facebook's doing stuff, it's got JavaScript running. Do you worry about going to another website and another tab like attacker.com or some shady site that now does all have a medical? I guess shady sites are watched and streamed some movie illegally or watch a sporting event live that is not supposed to be streamed on that site. Do you worry about that impacting the security of your Facebook tab? No. Why not? They're separate processes and browsers have- All browsers, all browsers go through, right? Browsers have this sort of sandboxing where one tab is completely different from the other. Yeah, but even if you use something like I even internet explorer six doesn't have any concepts with sandboxing, right? You're downloading code from remote websites whose authors you may or may not trust and that code is running on your machine. So part of it is a sandbox in the sense that JavaScript as it executes in the browser it can't just open a file on your computer. It can't write to arbitrary files on your computer so the browser has implemented sandbox mechanisms in that sense. But why can't it mess with Facebook's view? Right, we talked about the DOM, we talked about the Doc and the Object model. Why can't it do that? How would it change the HTML? With the DOM, you can do DOM, you know. With the DOM you can edit and completely change the look and layout of the page. So if I was a bad guy I could change the DOM of your Facebook page to make it look exactly like the login screen on Facebook. So you think you're locked out, you type in, you're using any password but the action element of that form actually redirects you to my page, the attacker's page sends, you're using a password that then redirects you to Facebook so it looks like you're back locked in. But one tab should have access to the DOM of another tab? Yeah, why not? Okay. No, that's what I'm saying, so why not? So what properties of security do we want to ensure there? Integrity. Integrity and maybe confidentiality and maybe stuff sort of in that DOM if that's your bank account or your health records you may not want other random sites that you visit to be able to know that information. Yeah, so we need some sort of way to, for the browser, to kind of enforce some kind of policy that says who should be able to access what because really each of our browsing tabs are, I mean most of them are sensitive. Or another thing is cookies, so what if, why can't the attacker tab grab your cookies for Facebook and use that to log in to Facebook, right? So, I don't wanna talk about frames, I'm not gonna talk about frames. Okay, yeah, okay, so the question is, okay, so tabs are one thing, right, which is very clear that there are different elements on the page. Other aspects are things like frames. So a frame is basically in this JavaScript no JavaScript, in this HTML, we're setting two different frames on this page and we're setting the sorts as other HTML pages. So the browser will get that and we can include arbitrary URIs here to include content from whatever URIs we can, and these frames you will see unless you're using super old software. There's some things, well I guess I shouldn't mention them but I definitely use some government systems that still use these frames. Mainly what you use though are iframes. So if iframe, I believe the I is a inline frame so you don't get the frame thing, it looks like it's just part of the page. And this is how you do things like advertisements, if you wanna let somebody execute something in your page, the iframe will be included in the visual element of your page but if you're somebody like Facebook, well Facebook doesn't add, so if you're, what's the big popular one that I don't know, YouTube? YouTube, if you read it would be better, I think it's the ads, I don't know, CNN or whatever you prefer. If those ads are iframes, right, you wanna make sure that those ads can't mess the other content of the page because they're gonna just go right all the other ads, they're gonna try to steal your username password, try to do all kinds of the various things, figure out what things you're doing. So iframes are way to include content from other people but fundamentally we want it so that that JavaScript is not able to interfere with each other, so you should be able to iframe essentially anybody else's content without it messing with your page. And the similar concept extends to tabs, like tabs I think are a more natural way to view it but it is kind of weird when you have this content intermix on one page of what you really want to happen. Okay, cool, so also with JavaScript, so there's the sandboxing mechanisms, no local files, mostly, no access to network resources, but is that true? What network resources and your access? Maybe you're about to do something like this, right? There's some limits on that but we'll talk about that in a second, but you can't make an arbitrary request to an arbitrary port of whatever you want. It has to be an HTTP port. Other rules they have now have no incredibly small windows because you used to have pop-ups that would be incredibly small and play noise and it was super annoying. No access to the browsers history? Why do we want this? Or why is this a desirable, desirable goal? Do you think your browsing history says a lot about you? Yeah. Everyone has this look but I'm like, no. Yeah, right? So you don't want every single website you visit to know the history of all the past websites you visit. Pretty obvious from what we've talked about that if you go to Facebook, right, you know about sessions. Facebook knows every other time you've gone to Facebook. What should they know about the entirety of every single website you've ever visited up until that point? Probably not, although they'd still do anyways. That's another issue. Cool, so it really comes down, the core of JavaScript security comes down to the same origin policy. And this is the well-defined mechanism that says this JavaScript shouldn't be able to mess with the DOM of this other iframe or tab or whatever. And so this is something that's insanely important in JavaScript security. And it's standard across browsers. This is something you need to know. So if you ever tell anyone you've learned something about web security and they say, oh, great, tell them about the same origin policy and you can't tell them about this and say you took this class with somebody else. Cool, okay. We know that every single tab iframe in the browser is associated with the domain. Why didn't we know that? Where does the domain come from? The URL. The URL, yeah, the URL and the URI, right? All of them have a domain and you've seen that in there. Sorry, okay, yes. This is slightly confusing, I realized on this wording. So there's two different things that are going to separate, the DNS domain, the domain name and the same origin policy domain. So the SOP domain is determined by a tuple, a three tuple, so three elements. The protocol, so what's the protocol in here? HTTP or HTTPS or even FTP or file, right? These are all different types. The actual domain, so the DNS domain and the port where the frame or tab content was loaded. So JavaScript can only, so code downloaded from a given same origin policy domain can only access the content in frames that are from the same origin. So why is the port important? Because it can be posted in virtual servers where each one has different port. Yeah, you can have content, plus I'd say a better argument for DNS domain, right? So that would be for DNS domain rather than using IP addresses, right? You want to use different DNS names. That's definitely good. The port would be, maybe you could. HTTP and HTTPS. Yeah, so HTTP and HTTPS are different ports. FTP may be somewhat restricted to use a different port on the same server. You want to make sure that content's different. The idea is that if I'm sending HTML content on a specific protocol domain port, then I own all of that content and I own all the domains. Sorry to be, sorry, I didn't mean to say domain, I'm a DOM. I control all the DOMs, right? Because I can send you a different HTML page anytime you visit me, right? We're with different JavaScript. So I fundamentally control all of that content. So everything in the same protocol, DNS domain, and port are considered the same origin, the same origin for the same origin policy. Okay, there are a couple exceptions to this. So we talked about when I have JavaScript on my age, like I had jQuery, where was I going with jQuery from in my example? I don't remember. Was I posting it on my server? Yeah, I was requiring it, I think, from Google's content delivery network, a CDN, right? So, but, so let's say that example was running on adamdk.com, HTTP, port 80. Should jQuery be able to change or do any of that off? Yes, yes. Well, from what we've talked about so far. No, it's from a different protocol. It's easy to PS. It's from the domain.google.com, and it's on port 443. So it shouldn't be able to accept that this type of script inclusion is essentially to think of as a same origin bypass. So it's a way for me as a web developer to explicitly say, I want to download this code from somebody else and execute it in my origin, which means I'm essentially trusting Google to not mess with my page as we'll see in a second. Cool. Oh, this was the example, sweet. Okay, yes. So this is actually from, I think, my homepage, right? So I'm including this ajax.google.com, but because of this, it's a script with an external source that's included in my same origin. So no matter what, that's definitely in the same origin. All right, any questions on this? And this is the key. This is why ads can't mess with whatever page when you include them in an iFrame. What about if you include them as an external JavaScript inclusion? Yeah. But in other words, they can do whatever they want. They can create better iFrames. They can do anything, really. So because you put that JavaScript in the source, that gives it the bypass? Yes. Yes, you're telling the browser, and you can think about it as extending trust, really, because you're telling the browser, I trust this JavaScript. So it's essentially the other way to think about it is take that JavaScript code, go fetch it, right? Do an HTTP request for this JavaScript. Give me back the content. And it's as if it was included there in line just like it came from me. The fact that it came from somebody else is irrelevant as if it was included directly in there. Cool. All right, so now we're gonna do a tax, which is awesome. So we've seen all different ways we can store data, right? So we saw that the cookies are the servers that are asking the client to store some information. We can store information in URLs. We can store information in forms. We can use plugins to store forms. There's also newer technologies like local storage, which gives the page, I think, something on order of 50 megabytes to store things. So you can do actually complex offline applications that have their own local storage. So this is continuing with today's theme of never, ever, ever trust the client side. Specifically, we're gonna look at reasons why. So this is one of the main, a key attack on web applications is if that application is trusting information that it's storing on the client, then that can be a vulnerability. When would it be a vulnerability? Any sort of, what's application? If it has to do with authentication, it's more generally, more generally, right? Anytime it allows you to compromise the security of the application. That's not a great question. It's just getting to the thing about it. So if you look at an application and you go, oh, this application is setting a cookie called language and it's setting it equal to EN and I can change it to something like ES and then the website's in Spanish. Is that a security vulnerability? Probably not, unless there's a weird security vulnerability in the Spanish version when you go to that website. I would hide it out, but maybe, right? The fact that you can tamper with cookies is no. It's about what tampering with cookies allows you to do on that website that you couldn't do before. Cool. Okay, so this is important. So tampering is not a vulnerability, right? You need to actually do it in order to compromise the security of the application, which is why, as we talked about many times, understanding is the most important thing about what these applications do and what they're supposed to do. Okay. Yeah, so it's a much more complicated statement, right? But if the server site code allows our tampering and that tampering compromise the security of the application, then there's a problem, right? If I have a username in a cookie and I change it to admin and the server says error, go away, there's not admin, that's good, that's what it should be, right? So that's it not accepting it. If it accepts it, but it's still our user, then that's also not a vulnerability. It's only if we're now logged in as the admin, we go, woo, sweet. All right, one of the first ones we're gonna look at are hidden form fields. So we looked at forms earlier. Why do we want a hidden form field? It seems a little bit oxymoronic. Why do you use a form? To keep user input, why would you want to hide a form element? What was that? It's a field that you don't want them to change. It's kind of a weird thing, actually, especially when you see how it's done. So a lot of times, so caches, so this is, it uses an anti-bot mechanism often times because you'll have a form field and you'll hide it from the user. And so a normal user should never change that value from what it is, but bots often will fuzz and change and put in the value there. So you can detect that somebody who's not a human or not using a browser did that. It's not very effective. We'll look at CSRF later, so I'm not gonna get into that today. But the problem is, and it's often used, you can think of it as like passing data from one step of the process to the other, right? So rather than creating a table or some entries in the database about even if you think of it as what elements you're adding to your shopping cart, right? You could put that in some informed information. The problem comes if the server blindly trusts that information. So for instance, okay. So this is a really terrible, very synthetic example of a shopping cart. So we are at, so put ourselves, we've all online shopped. Most of us, no? You can envision it just like shopping, but online. So now we're in the cart right before we're gonna purchase our items where we're gonna confirm what we're ordering. So I have one laptop at $1,000, a monitor at $1,500, total price of $2,500. And here's the credit card number that I wanted. And I have this big purchase button, right? Seems fine, this is a normal thing that web applications do all the time. When we look at this page, right? So at this point, we don't know necessarily the PHP on this page. But when we look at this page, we can see that it has a form. So the form has an action of purchase.php. It's got a submit button, which we know about, the purchase, and then it has hidden values. So the names on these are OID, price, and curve. So what do we think those stand for? And the values of, let's see, the value of OID is 5,929, the value of price is 2,500, and the value of curve is USD. So what do we think those are? Order ID, order ID, price, and currency. Which of those would you wanna change? All of them, I'm trying to name all of them. I mean, I first started creating price. Get that as close to zero as possible, but it doesn't let you accept zero. So we wanna look at, and this is why I'm looking at the code, or you're saying something like birth proxy is so important to you, you wanna see the actual HTML. Because with the browser displaced, you do something different. It's for human consumption. But you wanna see essentially the raw code, just like looking, I mean, it's similar-ish to trying to break a binary just by its input. You wanna look at that x86 code and actually see what's really going on there. Okay, cool. So then, basically, so okay, that's a good question. So then what would be malicious versions of these values? So what kind of things would we want to try? So some of you do one thing that you wanna try, and what you're looking for. Change the price to negative. Okay, so what are you hoping for? Can I guys see if I'm ready to go? Credit for your credit card, right? So that would be the test. So there's one thing, so you put the price to the negative, you submit the form, and then you'd see A, the transaction's accessible, and B, credit that your credit card, or blood, ultimately charged that credit card. What else? Like, I would tell you if it's giving an error, FET is the price. Come on. Do something else apart from the credit card. Well, you wanna put a million? No. It's not letting us change the price, so we're trying to change the currency for the US price. So think about it this way. If it doesn't allow us to put it to negative 10, does that mean we can't possibly give more input to the price variable? Think about the set of all possible numbers that we put in there, right? We know it accepts 2,500, or we think because we've gone through that, but it does accept negative 100. Does this mean we just give up? So what's the number you wanna try? So we probably don't wanna charge a million because we don't care if it lets us pay more money. It's not a vulnerability, and that's, I guess, a weird benefit to the company. Do you know what to do? Yeah, 0.01, so try to get a fraction, like a penny, see what happens. So what are you looking for then? So, maybe like normally here, there would be some validation that the price has to be greater than zero. That's why I'm at least 0.01 so that it passes. Right, so what are you looking for? How do you know if that your test is successful or not? It's hard. It's good for order to charge the credit card, yeah, exactly, so that's, so you gotta think of every time you're generating input to especially a web application that you have no idea what the source is, it's easy to just type stuff in and hit enter, and then you're like, oh, did it work? Did it not work? So you need to be thinking like a scientist and thinking through, you need to create a hypothesis and then a way to test if your hypothesis was true or false. So you can say my hypothesis is that it will let me buy this item of less money by changing the price. So I'd set the price that I would choose probably a dollar because maybe fractions are weird, so maybe a dollar, you'd submit it, and you say it's a rejection transaction, then break, if not, then you know that it doesn't allow you to produce the price. I'd also try zero, too. Why would I wanna try zero as well? I mean, obviously it's for free, but why would I wanna do that in addition to testing one? How negative? We don't wanna test it negative. Yeah, we won't test it a negative number, we've tested a positive number that's less than the price, but we haven't tested zero, right? So there's oftentimes, it really depends on the domain, you have to think about it, you wanna test the different boundary conditions, and this is actually a good general piece of advice if you're testing your software, right? You wanna think about things often blow up when there's a zero, right? If I buy zero here, it's all kinds of those things. So that may tell you some more information. Cool, all right, all right. So we don't have a let's hack it, but I will do it here because I don't wanna spend a ton of time on this. So, okay, so we do this, I use Curl, right? I look at the HTML page here and we know just like we talked about, we can take this form and we can make the exact HGP request that's gonna get made. So I can do that in Curl, but it tells me, I don't know who you are, by the way, why is that? Cookie, the cookie, I haven't sent any cookie, I've only told Curl to use these four parameters of OID, price, and currency to this URL, but I didn't tell it to send any cookie, so Curl by itself is not going to. So clearly this is using some kind of cookie-based session information. So I should go to the browser, I should view the cookies for that site, I should figure out what that cookie is. So, we'll figure out the cookie and then we use the dash B option in Curl to send it. So we do PHP session ID equals block, we send this, and then we say purchase successful, your final order total is 2,500 USD, charge you a credit card. And we say great, because we're testing this, we're using a fake credit card, we decided not to do a company or something, and when I would just board, yes. So now we have our good, like this is our transaction successful state, right? Hooray, all right. So what if we changed the order ID? So what if we changed the order ID to something like one? What are we expecting to happen? So this is an order for the same price. So if I was actually doing this, I probably wouldn't just use a random order, I would make two orders with two different users, I'd make one for, I don't know, some pencils or something, and one with like laptops and monitors, and I'd try to purchase the pencils but with the referencing the other order ID, right? So this way I control all the values, I'm not changing the order ID to something like one, which is just some random other person's order, but I have no idea what it's done. Maybe that person gets a second shipment, maybe like anything happens. It says fail not your order. Oh man, that was not good. So what do we now know about the server side code here? It's checking, so even though it's sending a order ID in a form field, a hidden field, right? It's still checking that, that at least that we own that order ID. So I can't order from somebody else's orders. Okay, cool. So price, we talked about price, so we could do a price of one. Oh, we really want to just pay $1. And it says fail not the correct price, half the dollar, right? Like maybe this is some weird, I don't know why it's doing it, but it is doing it. So what does currency stand for? So what do we use full to manipulate this value? Yes, you have a why. It changes the average. Yeah, it changes rates. Would you want to pay 2,500 euros for this? No. No, what would you want to pay 2,500 though? Pesos. Pesos, that's a good one. Again. So we can try, I think these are Hungarian for nets, if I remember correctly. And it's a purchase successful, your final order total is 2,500 Hungarian. And if we look at the time that I did this, that was $9.3, right? So the fact is even though we couldn't change the price, this is something really important, but there are other things that impact that, that have security problems. So this currency, even though it seems like maybe that's not a big deal, it actually is a huge problem. And now we've purchased that for effectively nine US dollars. Cool. Okay, cookies, cookies super important. And just like we saw, so we can take cookies, we can put them in a curl command, we can do whatever we want with cookies. So we can't trust cookies as well. These are another thing. So this is going over the different types of client-side information that can be manipulated. So we just looked at hidden input fields. We're looking at cookies. Okay, we still got time. URL parameters, right? So why would URL parameters be used? People are lazy and it's easy. I don't know, I'm on a deep answer. Developers are lazy. They're just trying to build stuff that works and get it out the door and move on to the next thing, right? Cool, okay. The refer header, so this is an important, anybody know what I'm saying, weird about this title? Is it what? Is it a real word? It is a real word. Yes, it is a real word. The page that you called for on it. Yeah, we haven't talked about what it is yet. I'm saying what's the problem in the title? How do you spell refer, there should be three R's on the per. But they defined this HTTP header in this spec. The idea is it's a header that is set by the browser to tell the server where they came from. So if I'm on a page foobar.com slash example and I click a link to my website, the browser will send a header to my website, a refer or a header with the URI that came from them. And this is kind of actually a nice thing because you can see how people are using the website and going through the super interesting thing is the spelling was a typo and it wasn't caught until it became a standard and people were already using it. But it's kind of weird when you think about it. Like this actually may have saved a lot of bytes and bandwidth if you would like to aggregate every HTTP request that's ever been made. No, it's interesting, I don't know what you're thinking about. So just like everything else that is sent from the client this cannot be trusted. It is usually in the form of URI but it's a header that is sent by the client. We can set this to be whatever we want. I've heard of cases of SQL injection that are cross-excerpt and scripting vulnerabilities happening through refer or headers because that data is being used somewhere and being used thrown into a database or used in some part of the system. All right, cool. And oftentimes actually some terrible websites will use the refer or header to do access control. So they'll say you can only access this page if you come from the home page and these referers do that. And they actually don't do any cookie checking or any other kind of authorization. So this is a super fun thing to do. Okay, very quickly. I want to talk about this because this ties into what we talked about earlier. So we talked about with client-side JavaScript that you can write JavaScript to validate form elements. There's also really cool features in HTML5 if you do web development that the browser will enforce so you don't need JavaScript. So you can set the required attribute on an input field to say that this thing is required and the browser won't let you submit until that's required. You can have type email which the browser will do some validation that it's actually an email. You can set a pattern or you can do custom validation. All of these as we talked about can be bypassed. Wait, okay, that's weird. Ah, I should have more on this. Okay, what's really interesting about this is most of the times when you're trying to manipulate some parameter and then to change it to be something else, you don't really know exactly what you're doing or what, like when we change that price, we didn't know what the server would accept or not accept. The super interesting thing with this client-side validation, the server is literally sending you what it thinks is valid input. So you can actually look at that and say, ah, the server thinks that the price should be, let's say, greater than or equal to zero. That's probably above, the price should not be zero. So you can change, you can actually start testing an automatic generic input that the server should reject and test to make sure that it does. So you can test the negative value and the zero value. Anyways, there's some really cool research on this where people do this automatically. So they statically analyze the JavaScript code in order to create inputs that should fail validation and test that it does fail to validation. All right, and in a long time, we will talk about how to break authentication and authorization.