get a successful login quicker and gain access to your application. So let's attack this page and we'll see what rate limiting exists, if there is any, and see why rate limiting would be helpful. Now I could try attacking the login form manually by submitting usernames and passwords myself and going through multiple combinations to see what comes through. But this is a web form and it's quite easy to automate, so there's no point doing it manually when we can automate it and use a script to do it. Okay, so we're in the command line and what I'm going to do is use a script that I built for user enumeration on Laravel login forms to attack the login form and see what sort of throughput we get and if we can find a working password.

for user enumeration on Laravel login forms to attack the login form and see what sort of throughput we get and if we can find a working password. So this is the command, spirit attack login, and then we've got there the URL of the login form and then the user email address that we're attacking. So I run the script and it's going to go start doing its thing. So how this script works is it first hits the login form and it grabs the CSRF token, so the cross-site request forgery token. And that is important because we need to send that with our POST request, otherwise the POST request will be rejected. And we also grab the POST targets, which is where our POST request is sending, and then

the POST request will be rejected. And we also grab the POST targets, which is where our POST request is sending, and then we can send that to, we can send our login request to that POST endpoint. And so I'm sending through the CSRF token, the email address, which we have in the command at the top, stevenaresecarla.net, and we have the email address that it is trying, sorry not the email address, the password that it is trying. So it's conducting an attack and it's got 1000 passwords in the password list that I'm using, and it's going through each of the different passwords and attempting a login to see which passwords work. And when it finds a working password it'll stop and it'll tell us it's found the working

of breaking into accounts when the User isn't aware of password security. And this is why rate limiting is critical for this sort of application, for login forms I should say, and for anything else where you're trying to, when you can guess or infer information and you have a list of information you can infer to. Because you can go through all the different combinations and try them, and without rate limiting you can try them really quickly. So let's enable rate limiting on this site, on this login form, and we'll see what sort of difference that makes. Okay, so here we are in the code, now I used Laravel Breeze to set up the login form. So this infrastructure is from Laravel Breeze, but I'm just using it as the demo, I'm not

Okay, so here we are in the code, now I used Laravel Breeze to set up the login form. So this infrastructure is from Laravel Breeze, but I'm just using it as the demo, I'm not trying to show a vulnerability in Laravel Breeze at all. So I had the rate limiter disabled, so I'm just going to re-enable the rate limiter components, and I'm going to change the attempts amount to 60, which means we're going to attempt 60 different passwords, sorry, it's going to allow us to attempt 60 passwords per minute, per request, no, so per minute on the login form. And so we've got the rate limiter enabled up here, just check it's all good, it is, I'm going to save this and go back to our command. Okay so we're back in our command line, and I'm going to run the command again, and now

I'm going to save this and go back to our command. Okay so we're back in our command line, and I'm going to run the command again, and now that we have the rate limiter enabled, we're going to see what difference it makes to the timing. Granted, we know the rate limiter we've set, which is 60 attempts per minute, so we should be seeing a pretty predictable response come out, which would allow us to have 86,000 requests per 24 hours, because of the mass of the 60 attempts per second. But again, we just want to let it run through to show you the difference that using the same password list has when you have rate limiting on the login form. Okay, the script has finished running and we now have the password, but this time it

same password list has when you have rate limiting on the login form. Okay, the script has finished running and we now have the password, but this time it took 250 seconds to check, which is what we would expect because the rate limiter kicked in four times. If we do the maths from that based on 60 attempts per minute, we can do 86,000 passwords in a day on this script, as opposed to the 384,000 passwords. So it's significantly less, but it's still quite a lot of passwords that we can check, and it still provides a sizable chunk of non-reused passwords that we can check an account on, so it is still a problem. So let's go back into our code and we'll set the rate limiter back to the default that

account on, so it is still a problem. So let's go back into our code and we'll set the rate limiter back to the default that comes with Laravel Breeze, and we'll see what that does. Okay, so we're back in the code and this is the limit that we set before, which was 60 requests per minute for our rate limiter, which, as we saw from our test, is far too many. So I set it to 5, which is the default that Laravel Breeze comes with, and we'll go run the script again and see how that goes. Now it's worth pointing out at this point that Laravel Breeze and other tools that come with Laravel, and even other third-party packages, have often been tweaked specifically with

