 Good morning, everyone. Sorry for the delay. Let's get. We are now actually at the point where we've learned enough background information that we can start getting into cool, interesting attacks. And since I know some of you are doing projects on web vulnerabilities, I'm going to kind of skip to really interesting the kind of SQL injection, code injection vulnerabilities, cross-excripting, and then we'll go back to talk about some of the other sessions, but session fixation, trust in client-side kind of vulnerabilities. OK, so we saw the architecture of a web application. A web application really takes any input from the user, does some processing, and builds and makes some SQL queries, and then issues HTML back to the web application. So we actually saw that. So where did we see mixing of code and data before? Where did we see that in that context? So yeah, the data is stored essentially in the same place that control information is stored. So the control information is like the saved instruction pointer. That tells the program where to go and what to execute. And that's stored in the same location as user data. We also, even going all the way back to, remember Captain Crunch with his whistle? The phone network also had the same thing. Your voice data was transmitted on the same channel that the control information was also passed. So that by whistling and passing things that should have been data, but look like code and commands, you're able to hack and access the phone systems. So this is why we still talk about those old phone freaking kind of things, because they're super relevant to even modern web applications. So there's actually a lot of areas, as I get into web applications, there's actually a lot of areas where this mixing of code and data causes an important security problem. And so we're going to look at, and actually a lot of instances here are just simply instances of this idea. So this is kind of what I'm trying to get across is a lot of these serious vulnerabilities are instances of this old kind of mixing code and data. So fundamentally, I try to think of this as anywhere that strings are just concatenated together and used to produce output to some other program or parser possible problems can occur. For instance, in HTTP, some cases information from the user is being used to generate maybe the location URL. There can actually be problems with HTTP. So think about what if an attacker could inject arbitrary HTTP headers into your response. All right, what kind of things can they do? HTML, right, so this is the root cause of cross-site scripting vulnerabilities is the fact that the program is fundamentally building up an HTML response by concatenating strings together and then sending that whole string to the user where the other, what's the program or parser in this case? The browser, right, the browser's HTML parser parses that page and interprets that. So we'll see that fundamentally cross-site scripting is not tricking the browser into executing your code but if it was actually the web was created in a way such that code and data were completely separated it actually would be secured. SQL, how do we see, how are SQL queries created in what we saw in our examples? Putting strings together, right? And actually, this is what's crazy, right? As PHP has a language feature to make this easier for the programmer to do, right? That string substitution feature is specifically about making it easier for the programmer to use variables inside of strings and they use that to either output to HTML or pass into SQL queries, right? This is something that they explicitly think is a good idea when really is a horrible idea. But the command line, right? What did your backdoor do in assignment one? It took user input and actually executed, right, as a command, like by calling system, right? Actually, a lot of, you know, there's a lot of functionality under your Linux system. So why reinvent the wheel and write your own code to sort or do something? Why not call it do rep and have a rep sort? Right? But here, once again, you're building up strings in order to, actually a funny story, I actually just found a problem in a program I was using on GitHub that had this problem. So I was typing in some commands. It was like a local mailbox search program. So I did this search and I put parentheses in there and then the program crashed and it was like SH error could not parse this thing. And I was like, oh no. So I looked at this code and I was like, okay, so I was like, and once I see this, I basically like feel morally obligated to tell the people. So then I had to like make the patch and then submit a chain pull request on GitHub. And it's because they were using input. I mean, this is input directly from me, the user, so it's not as severe as on a web application. But they were using it on sanitized in a command line query. SMTP, so the mail protocol, right? So web applications also send out mail if we use strengths and cabinet to send out an email. We can also see that this is a problem. And there's probably a lot more because this is a very, very common pattern. Okay, so we're gonna dig into some of these. So the first thing we're gonna look at is OS command injection attacks, right? So an idea is, right? There's no, either incorrect or no validation of user input that results in OS commands being executed on the server. So how do we do this in the binary world? What characters are we looking for? And what was kind of the malicious pattern we looked for with binaries? Habitacks, you're tricking the system by manipulating the environment, right? But traversal, okay, so you can make it go to different places maybe. Not one of these examples, there was, oh, I think that's right. That will have two solutions, so that was the problem. So what happens, so we saw the sign in one, what does the system command do? Executes it as if it was done by slash bin slash sh dash c. So it does all the command line parsing that we're used to there, all the parsing that batch does on the command line. Separates by spaces, does double equal signs, right? What does it do when she's back takes? Yeah, you can run any command in the background. It says run this command first and then use this output here in the parameter, right? So if the program is actually creating code that looks like this, then they're using our input to call system, then potentially we can make it do whatever we want and execute arbitrary commands. So let's think about this. So from a attacker's perspective, right? Why is this, so think about permission. So what permission sort of security perspective do you have when you're interacting with the web application? What can you do? Read what content. You can interact with the web application, right? By reading the content. Do you have a local Linux account on that machine? Do you SSH to it? Usually not, right? It's on the else's, right? So all you could really do, the permission should be, you should be able to do whatever the application allows you to do and interacting with it. So let's say now we have an OS command injection vulnerability and now you can execute arbitrary commands. How has your privilege expanded? Have you actually gotten your privilege expanded? Right, now we had very, we started with very remote access, right? We're interacting with just a well defined application. We can only do specific functionality that that application let us do. But now we have local access. Do we have local root access? Probably not. We're probably executing with the permissions of the web server, right? Which if you've done some web administration or Linux server administrations, this is why the web server runs as either the nobody or the WWW user, right? So this way, if this happens, they're not root on your machine, right? But we can use that local privilege, that local command execution, right? So let's say we find out as somebody did on the older version of this, the 545 server, the binary server that, oh, it's actually running an older kernel, which is vulnerable to some privilege escalation vulnerability. So now I can leverage this command injection to get local on the system, then download arbitrary C code, compile it, run it, and then that gives me a root on the system. Now you can do anything I want on that system. Also think about it, so who has permissions to talk to the database? Like, do you directly as an external user, can you talk to the database? Often times not, you don't let the users talk to the database. Who's talking to the database? The web application. And then when you have a command injection vulnerability, what are you executing code as? The web application, yes. So you can make connections directly to the database, right? You can also read everything to the database that the web server user can read. So the web application, where are the credentials stored to talk to the database? The database itself is set by one place, but how does the web application actually like connect to the database? Yes, right? It's gotta be in some, it has to be, the web application needs to know how to connect to and log into the database, right? So that means that password has to be either in a configuration file, or maybe it's set up that that Linux user can access that, right? But fundamentally, now if I can execute code as the web application, I can read that file, right? The web application must be able to read that file therefore I can. Now I can access that password and log in correctly to the database and do whatever I want to the database. Or whatever the web application could do with the database I can now do. So this is why these things are such critical vulnerabilities, right? Especially this command injection. Now I can have remote code execution on your machine as that web application. I can use that to launch and leverage all kinds of attacks. So the idea is that what happens is the web application uses unsanitized input from the user to create strings that are passed to a function that can either evaluate code or include code from a file and this could be a language specific thing. So we actually saw that system, right? So the classic system type vulnerability, right? That occurs even in binaries also occurs in web applications. It makes sense from the developer's perspective that I'm just using this local system utility, right? I want to maybe log something, set the cron job, I don't know, whatever it is, right? This also includes eval, right? If a language like PHP allows you to evaluate a string and turn it into code, right? This allows us to execute arbitrary code. P open, so we saw it's similar to system, right? P open will execute a process. Even seemingly innocuous things, right? Like include. On PHP include means go grab this file and include it as PHP code, right? What if we saw some features, right? We saw that PHP A will, so this is a runtime include, right? It's not hard coded by the developer which means that it could be influenced by the user, right? It's actually very, developers see this power of like, oh, I can pass in which file to include based on the URL parameter. Like this makes my website so flexible and beautiful in general, right? Because now I'm just adding a new module by creating a new PHP file. I can just link directly to that module and code like looks the same. But they don't realize that the attackers can leverage this, change this and get this to execute or include arbitrary files. Same thing with require. And to make these even worse, right? There's features of PHP that makes these even worse, right? If the website has the FGRL open, we can actually pass a remote website which that code will be downloaded, executed and ran as PHP code in that application, right? And that code that's being executed has the same permissions of the web application. So we can do anything that web application can do. So let's look at an example. So let's say we have some CGI, some web application program that does a CREP over some server file using the user input as a parameter, right? So one way to do this would be CREP for this in the phonebook.txt. So let's think about this. Will we come across this code? What can we do? What are some of the attacks we could leverage on this? Use your attacking hacking brain. You don't have to be correct either, it's okay. Make our own CREP. What do you mean make our own CREP? Let's change whatever is looking for CREP and then we go on with CREP. Ah, change wherever is looking for CREP. Where are we at this point? So where are we, the attacker? This is a website, a PHP script that does this. Where are we? Yeah, we're remote, right? And even if we were on the same machine, right? I can't change your path, right? You can only change your path and then execute a set UID application, right? So here, I can't change the path to make the correct point to anything else, yeah. Use a semicolon. Use a semicolon? We have to do what? Command with a command of your choice and then that outputs to standard out as well and then probably get the results. Yeah, so I've been incentive for expression, right? If I can control that, if I do a semicolon, a new command and then another semicolon, it will execute that command in addition to whatever happened here, right? So then I could change the path to do whatever I want. Then I can download a PHP, a remote shell PHP application to a certain location. I can try to add myself to the SSH authorized E file. I could try to change, what can I do? Could I change the password of the user? I think I could change the password of the user. Maybe, I don't know, what else? Was there any other contacts I could do? Yeah, so you can also use back takes, right? In addition to semicolons? Actually, you could go for rightfulbook.txt. To do what? Just change from numbers. Change from numbers, yeah. Yeah, right, so we could even do things like, yeah, so actually this is kind of a super malicious one. We're texting foos, we're gonna grab whatever, then we're gonna email to us the ETC password file, and then we're gonna remove phone book because we're kind of gritting the hackers. So let's say they go, okay, well, ha ha. I'm a better developer. I'm gonna add quotes around my parameter. So this is when you're doing batch scripting, right? This is, you put quotes around it and it should fix all the problems. So now, how can I exploit this? Use a double quote? Yeah, so I can use a double quote first to get out of that first double quote and then put whatever I want and then make sure I have another double quote, right? So now here, I put double quote, right, then foo, then mail, and then the RN, right? Now here, I've stolen the password file and deleted the text file. So what if they changed it to like this? So this is the PHP system function. So it's slightly different than the underlying OS one. So what's the big difference between these two invocations here? Right, so we are cool. So how many parameters are being passed in? How many parameters are being passed to grab in the third implementation? Three, four, our view zero, our view one. We'll say three, right, for all purposes right here. How many are being passed in the second and first one? Yeah, we don't actually know, right? We don't know, system has to figure it out because we are just drawing a string in the system and being like, you figure out how many parameters and what they're supposed to do and what the order is and even which program to execute, right? System does all this work to figure it out. It essentially is parsing this string, right? Here we are giving one string and we essentially concatenating our expression in there, right? But here, now in this third one, we've pre-parsed it, right? We've said, okay, the program is grabbed and the second parameter is to use the third parameter's expression and the fourth parameter is foo.txt. Now, obviously I have to look at the documentation to see exactly what this system does but it's the same as execve in that it does no shell parsing. It does not parse anything, right? So now by getting rid of this parser and doing that work on our own, we're able to use a secure version and say, look, just do this, like only do these. Now it doesn't matter what you put in for expression, right? Well, it will only be passed in as the second argument to grep. It's not going to be parsed for backticks or semi-colons or anything else, right? But is it secure? I don't know, what else could you do here? Pass it in on flags? I don't know what you can do with grep. Yeah, so, huh? Time to man grep and see what you're doing. Yeah. Yes, I tried too well, good. Yeah, so you can look at grep and actually you can figure out if there are any other parameters to pass in here, right? One thing specifically you can do with grep is you can do, because grep does, what do they call them, extended regular expressions, right? So you can have regular expressions that do backtracking. So with that, you can actually, because I'm controlling the regular expression to be used here, right? So I can make this grep do this really complicated backtracking regular expression and cause a denial of service attack on this application. And I can make multiple requests at once, right? And all these cracks are running in parallel and doing all these backtracking. You can also explore the file system. Fundbook doesn't have to be the file that it looks for, since it's based on that, so you can have, you do an expression with this base and then provide your own. Ah, but if I add a space here, does that change the number of parameters that are being passed to grep? Just don't check for that. It does not. So it passes it directly to exact VE, basically. So it's passing, you would pass in something space, something as the third, second parameter to grep. I would take those four then and pass them all in to exact VE as arguments, you wouldn't. No, it passes it directly like this. It's basically just a wrapper around the exact VE when you do it like this. So it's not gonna, it doesn't parse any spaces, it doesn't parse something, it doesn't parse backticks, it just passes whatever this is as the second parameter to grep. As Rv2 or something, or Rv3, right? So the space parsing comes in when creating the Rv vector to pass in the graph. It effectively creates its own quotes around it. Yes, yes, and does it in a way that you can't get out of them? Yes. But there could be tricks you can play with. Yeah, I'm not sure exactly if you pass that file here. There could be other ways maybe we could get it to read other files or something. Or actually, there are some functions like the find function. Did anybody do this like this? One of the levels had the find command. It sanitizes fairly well, but there's a dash exec option on find that allows you to execute things. So grep has something similar, right? None of those are backticks or whatever. That's like functionality in grep that's telling you to execute this thing for me. Right, cool. So how do we prevent this? Do we just never use commands, other operating system commands? That should be kind of a valid idea. The doctor does just like that, my elbow hurts. We'll stop doing that. So it really comes down to sanitization, right? This is fundamentally the problem is I'm using this data in an command injection or in an operating system command and I haven't properly sanitized it to be the parameter to a command. You should never trust outside input, right? When composing this command string, this is really the fundamental problem. And many languages actually will provide built-in sanitization routines. So like PHP has escape shell arms, which adds, so, but this is where you can get into some weirdness, right? You have to understand exactly what it's gonna do because it actually adds single quotes around a string with what it returns. So then you can use it directly in a query, in a OS command, right? Without any further sanitization. Some of them will assume that they're inside double quotes, so you have to make sure you put double quotes around them. So you just have to be very careful about the languages. Escape shell command escapes any characters in a string that may be used to trick a shell command and SBR trick commands. This is actually really cool. That's like a lot of characters, right? And FF, okay. Questions on command, OS command injection? Okay, so file inclusion attacks, right? So we actually saw a PHP that a lot of web frameworks and languages, right? They want the developers to write modular code that can be reused, right? And abstract and to refactor code into a shared library. But the problem is if this is not configured correctly, then we could maybe inject attack code into the application. So for instance, actually a common thing that happens is, so from the developer's perspective, well, okay, so if I want to include, you know, something from a parameter, whatever, right? The problem, actually one of the big things that happens is if I can upload code and get that code to be included, right? Let's say you have an image upload system that uploads to an uploads folder, right? So normally, so let's say I don't have this FURL open so I can't pull remote code down, right? So I can only execute things that are in your file system. You also are being safe, or I can't do directory traversal and go somewhere else, right? But if you allow me to upload something like an image, right, and you're not checking that it's an image or anything like that, I can upload a PHP code as an image and then get your other code to include that file and then that would execute that code. If I do remote code, then that makes my job a lot easier, right? All you gotta do is provide an EUR, I'll download and execute it, that would be pretty sweet. Or if I can somehow influence the path that's used to locate the code component, right? So this is by default, let's see, does it use the path? I don't think so, but it may build up the path by concatenating strings together, so then if we can control one of those strings, then we can influence where it's gonna go. So if we look at PHP, the allow URLF open directory that we looked at allows us to use URLs and includes and requires. And so even when, so yeah, we can execute basically arbitrary code. So this would be in some PHP code. Here we have an includePath, so we're gonna include everything in slash includes that we include includePath.library.php and in library.php we include includePath.math.php, right? So this is chaining another vulnerability. We'll say we can control this includePath variable by setting it in the parameters here. I actually skipped over this, this is something we're gonna come back to, but this is the PHP registerGlobals feature. So this is part of the reason why it's so dangerous is with registerGlobals, I can directly access library.php, because there's no restrictions on that. I can access any file as long as you allow me to. And then I can, with registerGlobals, I can create an includePath variable from a getPranker. So here this would include evil.com slash math.php, it would go fetch that code and execute it on the server as that application. All right, so the next one, the other really important vulnerability is SQL injection, which falls under this umbrella. So, and this is, okay, so SQL injection is a very well-known vulnerability. I don't know if you've heard about SQL injection vulnerabilities. Yes, I mean, obviously from the last of the projects and stuff, but even outside, right? So at the very beginning, or I think when we talked about ethics, I talked about Albert Gonzalez and his hacking crew, right? They had hundreds of millions of credit cards and they did it using SQL injection vulnerabilities as part of that, I wish I could take that. There's a great American Green episode about him and his crew and they had this great like SQL injection that like scrolls across the screen all the way. So let's walk through. So the basic idea is any, a SQL injection vulnerability can occur any time user input is used unsanitized in a SQL query, right? As we saw a SQL query, the SQL parsing engine gets just raw bytes, a raw string and tries to interpret that as a SQL query, right? It's exactly the same thing that happens with system, right? The system call sees a string and has to parse it and interpret what you mean and what program you wanna execute and how many parameters. The exact same thing happens with SQL. And remember, we gotta think about all user input. So here we're talking about a login form on a page but it could be parameters, URL get parameters. It could be your user agent. It could be the cookies that you send. Anything that comes from the user is untrusted, right? And could be a potential vulnerability. The form, the code in the form, we have just a post method to a login page. We have a table, we have a username, we have a password and then we have a submit button, right? So on the end, on the server side, our login page has some code that looks like this. So it has a login function. It takes from the request.form. So this would be from the post request, get the username name, right? So this would get when this form's posted this, that's in here, name equals username. It's gonna get the password for the same thing. It's going to create a record set object. It's going to build up the SQL query, right? So everybody see how it's concatenating? And this one makes it a little more clear, right? It's literally concatenating strings together. Whereas in a PHP's example, they were implicitly concatenating strings with the string substitution. So here we're selecting all from our table where username is, and you see how we have ticks, right? We've done single quotes right here and concatenating username and password is being concatenated as well. It should probably be a semi-poll in here too, but not for us, I'm sure. Then this line actually performs the query. So it opens the connection, it makes the SQL query and then we check, hey, if this did not return anything, then close it and say access denied. Denied, you're kind of talking to my web application. Otherwise say, yay, access granted, everything is good. So if the database looks something like this where we have usernames and passwords, right? So one thing we can do is we can use what's called the tick one equals one technique. So the idea is that, right, this is the string that gets passed to the SQL engine, right? And the important thing here, right, is what are we constrained as attackers as to what we can use for characters for username and password based on the code we just saw? Nothing, we can use anything, anything we want. Can we use no lights? I don't know, it depends on the language, but sometimes we can, in PHP you can, which is kind of cool, but may not help here, right? But we can use any characters we want here and they will be concatenated with the string and pass to the SQL engine. So the idea is what happens if we do tick for one equals one dash dash? So A, what does the dash dash mean in SQL? Comment? Yeah, so this means from here to the end of the string consider everything else a comment, right? And so what does this tick effectively doing? The one single quote? Closing. Yeah, it's closing the previous single quote here on username, it's actually kind of hard to see here, it's a single quote and then double quotes, right? Because this double quote is closing the end of this string, right? So this is the other thing we're parsing and just yourself looking at this and knowing what's going on, right? So the double quotes, the double quotes are not part of the SQL string, they define the ASP string, right? So the idea is here, right? I can put whatever I want for you, I can put this specific thing as the username and anything I want is a password and it will select star from essay table where username equals single tick and tick or one equals one dash dash tick and password equals double quote. It will not include that double quote, it will be a single tick, right? So how is this, so remember these vulnerabilities are all about parsing, right? So how does the SQL engine parse this query, right? So this or, is this or part of the username that it's gonna check for? What is the or here? It's a SQL keyword, right? Or it's, we're doing a condition we want where we are querying the essay table and we're looking through a row where the username is empty, right? Or one is equal to one. What is one equal to one, by the way, true? True, true, true, right? It is always true. So this will return and then, right? The double, the double dash does what? Ignores everything else. So why is this important? It removes the end condition and the password text in the SQL query. Yeah, so it removes the and clause from our SQL query that the developer intended, right? The developer intended for there to be a where clause and inside that we wanted one and statement with username equals something and password equals something else, right? What else does it help us with? Where does this tick, right, after the double quotes come from? From us, from the username? From which string? From which string? It's the SQL string. Yes, the SQL string that's embedded in the application, right? Can we get rid of this? No, this is always going to be put here, right? Everything after username, this is all constant up till password, right? That is something we can't control, right? So the double, the comment is actually very clever. It's like me to say, well, we don't care what goes after us because if we didn't use that, we have to make sure that our resulting string was a valid SQL query, right? If we didn't have the comment, then we could just, we would have to make sure that double, that single tick matched another single tick so we have to maybe add another clause, you can do it, but it's a lot easier with just commenting out the whole line. So the important thing is that it comes back to parsing. The SQL server parses this query, it sees this query, it parses it as select star from SA table where username equals, single ticks for one equals one, right? And it's, the one equals one is always true, so this is gonna return every line in the database, right? Every row in the database. It's gonna return every row in the, sorry, not in the database, in the SA table, right? And so this will actually allow us into that application, right? We could put this in as our username and it's gonna log us in into this application probably as this first user in the database. This is kind of the basic primitive, so this is an example. So the idea is, it's all about transforming SQL queries, right? And we have to remember that we can't control the string, right? That happens before our injection, right? So like here where they were injecting to the username parameter, right, username variable, this means we can't change any part of this query, right, what happens before. Because this is constant, right? It's not like we can put like a backface character to make it like try and go backwards, right? We can't do that. So this is what we have to work with. So there are different types of queries, right? We talked about different types of SQL queries. So what kind of SQL queries do we have? Yeah, those are like high level operations, the credit operations. Yeah, so we can select, right? We can like select star from accounts where user is equal to U and password is equal to P. We have insert statements where you can say insert into accounts where user pass where the values are U and P, right? So here, right, we saw the select statement so we can modify the select statement to return arbitrarily many rows, right? Or change the where clause, right? We can insert it. So what happens if you can insert, let's say this user here, like into U and it's insert. What could you do? You have admin access? Yeah, it actually kind of depends on the application, right? So here, we can actually just create username and password. So it's almost like, I can't do much here because what are you just gonna add? You can already, if you can create the account already then you can create as many accounts as you want, right? There's nothing stopping you from doing that. But let's say there was, this query was concerned to accounts user pass is admin, right? Which would be zero or one. And by default, the application would give you a zero because you're not an admin, right? But if you could inject into the U parameter, you could create a new field here in the insert statement, comment down the rest, and you could set yourself as an admin. A tricky thing here from the outside, if you don't know what command is being executed, you have to make sure that the number of parameters in that insert accounts, right? Here it's two, user and pass, matches exactly the ones you inject. So this is kind of a little tip for when you're doing this in a black box manner and you don't know the source code of the application. Update statements, right? So you can update accounts, set password, where username and password, right? So this would be pretty handy to inject into, right? You can arbitrarily change any of whatever you want. I can update the admins password to whatever I wanted it to be. And delete, would it be cool to change the delete? What if we did a tick one or one equals one in here? That would be probably not great. I mean, I don't know what our goal is, but I would think that we would, nine times at a time, you want to either steal or change the data, not delete at all, yeah? Is it possible to use semicolon to combine together segments? Yeah, so what do semicolons use for in SQL? What was that? Yeah, so term it state and separator, right? So you can use this, the answer is it depends on the engine. Lots of, the PHP ones, I think by default allow that. There's other things, I think Python, the pymySQL bindings do not allow that. If you're opening a cursor or something. Yes. But it's easier usually on the exact, like on the insert update and delete. Yes, you can, exactly. You could do that in here and then for the semicolon, you can do whatever you want. You can execute any arbitrary query. Okay, oh, so good, yes. So, good thinking, right? So you can use semicolon as the SQL statement separator. And so if you can use this, then we can say, well we can actually change the select statement to select star from table where username is ticks, semicolon, insert into essay table user password values add on a test, right? So here now I'm able to insert into that and you can see here in gray, right? The query automatically appended the tick and password equals double ticks. So what can, so what is, what's, think about the severity of the SQL injection vulnerability for a second here, right? Why is it so bad? What does it allow an attacker to do? What's that? Create new accounts. Create new accounts. Yes, think about a high level. So that would be like inject data. Is the application right? They've injected out of your application. What else? So you can do what? You can do anything on the database, like once you get access to the database. Right. We're trying to say what kinds of things. So add data, modify the data. Just modify the data. You can do system commands most likely. Depending on the database, some databases, yes. You can actually execute system commands. Which are very scary, yeah. Can you use joins to kind of do data service? The long period. There's a lot of joins. Ooh, that's a tricky one. Yeah, you could do us the application by making the SQL server do a lot of unnecessary work. That'd be really mean. Yes, and you can delete data, right? So at a high level, right? Add data, modify data, or delete data. What if just reading something? Or reading data, right? What if it's the database of credit cards? I don't want to object to a new one. I want to read all that data. And SQL is actually a really powerful language. It has a lot of functions, normally. So you could actually, because you think a lot of organizations, especially credit card companies, will look at all the data that's flowing out of their applications, right? And see, make sure there's no, that none of the data passes like a wound check, which is the thing that identifies your credit card number, right? It has to pass a certain validation. So actually checking all of this. You can have SQL, like, encrypted, move. I mean, I actually think you can have encrypted. You can also have it, like, just exhorted with As, or, I don't know, anything you want. You can have it transform that data so it no longer looks like a credit card at all. Yeah, so, okay, let's compare it briefly with command injection. So is it more severe, less severe? If I told you you had one vulnerability, right? If I told you you had both, but you could only fix one, what would you fix? You quit because you went on work or something like that. But as a theoretical exercise, which one would you prioritize fixing first? Was that command, why? The access of that. User level, so I can get to the database and execute any database commands that I want to execute. Yeah, exactly, right? So this is why command injections are usually considered more severe, right? I mean, SQL injections are really severe, right? But everything I can do with a SQL injection, I can do with a command injection. Right? But the reverse is not true. Right? With a SQL injection, I can't assume that I can execute arbitrary commands. I can't add user accounts. I can't, I may not be able to even, I can read that in the database. What if there's like files on the file server, right? I may not be able to read those necessarily with a SQL injection. So thinking about how those two are related, right? So, command injection is like way worse, right? But SQL injection is still really bad, right? Even if I can't execute commands in your server, what do I care? I have all of your data, right? I have all of your user accounts. I can start cracking username passwords, right? I can try looking, if you have the emails of those users, I can try to crack those passwords and I can, some percentage of those users are gonna be using those as their Gmail passwords. Now I'm into people's Gmail accounts, right? Just by hacking some random site. So yeah, so this is why this is one, so in terms of like, criticality and severity, severity, you can see it's actually incredibly easy to have a SQL injection vulnerability, right? You just kind of forget to quote something. It's incredibly simple to have occur, but it's a critical and severe vulnerability when it does occur. And so, in terms of that and cross-site scripting, which we'll get to on Wednesday, cross-site scripting is a little bit less critical in the sense that they can't access all your data, but it's much more likely to happen if there's just so many more cross-site scripting vulnerabilities. So great, all right, let's stop here and we'll come back to this on.