Thread by @valorin

I’ve recently started doing @laravelphp security audits & pentests, and thought it would be interesting to share the process I've developed for doing them.

#Laravel #Security 🧵 (Is this a thing now?)

The first thing I do when starting an audit is to run a couple of passive scans/checks on the public page of the app, and open view source (😱hacker!). These help give an idea of the security awareness level of the dev team, and what to expect in the code.

The main one is @securityheaders (securityheaders.com), but ssllabs.com/ssltest/ and hstspreload.org are also useful, and I always check for a securitytxt.org file.
Plus, if it's an SPA, I'll look things like config, routes (i.e. Ziggy), translations, etc.

With the passive scans finished, I’ll check out the code repo and start checking the multitude of config files, looking for API/auth keys, etc. It's unfortunately quite common to find them committed into the repo somewhere. 😭
github.com/zricethezav/gi… is very helpful for this!

The next step is to review the code!
I start with the routes, they give an overview of the structure of the app, including the auth boundaries, policies, ACL, special endpoints, unique keys, etc.
It's a gold-mine of information, and I'm always referring back to it. 😈

Next up, controllers!
I walk through every controller and action, looking at it's inputs and outputs. Often authentication is defined in here too.

Controllers are responsible for validating and sanitising input, and I check every one for validation rules covering all inputs.

Don't forget FormRequests! These make complex/shared validation nicer, but also hide it away so you might not notice the FormRequest object you're using doesn't have any rules defined! 😱
Custom validation Rules also need to be carefully checked.

During this whole process, I'm making notes of anything that looks exploitable or problematic. Building up my list of priority routes to check and how I may be able to compromise them.
Also nothing features with elevated risks, such as file uploads.

Once I'm finished surveying the controllers, I'll start digging deeper into the app logic. Following the paths the inputs take from the controllers - especially string and file inputs, which have the most potential for exploiting.

This includes looking at the auth context - what permissions does the user require to perform the action. I often find cases where a user can view (😬), modify (😠), or even delete (😱) records they should have no access to!

Next up, the view and JS layer. This is very dependant on the stack, but I'll usually start by looking for unescaped outputs, i.e. {!! !!} and HtmlString() in Blade and v-html in Vue.
I'll also review what data is sent to the JS, as this can often contain sensitive data.

After that point, it's time to break into stuff! 😈 😎
Using all the knowledge I've gained of the app, I work through my hit-list to see what can be exploited (on staging/testing, I never touch prod beyond passive scans).

Not everything is exploitable, but having intimate knowledge of the app really helps in finding tricks to bypass protections. I check my full list of potential weaknesses and risky areas, plus anything else I notice while testing the app.

I also look out for ways the app security could be creased, such as suggesting MFA for users, adding in password confirmations (laravel.com/docs/9.x/authe…), separating staging/testing from prod, etc.

One final thing before I wrap up:
I take note of any hardcoded email addresses, especially admin user lists, and check them on @haveibeenpwned.
And please don't put these lists in your JS where everyone can see them!! 😭

And that's basically* it. 😎

* Well, it's a lot more complicated than it sounds, but you get the idea at least. 👍

Reach out if you're interested in a security audit for your apps. 😁