books. If there's something, except for, of course, these two transactions down here, the 80 and the two, those are not on our books. And the general rule is going to be this, if it's on the bank statement, and it's not on our books, then we probably have to fix our books. Now the exception to that is what often people think of the reason of doing a bank reconciliation. And that is what if the bank made an error? That does happen. I've seen errors before, but the bank is pretty good at it. So they don't often make an error. What happens a lot more often is that there's transactions on the bank that we have to record. And that's the case with, of course, these two transactions here, the 80 and the two, 80 represents something that maybe we went to the bank and took a withdrawal and never came home and recorded that or to the office and recorded that withdrawal. And therefore, obviously it came out of our checking account. Therefore, it should be reducing our checking account. It is deducted reduced from the bank's side. We haven't recorded it on our side or something like bank charges. If we got a, if we bought checks or if we just had a non-sufficient fund charge, something like that, then of course the bank will just take it out of our account. We wouldn't even know about it. We don't know about it until we get the bank statement and say, okay, they took, in this case, $2 for just surface charges that we're going to have to reduce from our side. Also note that if we're a small company, some small companies may do a lot of stuff basically on a debit card or even individuals may do a lot of stuff on a debit card and actually record it monthly, meaning they're going to get the bank statement, look at all the charges they have made and basically record the transactions from the bank statement to the books in that fashion. Now, the other side of it is if we have something on our books that's not on the bank statement, such as these three items here, so we have these two checks and this item, this deposit, then that difference is probably due to timing differences, meaning we wrote these checks clearly and we made that deposit, but they have not yet cleared the bank. The bank hasn't had time to process those because these two checks have to once again get picked up by the recipient of the check and they have to deposit it and then tell our bank the deposit should take one to two days, but this was deposited on February 28. So what we're going to do is we're going to say, okay, here's these two checks. If we're concerned about them, then what we want to do is call the bank maybe because note when we're doing this process, it's going to be even though it's as of the 28th of February, it's going to be some time in March because obviously we got the statement some time in March and so we can call the bank. We can say, hey, bank or go online and say, hey, did these two checks clear some time in March? And if they did, that's what we would expect and we say, okay, we're just going to record that that's a that's a difference. That's a timing difference. We're good. Same with this deposit, we can with some time in February now, we can call the bank if we're concerned about it and say, I would expect this deposit to have cleared sometime between, you know, before March 3rd. Is that the case? If it is then as of this time period, we just record that as the timing difference. So first let's take care of these two items. We noted that these two items were on the bank statement, but they're not on our books. So what we're going to do is just make the adjustment. Let's just make the adjustment for those two items. We need to fix our books, meaning that if we took out $80 here and we drew it out of the account and just got cash for it and we didn't record it in our books, then what's going to happen to happen is cash is going to have to go down by that $80. We can see that cash has a debit balance. We need to make it go down. We're going to do the opposite thing to it, but therefore that would be a credit. So that's going to be this credit here. We're going to credit cash by the $80, which will reduce the cash account. Then we're going to have to record some other side of it. So we know that cash has to go down. What about the other side? Most likely it's going to be some kind of expense. If we took something out in cash and didn't keep the receipt, that's, you know, we should keep the receipt probably, but if we took it out and we don't know what we spent the cash on, then we're going to have to put it somewhere. One place we can put it is probably the miscellaneous account here. So we're probably, we could put it in the miscellaneous. It's going to be some type of expense, most likely, and expenses have debit balances. And once again, they only go up. So we're going to make it go up by doing the same thing to it. We're going to debit the $80 expense. If we record that then, what would happen is the expense goes from zero up to 80. It brings net income down because net income has a credit balance. It's the 50 minus the 80 would bring it down here. Also, of course, the cash has a debit balance. It would go down by that 80 and bring the cash balance down. That would put it back in balance. And there's what the effect on the net income would be. Once again, this is income, not a loss. The other side of it, if we had a bank charge, this would be also something that the bank would record that we wouldn't know about until we got the bank statement. So the bank took the money out. If there's a non-sufficient fund, if they charge us a late fee or something, then we just get it and we go, okay, we're going to have to record that. We're going to have to reduce our cash account. Once again, cash has a debit balance. We're going to do the opposite thing to it. Therefore, we're going to credit cash. So we know that has to happen. So we're going to go ahead and credit cash. What's the debit going to go to? What's the expense account? Probably going to be an expense account. I personally like to make an expense account called bank service charges. So I like to record what the bank has taken out in a separate account. It is up to the bookkeeper to do that if they want to or not, because note that it is probably going to be a small amount. So hopefully the bank's not taking a lot out. So since the amount some people might say is immaterial then, why don't we just put that into miscellaneous as well or something, because it's a small immaterial amount. Personally, most of the people I've seen, I kind of like to see how much the bank's taken out, even if it's small, just to make sure it is small. But that's a choice that the bookkeeper is going to make. In this case, we have a separate account, bank service charge, it's an expense, expenses that debit balances, we're going to make it go up by doing the same thing to it, which in this case would be a debit. So we have it going from zero up by the two here to $2. That's going to bring down the net income, the expense goes up, which brings down net income. And then the cash is the other side of the entries being recorded here. That's what's making the 82, the 80 plus the two. And so the cash has a debit balance, it's going to go down by the credit for the $2 in that case. And now we've recorded these two transactions. So now we can say, okay, those now I can see. If we look at this same transaction in terms of our general ledger now, note that this is where we were at on our trial bounce before these two transactions where we should also reflect this, this would be reflected on the general ledger as well, meaning in our GL, we have as of the 28th, there's that $80 that's going to come bring it down represented by this journal entry. And here's the $2 bringing it down represented by this journal entry. So that would also, of course, be reflected on our GL so that our new balance in the GL would be 16 to 56. So this is where we stand now. This is still where the bank statement is. So we're still not in balance, even though we've adjusted for these two amounts, what we have not adjusted for yet is of course, these that were outstanding. So that's what we'll have to do next time. So now you'll remember, you'll recall that we tick and tied all this off, we've now taken tied these off, and we're left with these items, these three items. So these two, they're on our books, but they're not on the bank statement. And we wrote them as of the end of the month. So it's expected, we would assume that we wrote them, and they just haven't cleared yet. So that's going to be on the bank reconciliation. So the bank reconciliation should for the most part be these timing differences, meaning this is what we started with, or this is what is on the bank statement. And then we're going to say what should be on the bank statement that is not due to timing differences. Well, this 130 plus the 110 are checks that we wrote, and they're not included in the ending balance on the bank statement. And they should be because it's just a timing difference, they're already out, the bank just hasn't got to them yet in order to record them. Therefore, we're going to reduce the balance by that. And what that'll do is I'll bring the balance down to 1556. And of course, we're still not quite there yet, because our balance on the books is 16256 at this time. What's the difference? It's the deposit we haven't yet recorded, I would hope. So let's do that now. So now we've found these two. Again, these two are done, the only outstanding item being this now at this time. So we found these. So that of course will be recorded here. So now we have the outstanding deposit, same idea. We deposited it as of the last day of the month. Therefore, the bank reconciliation for the month does not yet have it. We could verify that it has passed and cleared in March. But we just want to record as of this time that that's the difference. And so if we take the 15 minus the outstanding checks plus the outstanding deposit, we come up to 16256, which is now adjusted to what we have in our books. So what's the purpose of this? Now we can say this is what's on our books. And it ties out exactly to what's on the bank statement so we can double verify our entries, because we know exactly what the difference is. And the difference is exactly what we expect it to be. It's the timing differences. And if that's the case, then we've double checked our work and we've double checked it with a very strong source being the bank. And if our cash is in reconciliation, we have a much better verification and we feel a lot more comfortable that our transactions are correct. So whether you're a large business or a small business, if you get the cash reconciled, that is a huge check in order to verify the books. So obviously, we can see that this ties out here, it ties out to the general ledger, and it ties out to our ending balance on the trial balance. All right, so we are now able to describe what a bank reconciliation is perform a bank reconciliation, make a needed adjustments to our books in the reconciliation process and record adjustments.


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.  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.  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?  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?  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?  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.  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?  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.   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?  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?  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.  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?  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 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?  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.


