Hello and welcome to Secure JavaScript programming with Vladimir De Turkheim. In this video, we will talk about injections in Node.js. If you build a serverless JavaScript application, you are very likely to use either a NoSQL or a SQL database to do things maybe with fights and maybe we shells. In this video, we'll focus on string injections. If you're interested in learning more about MongoDB injections in Node.js, you can check the criticisms that topic are digging to make conference talks that are all online on the topic. Injections are actually still the first element of the OS top 10 in terms of security issues. If we check the top 10, so first one is injections. That's as a single vulnerability that it is considered as the most dangerous and impactful in the web application world. Now, because examples always work better, let's start with the secret injection. Here I've got a website where you can access blog posts by their ID. However, usually when you see this thing where you can just change an ID and get a different contents. Here you've got a title, the content of the blog posts, the first name of the author, the last name of the author, hackers, will try to inject into it. One easy way to start injecting is to do something lake union select star from users. Here we get an error message. That's actually very interesting. That means that the injection works, but that we don't have the right number of columns. That as a SQL query we injected had two subqueries with different outcome of columns. The thing to do in that case when you are a hacker, is to count the number of entry you have into dataset. You've got title, content, first name and last name. Full. We'll retry an injection. We select 1, 2, 3, 4 from users. Here, as you can see, we've got a new record which has title 1, content 1 first name 1, last name 1. That means that we are going in the right direction. Now, let's try to do first name. You have much more that into it with lot of first name and last name. That's actually dropping us the world author correction. Maybe they have an e-mail. Here you see, I'm guessing with keywords, but in real life you would be using a tool name, SQLite is a database that would actually runs injections for you and drop the contents of the database and displays the contents of the database. Here we have started to leak the first name and the email of all users into database. But that's actually very problematic because that's what's called PII, for personally identifiable information. Meaning that if this vulnerability happens and that EU citizens are impacted or California resident, well, you are in for big trouble because each legislative system has created a lot of penalties through GDPR and CPA for people who let personal information leaked. Why is it vulnerable? Well, it's vulnerable because here we've got a SQL query, and the parameter into it is actually concatenated. It's not what we call escaped. I will show you how it is done in a couple minutes. But the parameter is actually concatenated, meaning that when I want to run for a single blog posts may SQL query becomes select. All of that. I'm at the bottom of the screen from first as first then I join under the user table where first equal ID equals one. Here is my injected part with email and first name being stolen from the user table. That's actually very problematic because in a select query, it's possible to union and therefore access all their data. In queries that have side effect under database like creating or updating stuff. Well, it will all delete it. Well, it will mean that someone can't tamper with the condition and won't type literary data in your database. It's actually very bad. Thankfully there is one easy way to fix it. Your tags are parameters that has been concatenated and you replace it by a question mark. Here in the call, choose a database driver, you pass it as a second parameter. If you want to put other ones, you would pass them as extra parameters in this array. That tells the Sequel driver to not consider anything that's replacing this question mark as executable code, but only as the trolls. Now, if I rerun the same thing with the attack, the attack is just ignored and we just get the elements with the 81. Those are very interesting secret injections, and you can check the SQL injection course on Infosec if you're interested in that, it's called blind SQL injections. Here we've got another endpoint that actually it doesn't return really data, it returns number. What's interesting is that actually it's injectable and you can make it lie. If I write two or one equals two, it will return something, but if I return one or true or one equals one it returns something else because it becomes a tautology. Because these [inaudible] tells me, return me the item with ID two or one equals one, which means all items. If I put end here, it will only return this, and if I put something that's false, it will never return anything and actually, it will crush. It's even 404. The interest IS 404 because I've got this. It's interesting because using timing attacks, a hacker can actually tamper that, when we place to our one equals one, the query will become something like that for instance. But by doing timing attack the user could do things or author that email like and then puts a regular expression. Byte by byte, I would be able to detect, because this will return true or false. 20044 would be able to detect the world contents of the database. It's very advanced attacks that are done through automated scripts, but they are brilliant. Once again, the solution is actually to remove this and make the parameter escaped and we're protected against SQL injections. Second kind of injections I wanted to show today, was Path injections. It's actually very common for a web server to have access to things under fake system. For instance, when you serve a static website, from your back-end website, when you have both in a single process. Well, it's very common for your server to have access to the file system and to be able to save files from the file system. These once again is injectable. Let me show you how. What we want to do is we want to access into the Directory File and Print secret that takes, usually to prove that when we go to../,../,../, ETC/ password. But since this is a recorded video on my personal laptop, that's not going to happen. The naive way of doing that would be to do../files/secrets.txt. That will actually fail because the browser and the server don't want to interpret these as a real path because of the slash. They won't, interpret this as a parameter. When you don't know how to inject something in a server, usually the ideal way is to HTML escape. To escape components, encode it. That's what it has been done before actually. We do this and this returns us an encoded string. If we place it here, we get the content of the secret file. Why is that? Well, let me add a debug point here and restart the server. When I run the [inaudible] query, the path to be read is actually this. You get pages/index.js. However, when I run the injected thing, the path becomes a full path like that with the dot slash file secret dot txt. What you want to do to be safe is actually first of all, use the path package in node.js. It's a standard package. Never concatenate path yourself. Let's find out if that's enough to protect us, Path dot Join. This method is not enough because it actually creates the path. Once you have done that, here at this point, you have the full path that is still malicious, but at least it's normalized. Now, what you want to do is to have const public path equals path dot join and we just take those two first arguments. I don't know where you have a hands. What you want to do is to check that path dot this name of file path and you compare that with public path and that's just a matter of if statement here. Here we can see that path is a path is slash page and here it's secret that TXT, because I did not use the right method. It was D unnamed to use. Sorry about that. Here you can see that they are different. You can put a check in the code to make sure that if path.direname is not as a public path, then raise end no, at tax here and of course glitter return statement. Let's see that again. No attacks here, and that's because we limited the actual path access, further Cisco okay. Last one I will show and you understand why I did not spend that much time on mongo injections. That's because we already spent a lot of time here. It's actually sometimes convenient to use shell commands when you want to run a sub-process lake a python comment, or check the size of a file under disk. Well, when you do that, you must always use just Capone comment and post a comment as the first argument and the parameters of the comment after, that will do exactly the same thing as the sequel escaping. If you use any other ones as pull, like exec, something like that. Well, the attacker actually will add access to running. It will be able to run any arbitrary script on the server. Meaning there will be able to write things to override thing, but also to access the database, to steal the enlightenment variables, pretty much everything. They will be even able, thanks to a method I developed recently and let you to Google my login path.It will really even be able to circle back cuisines on node.js process and obtain node.js process remote code injection through that. Once again, there are methods that are already escaped into runtime for you to use, just chose them. I don't know why I have frozen now, let me just as quick team to add me back on the screen. Thanks so much for watching this video. I hope it helps you. It was mostly introductions to injections in node.js that can happen in a serverless environment. Thanks so much for watching that. I hope you enjoyed the video. Have a great day.
