Final attempt. Laravel security updated. Malicious script injection detected. Blocking and purging all entries. Attempt successful. Breach prevented. Rebooting all systems. Simulation complete. Hey there. My name is Stephen. I'm a Laravel security consultant and the creator of Laravel Security In-Depth. To kick off this series about Laravel security, we're going to check some of the basics you should already be doing.

So this is a simple application that I've built that tracks the books that you're reading, and we're going to use it as examples throughout this series. So let's put ourselves in the mindset of the hacker, and we've discovered this site. So we've discovered the site. We've created an account called Steven, and we're looking around, trying to work out what to attack first. So as a hacker, the first thing that jumps out at me is the search box because it's an input.

It also means I can give someone the link that has my payload in it, that has my attack in it, so I don't need them to do anything. All they have to do is click the link, and then the thing runs. So in this case, we've got search="i". Now it's passing in a string. And one of the brilliant things about php when it comes to hacking into it is that php doesn't just accept strings as inputs. It'll also accept arrays. So if we go up here and we modify the search parameter, and I put the square brackets on,

So if we go up here and we modify the search parameter, and I put the square brackets on, that will tell php that we're actually passing in an array, and one of the values will be $i rather than a string. And so I'm going to hit Submit, and boom, we now have an error message. Now, we could easily expect this to happen because the application is expecting a string and has received an array, and so it's throwing an ArrayToStringConversion error. That's normal. What isn't normal in this instance, though,

That's normal. What isn't normal in this instance, though, is that we have the debug screen on this production environment, on this web-accessible version of the application, I should say. So at the top, here's the exception that we expected, ArrayToStringConversion here. And if we scroll down a bit, we'll see that we have the stack trace over here, so we'll expand that out, and we can look down, and we have the various different classes that are being called in the stack trace. We've got the middleware here,

and we have the various different classes that are being called in the stack trace. We've got the middleware here, all the different middleware classes that are being called, and this gives us a really good idea of what's going on in the application. We can see if there's any custom middleware that's being fired, anything specific about this application. It's going to tell us that we're running as Laravel and the stack that's going in there. So in terms of doing recon, in terms of hacking into this site, this gives us a lot of valuable information.

Not only do we have an ArrayToStringConversion problem, i.e. it's passing the string value into the string, which we're given when we're passing in the array, it fails. We can also notice the whereRaw function here, so I'll highlight that. And the great thing about this whereRaw function is that this is often where you'll find SQL injection vulnerabilities in PHP code, sorry, in Laravel code, I should say. And so when you're looking for vulnerabilities and looking for, and you will look for keywords like this. And so as an attacker, we immediately see the whereRaw.

and you will look for keywords like this. And so as an attacker, we immediately see the whereRaw. And if you look further into that string, you'll notice it actually is SQL injection vulnerable. We can inject our own code in here. Now, I'm not going to exploit this vulnerability in this lesson. We're going to deal with that in a different episode in the series. It's just there as an example to show you what we would discover if we were investigating the site and we discovered this debug enabled. So that's the source code of the routes file that we can look at.

if we were investigating the site and we discovered this debug enabled. So that's the source code of the routes file that we can look at. And we can look through them further to look for any other issues if we want to. But we'll keep scrolling down, pass through the request and the headers, which are pretty boring because we receive them in the browser already. No new routing, doesn't give us anything useful. Context here, we can see we have the User. So this is giving us the full context of the current User that's running this code.

So this is giving us the full context of the current user that's running this code. Now, this is really handy if, say, there are fields in here that the user shouldn't know. So this is my profile. All that information is information that is known to me, essentially. The profile key, it could be sensitive. We don't know. We're not sure what the purpose of it is. There's nothing else in here that jumps out at me apart from that one.

But I want to reiterate, this is only for the current User in this one. So I'll scroll back down and we'll get to the version section. And this is the interesting bit in here for us. We have the PHP version and the Laravel version. So these are fantastic for recon to work out, are there known vulnerabilities? So we can take, for example, the Laravel version, and we can go look it up in the database of vulnerabilities and see, is there a vulnerability, a known vulnerability in this version? And if there is, then we can research how to exploit it,

And we have App Environment Local. So we can see here that this site is currently set to running in a local environment, and that is a big, big problem from a security point of view because if your site is running in local, then other development tools might be enabled and might be accessible. For example, Laravel Telescope, configured to allow full access when running in local environment. And given we're currently running in a local environment, we should be able to get straight in regardless of our permissions.

And given we're currently running in a local environment, we should be able to get straight in regardless of our permissions or authentication level. Let's check it out. Okay, up in the URL, we're going to put Telescope and see what happens. Boom, cool. Okay, so we now have Laravel Telescope for this site, even though we shouldn't have access. But as the hacker, because we've discovered the debug is enabled and that the local environment is set,

But as the hacker, because we've discovered the debug is enabled and that the local environment is set, we can get straight in without authentication, which is fantastic. Because Laravel Telescope especially has a whole lot of useful information for us if we're trying to understand what's going on in this site and what's vulnerable. So let's have a look around. So first up, we have this list of requests in here, different requests that have been made to this application. We've got commands in here, different commands that have run.

different requests that have been made to this application. We've got commands in here, different commands that have run. You've got schedule, jobs, batches, cache dumps, events, et cetera. The one we're looking for down here is models. So if we go into models, we can see it tells us the different models that have been loaded on requests. Let's go and have a look in this one, app/models/Book.php. Okay, so in here we can see here model action is telling us what time it happened, the host name retrieved, how many models were loaded, and then linking to the requests that have happened in.

the host name retrieved, how many models were loaded, and then linking to the requests that have happened in. So we'll go into that request, and this is giving us more information about the request. So we can see here the method that was used, the URL, status code, IP address, keep scrolling down, and we can see here that the authenticated user was ID number 2, Alice. So if you remember before, we were logged in as Steven, but now we have a different user here, Alice, is making requests as well, and we can see the request that she is making,

and we don't want to skip the basics. If you start skipping the basics of security, you'll get lazy and you'll forget. And so we're doing this so that we can get the basics in. So let's jump over to our code. And in here, in the .env file, as hopefully most, if not all of you, have been trying to tell me to get to already, we have APP_DEBUG. APP_DEBUG is set to true, which we know

we have APP_DEBUG. APP_DEBUG is set to true, which we know because it's showing debug information. Anytime you make your code web accessible, set it to false. I know having debug mode is useful in staging or QA or testing or any of those other environments. When something breaks, you want to know what's going on. But it gives anyone who can trigger an error on your site access to your site. And they can view all sorts of information.

And the other thing that you need to do is change this value here. The APP_ENV value. Doesn't matter what you change it to, just don't make it local. Because local is the magic keyword that opens up things like Telescope and Nova. And set it to something else. Set it to staging. Oops.

We can't see the code. We can't see any of the version numbers. We can't see the logged in user. There's no useful information here beyond the existence of an error, which for protecting your site is fantastic because you're not leaking anything beyond the fact that you're not catching that specific use case. If we go over to Telescope,

that specific use case. If we go over to Telescope, which is the other place we needed to protect and refresh that one. I'm going to click that up there. We now have a 403 forbidden. So we can tell Telescope is enabled and installed, but we can't do anything about it. It's forbidden.