Securing Laravel

Share this post

Security Tip: Replace Simple Dependencies

securinglaravel.com

Security Tip: Replace Simple Dependencies

[Tip#45] The more dependencies your project has, the higher your risk of supply-chain attack is, and the less you're aware of what code is actually running...

May 9, 2023
4
1
Share
Share this post

Security Tip: Replace Simple Dependencies

securinglaravel.com

Greetings friends! This week we’re on #6 in my list of Top 10 security issues I’ve found during audits: Outdated & Vulnerable Dependencies! Since I’ve covered this topic a few times, today’s tip will be on a related topic: replace simple dependencies with in-house versions. As per usual, I’ll link to my previous articles on this topic at the end.

Here’s our current Top 10:
#10 → Insufficient Input Validation
#9 → Missing Subresource Integrity (SRI)
#8 → Insufficient Rate Limiting
#7 → Cross-Site Scripting (XSS)
#6 → Outdated & Vulnerable Dependencies

🛡️ Worried about the security of your Laravel app? Book a security audit now to identify and fix any vulnerabilities in your code! 🕵️

Looking to learn more?
⏩ Security Tip #30: Finding Secrets
▶️ In Depth #11: Insecure Direct Object References (IDOR)


Laravel Security In Depth is 100% reader-supported. To receive new posts and support my work, please consider becoming a free or paid subscriber.


Replace Simple Dependencies

Given the huge dependence on frameworks and shared components, supply-chain attacks are a real risk to modern web applications. Laravel alone pulls in a significant number of packages by default, and then we add in our own packages for different features, they pull in even more… those numbers very quickly add up. Not to mention the sheer multitude of packages required in the JS world… 😱

It becomes harder and harder to keep track of all of the packages in your app, and then something like the recent Packagist.org maintainer account takeover occurs, and you find yourself with a package that has been compromised and injected with some malicious code

1
.

A common “solution” you’ll hear from infosec folks is to “review all dependencies before using them”, but this is completely useless advice. No one has time to review every dependency they use!

Instead, I recommend you replace simple dependencies with your own in-house versions.

I’m talking about Laravel-specific wrappers around other packages (there are a multitude of these), or middleware helpers, blade components, JS helpers, etc. So many of these packages really only contain one or two actual classes, and then often pull in other dependencies. By replacing them with your own in-house code, you’re eliminating at least one dependency (and often a lot more) that could be compromised and injected with malware.

Even things like vendor SDKs can be easily replaced - if the API is simple and/or you’re only using a subset of the endpoints, you may find that ripping out the vendor SDK and using Laravel’s HTTP Client does everything you need, without the bloated and clunky vendor SDK

2
.

So go take a look at your `composer.json` and `package.js` and see what you can remove. 🧐

More About Vulnerable & Outdated Dependencies

  • Security Tip: Keep Dependencies Updated

  • OWASP Top 10 → #6 - Vulnerable and Outdated Components

  • Security Tip: Composer Audit

1

To be fair, the person responsible for the recent account takeover was just looking for a job, but not everyone has such benign intentions...

2

This is especially true when the vendor isn’t a PHP shop, and their code is complete rubbish. I’ve done this a few times, and the features of Laravel’s HTTP Client won me over completely. It’s surprisingly powerful and makes working with APIs really easy!

4
1
Share
Share this post

Security Tip: Replace Simple Dependencies

securinglaravel.com
Previous
Next
1 Comment
colbyalbo
Writes colbyalbo’s
May 12Liked by Stephen Rees-Carter

About a year and a half ago, I began doing exactly this.

So glad I did. I’d pick a package, isolate the part I was utilizing and figure out how to write my own functionality.

It wasn’t as daunting as I expected. And I found that digging through a packages code exposed me to different ways to code things up; time spent reading code is never wasted.

Expand full comment
Reply
Top
New
Community

No posts

Ready for more?

© 2023 Stephen Rees-Carter
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing