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...
#1 → Exposed API Keys & Passwords
#2 → Missing Authorisation
#3 → Missing Content Security Policy (CSP)
#4 → Missing Security Headers
#5 → Insecure Function Use
#6 → Outdated & Vulnerable Dependencies
#7 → Cross-Site Scripting (XSS)
#8 → Insufficient Rate Limiting
#9 → Missing Subresource Integrity (SRI)
#10 → Insufficient Input Validation & Mass-Assignment Vulnerabilities
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:
md5()sha1()uniqid()rand()mt_rand()tempnam()str_shuffle()shuffle()array_rand()
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?
Asking The Question…
When preparing for this article, I wanted to answer these questions and see what other folks in the community think about insecure functions, and what they are.
