Greetings my friends! We’re onto the final 2 risks in our OWASP Top 10 series, and I don’t know about you, but it’s quite exciting to be near the end! I definitely underestimated the scope of the challenge Top 10, but I hope I’ve done it justice and I’m looking forward to using this as series a reference in the future. Note, if you’ve missed some of the past emails, you can find them all linked here.

💡 Want me to hack your apps and help you secure them? Book in a Laravel Security Audit and Penetration Test! 🕵️

Looking to learn more?
⏩ Security Tip #11: Default Password Rules
▶️ In Depth #4: Guessing Placeholders

A09:2021 – Security Logging and Monitoring Failures

The title of risk #9 should be pretty self-explanatory, and we’ve touched on Logging previously with Tip #25: Login Logging. It was included in the Top 10 based on the Community Survey, and is something often overlooked which doesn’t usually directly lead to vulnerabilities1, but without decent logging and monitoring, you're far less likely to detect and stop attacks and figure out the the root vulnerability in your apps.

In short: logging and monitoring are essential.

My recommendations are simple:

1. Log everything.

   1. Enable webserver access logs (these are disabled by default on Laravel Forge! 😔).

   2. Log all authentication events.

   3. Log important user and system events, especially admin changes and destructive events.

   4. Link each log with a IP address2, UserId, and/or email.

2. Use a 3rd party monitoring solution to track all errors and ideally logs too.

   (I don’t have any recommendations here, but there are plenty of options, so throw your recommendations in the chat!)

3. Remotely store or backup your logs (at least for a short time).
   It’s not uncommon for a hacker to delete site logs to cover their tracks. If your logs are sent off-site, it’s much harder for an attacker to remove them.

Story Time…

To reinforce this point, I want to tell you about my experiences with logging and why I believe it is important.

I used to work at Wordfence a few years ago and when I first started there, I spent 12+ months cleaning infected WordPress sites. Customers would give us access to their hosting accounts and we’d go in, look for any malware3 and try to identify how the hacker managed to compromise the customer's site.

In many cases access logs were disabled by the hosting provider, which made it difficult to track down what happened, but when logs were available you could often trace their full activity to find out exactly how they got in and what they did.

Access logs will frequently expose vulnerable pages and even vulnerable query parameters after an attack has taken place, and you can follow the IP address as it explores, identifies, compromises and then exploits the vulnerabilities.

As a great example, this is a slide from my Cleaning Infect Sites conference talk:

You can see quite clearly the hacker discovered a fresh instance of WordPress that hadn’t been installed yet. They proceeded through the site setup process, uploaded a malicious plugin, and used that to compromise the account.

What’s not shown is them resetting the site back to “fresh uninstalled state”, so the site owner had no idea. The fresh WordPress instance is already infected when the owner goes to create their new account.

If you’re interested, go check out my full talk, it contains more logs and other fun stories from cleaning infected WordPress sites.

Moving to a custom domain?

Laravel Security in Depth has been at larasec.substack.com since I first created it, but now that we’ve hit 1,500 subscribers and bestseller status, I feel like we need to look into a custom domain and move off the subdomain.

I currently own three domain names which would work for Laravel Security in Depth. Let me know which you prefer in the poll below, or if you have other suggestions, send them my way privately (to avoid squatters!).