[MUSIC] Whenever you're building a server side code base that's going to receive data from a client, like we are in these examples where we're receiving data over HTTP from a client. And then we're going to process and do something with that data, something that we have to be very concerned about are injection attacks. And so, to summon up what this is, is when the client sends us some data, that because of the way that the client sends that data to us or formats it or some other aspect of the data or the request, we end up rather than interpreting that data as data we end up interpreting it as a command and executing something. We have to be very careful of these things because we don't want the client to be able to manipulate our execution paths and our logic on the server, or on other clients that are accessing our website. So it's very important that we always, be cognizant of the potential for the client to send us some data that causes to take some command or action that we didn't want to take or that we don't thinks is secure. So, let me give you an example using the echo servlet that we've seen in our coded samples. So, with the echo servlet a client can send a request to the server with a message that should be occur, and the server then returns to the client a message back which is the content of the webpage so its going to send echo plus the message. Now, in our example that we were using, we were sending this echo plus message back as plain text. So whenever the client gets back, it's just going to hopefully look at the content type header and interpret it as plain text. But let's assume that we were actually setting the content type to HTML, so that when the client got this echo plus message back, we could have HTML in it, and the client would display it. So you can imagine we might go and add something like a HTML tag, and then we might add a body tag, in front of our content we're sending back, and there might be a closing body tag. And a closing HTML tag, so now whenever we, the client send us a message they could provide some HTML formatting on the message that they sent to us and when I got echo it back they could make it bold or different colors whatever they wanted to do. Now the, the challenge with this is what if they make this message, some JavaScript code. So suddenly, the client is going to send us, some JavaScript code, which we are going to echo back to them. Well the challenge is now, when we echo this HTML page back to them, It's going to have java script code in it, which will be executed by the client when it gets it back. Now you may say, well then, why, why do we care about this If the client's sending it to us, why should we care about it executing it because it sent it to us so it must be okay? Well, the challenge is, is think about in this case, If we had a second website. So, we have another website and the client then goes and visits this website, and part of what the website returns is a URL to this server so a link, to the echo service. If that link encodes some java script in the message, then this website can trick the client into clicking on this link, which when they visit it will cause JavaScript to be injected into their browser that goes and does something malicious. So for example, if our server was sending private cookies or other data back to the client or maybe our, the bank balance was coming back. It wasn't just a simple page, web page but it was actually something to show them their account balance. The script that they injected into the client, would have access to all of that data when it came back to the client and that script could tell the client to go ahead and for the data secretly to the attacking website, so this is just one example of where the facts that we're taking in data from the client can lead to some type of injection attack. We want to be very careful, that whatever data we take from the client, that we treat it very, very carefully. Another one of the top types of injection attacks, that we'll talk about later in the course, is called a SQL injection attack. Where, because of the data that the client provides, the server goes off and accesses or manipulates the database in an inappropriate way. So, the moral of this story is, whenever you are taking in data from the client, you must consider this data to be highly untrusted. Even if you were expecting only your mobile client to be sending the HB request to the server, it doesn't mean that some other Entity could just directly, create HTTP requests outside of your client and send them to the server to do something. So, you always, always, always must be very, very careful and don't trust client data. [BLANK_AUDIO] You always must validate it and segregate it, and make sure that it can't manipulate your server in some way. So what are things that you should be careful of? Anytime a client is going to be sending you HTML, or some type of code that could potentially be interpreted as commands or logic. Be very, very careful of that, because that's a direct case where, if you're going to interpret what they send you as logic, then there's the potential that what they send you, could manipulate the logic on your server to do something very bad. If you're going, they're going to send something to you that you're going to temporarily store and then send back to other clients. But what you send back is going to be interpreted as logic in some way or executed in some way. Be very, very careful of that, because that's another case where they could inject some type of command data, that later gets served up to your visitors or store other clients of your website and causes attacks to be generated on them. So, always take client data and validate it very, very carefully, If there's the potential that it could be executed, you must try to sanitize that data and strip out anything bad in it. And the best approach is to only allow very certain things in. Rather than trying to go and manipulate the data after the fact, and remove bad things, or try to catch just bad things. It's very, very difficult to take data in from a client that's later going to be executed as logical commands in some way, and do that securely It's a very, very challenging thing to do, be very careful whenever you do it. Any data that you're taking from the client, if you're expecting it to be of a certain type, validate that it's that type. If you're expecting it not to be empty, validate that it's not empty. Always you know, treat client data as an attack on your system. Validate it, and then prove that it's not an attack before you do something with it that is sensitive. So, the moral of the story is anything that comes into a servlet, anything that comes into the controllers, the spring controllers that we'll talk about later in this course. Any of that type of data that comes in, you must be incredibly careful with what you do with it, and ensure that doesn't lead to an attack on you, and your server or the clients that are visiting your server.