Now it's worth pointing out at this point that Laravel Breeze and other tools that come with Laravel, and even other third-party packages, have often been tweaked specifically with things like security in mind, and so the defaults they come with, like 5 requests per minute, have a basis in security, and are there for providing a sane difference between tightening the security and usability. And we'll see what difference that makes when we run our request. Okay, so we're back at the script, now I'm going to run it again with our limit of 5 requests per minute, and we can tell this is going to take a lot longer. We've now got our 5 requests, it now says try again in 59 seconds. This is going to take a long time to check all of the 281 passwords to find the working

Okay, so here we are in the code, this is where the key is that Laravel Breeze is using for its rate limiter, and you'll find a standard key elsewhere, in any sort of rate limiting there's always going to be a key, because it has to be something that's defining the unique nature of the request. What I'm going to do is just remove this. So now what we're doing is we're grabbing the email address, and then we're lowercasing the string, lowercasing the email address, to prevent any sort of casing uniqueness check, uniqueness bypassing, and then we're running it through the transliterate function, which removes any special characters that, again, allow you to defeat the uniqueness checks. So we're passing just the email address in as the throttle key, and then we'll go back.

is under an attack, and there are other mechanisms that you could put in place there depending on your application and what you need to do. So that was Laravel Breeze, which provides a great example of rate limiting for login forms and how that's set up, and it comes out of the box, you don't really need to think about it. But if you want to do rate limiting in other areas of your app, then you have to set up the rate limiter yourself. But there is the throttle middleware, and let's have a look at that now, and I'll show you how it works, so you can use it for other routes that you need rate limiting on. Okay, so we're in our HTTP kernel, and as you can see here under route middleware near

you how it works, so you can use it for other routes that you need rate limiting on. Okay, so we're in our HTTPKernel, and as you can see here under route middleware near the bottom, the line that I've highlighted, we've got the throttle requests middleware. And this is a rate limiting middleware that you can use easily on routes to add rate limiting in place. So it's aliased as throttle, and then if we go up here and look under the API middleware, we can see we have this here. So by default, API requests are all throttled using the rate limiter in Laravel, which is great because for API requests, you want to limit the rate, otherwise they could send so many requests to your application, it takes it down.

great because for API requests, you want to limit the rate, otherwise they could send so many requests to your application, it takes it down. So from a performance and integrity point of view, you want some form of throttling. But how do we configure this? How do we set the different levels of want to make it to be a same level? Because we don't want something that's really tight for an API, we may want the users to be making like 150 requests per minute, and that might be acceptable, it might be supported by our application. So to manage this throttling, this rate limiting, we can jump over to our RouteServiceProvider. And in the RouteServiceProvider, we have a method here, configureRateLimiting, and

So to manage this throttling, this rate limiting, we can jump over to our RouteServiceProvider. And in the RouteServiceProvider, we have a method here, configureRateLimiting, and this is where you define the different rate limiters that can be used for the middleware, the route middleware, sorry, the throttle middleware, I should say. So what we're doing here is rate limiter for API, so we're giving it a name, so we're saying this rate limiter is called API. And then in here, we're defining the rules. 60 requests per minute is the allowed rate that the API can support. In our example before, I said maybe you want 150 requests per minute, and that's fine, you can change the number, it's really easy, as long as it's something that your application

In our example before, I said maybe you want 150 requests per minute, and that's fine, you can change the number, it's really easy, as long as it's something that your application supports. And then by here defines the key. So what we're saying here is we're grabbing the userId, so if the user is logged in, then it's going to use the userId as the rate limiter key. So it's going to ignore the IP address, and it's just going to use the userId, which is fantastic from, if the user has multiple servers from different IPs making requests, it's going to rate limit across all of their different requests for their whole account. And if we don't have a user, it's going to fall back to the IP address.