In Depth: What Are Insecure Functions?
[InDepth#16] According to random folks on the internet (i.e. social media), "insecure functions" are a wide and varied concept. Let's take a look at the common themes across the different ideas...
Greetings my friends! This week we’re on #5 in my list of Top 10 security issues I’ve found during audits: Insecure Function Use! This is an interesting topic - I originally had a very limited scope for it, but as you will see, insecure function use is a much wider problem.
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
#5 → Insecure Function Use
🛡️ Worried about the security of your Laravel app? Book a security audit now to identify and fix any vulnerabilities in your code! 🕵️
Laravel Security In Depth is 100% reader-supported. Please consider becoming a free or paid subscribe to receive new posts and support my work.
What Are Insecure Functions?
When I tallied up my findings and wrote up my Top 10 list, I had a very clear idea for what “Insecure Function Use” meant. It was focused specifically on a set of core PHP functions which, in my opinion, should be avoided in a lot of the places they usually get found.
Functions like this:
The common theme with these should be obvious: cryptography and randomness. These functions are often used for secure purposes, such as generating random passwords/tokens, or hashing passwords, or applying randomness to something, but they are all flawed and vulnerable to some form of attack.
My favourite example is
`md5(time())` which is an incredibly common way to generate random strings. It’s also incredibly predictable, given
`time()` only changes once per second. If you can narrow down the time window during which the token was generated, you can guess it. There will only be 86,400 different hashes in a day, and without adequate rate limiting (or given enough time) this becomes trivial to guess.
I’ve talked before about these functions, such as during our mini-security audit of Steve McDougall’s Password Generator, my attempts at upgrading Laravel’s Randomness functions, and back when I talked about Cryptographically Secure Randomness.
However, all of that really only scratched the surface of what an insecure function is. Sure, those specific functions perform operations that are considered unsafe, but are they the only definition of an insecure function? Can we simply build a list of core functions to ignore, and move on?
Keep reading with a 7-day free trial
Subscribe to Securing Laravel to keep reading this post and get 7 days of free access to the full post archives.