Hi everyone, I'm Joe for jaspyscasebreaks.com.  Take a look at our videos. Our last thing today is going to be a quick little flashback pack break and a chance for you to win four mixer spots at the baseball mixer that's currently on the site, jaspyscasebreaks.com. Chance to win four of those spots, that'll happen with Jason on Sunday. But first we're going to do the break first and then we'll randomize the names from the list and then we'll see if you get mixer spots, top four get mixer spots. First big thanks to all of these folks for filling it. I think we might have to do a couple more of those tomorrow and then some spots straight up and then we'll be in breaksville on that mixer. Nine times for each list, five and a four. One, two, three, four, five, six, seven, eight. All right, we've got John down to Tony for the break, nine times for the teams, two and nine. This is just for the pack. All right, Mets down to Pirates. So this is from a fresh box or not a fresh box. We did a few of these already, but it's all from the same box unless people have been selling packs out of this box. I don't think we've seen the auto yet for what it's worth or any Luis Robert base cards or parallels again for what it's worth. All right, no trade windows for little things like this. Let's print, let's rip good luck and then Jason should be back. I think he starts at two o'clock civic, three o'clock civic and usually he's on the main channel for a couple of nights a week. So usually he goes pretty late on the on the main channel stuff. Right, right, right. The refractor would be the hit not not an auto. Autos are super rare in this, right? Thanks will Christian dozens of products jumbling up in my head and I need you guys alzalee, Buster Posey, Aristides Aquino, Shane Beaver, Lorenzo King. Nothing crazy there, but the all four of those will ship. All right, so let's grab your names again. Joseph Pugh down to Chris Boggs new list. Let's roll it. Let's randomize it six and a four 10 times top four. I said, right? Yeah, top four after 10 in the baseball mixer. How much are you baseball mixer? How much do you cost a $200 value? That's pretty nice and a old school yellow chat giveaway in that one as well. All right. So six and a four 10 times top four after 10 1, 2, 3, 4, 5, 6, 7, 8, 9 and 10th and final time. Good luck everybody. Big thanks to number five down to 30. I appreciate everyone here getting in. There probably will be a couple more of these pack opportunities to try to get into that mixer. So if you'd like, try again and congrats to Jacob, Tony, Deborah and Andrew. There you go. Congrats to you. We'll put a little, I guess we'll put flash three something like that next to your name so you know where you won that spot. Congrats again. Thanks everyone. Joe for jaspercasewrakes.com. I'll see you next time. Bye.


Hi, this is Dr. Don. I want to show you how to do permutations and combinations using stat crunch. I see a lot of students struggle with these questions on quizzes and make the mistake. The key thing you need to be remembering is that if order does not matter, if ABC and CBA are the same or equal, then you use a combination. And a combination is indicated by the NCR where N is the number of objects that we have in the pool and R is the number we're selecting. If order does matter, ABC and CBA are different, then you must use permutation in PR. So let's take a look at an example. There are 62 members of a club. Club members want to elect a president, vice president, treasurer and secretary. How many slates of officers are possible? Well here, logically, they select a president, then that person is taken out of the pool. So the order does matter. They select the president first, then the vice president, then the treasurer and secretary. So we need to use permutations to do this. I have stat crunch open. To do a combination or permutation problem, we need to use the data, compute, expression tool. And we're going to click on bill. We'll do the permutation part. So I'm going to scroll down here until I find something that looks like permutation. And there it is, P-E-R. And it enters the basic function. We need to enter our N, which is 62. And our R, I'm going to move this over, is 4. Click OK and compute. And we get that the number of slates of officers is large. It's 13.388 million different ways that we can select those officers as order matters. The second part, from the 58 members who were not elected officers, the club members want to appoint a planning committee of four who will then select their chairperson. How many ways can the committee be selected? Well, it doesn't really matter which person we select first because they're going to elect their chairperson later. So any person can be the first person chosen for the committee. That tells me that order does not matter, which means we use combination. Back in StatCrunch, I'm going to go back to data, compute, expression, build. And this time I want to find something that looks like combination and there it is, COM. And we need to enter our N this time. It's 58 because we had four people elected officers, but we're still electing four. So I'm going to click OK, compute. And you can see that we have only, it's still a lot, 424,270 ways that we can select four people out of those 58 members. So remember that difference. If order does not matter, you use the combination NCR. If order matters, then you use the permutation NPR. Hope this helps.