What Developers Get for Free
One effective way to accelerate your security code review or pentest is to understand what developers get for free! In this blog post, we'll see why this matters.
Today, it's increasingly rare for developers to create applications without utilizing frameworks and libraries. These tools offer functionalities that are often more mature and reliable than custom-written code.
For example, developers shouldn't usually have to write their own implementations for authentication, password storage, JWT, or SAML. These features are hard to write and hard to get right. The more developers rely on battle-tested code for these, the better.
For security reviewers, this means you can probably increase your coverage by spending more time on the code that developers didn't get for free!
This doesn't mean you shouldn't test these frameworks or libraries. Instead, it suggests that the code provided by these tools is generally of higher quality and security.
Understanding what developers get for free can also help you identify common misuse. If you're experienced in code review or pentesting, you know that many frameworks and libraries do not always provide a high level of error-proofing, and developers often make similar mistakes.
But how do you know what developers got for free? Great question!
As a security code reviewer, you can look at the list of dependencies used by the application to know what the application is using. From there, you just need to ensure they are using those dependencies properly.
From a black box perspective, it's a bit harder to know accurately, but you can rely on a few clues: error messages, URL mapping, quirks that the library or framework may have, exposed documentation and example pages left from development, favicons, HTTP headers, cookie names, and so on. It’s challenging at first, but with time and experience, you can get really good at this!
If you are working in application security and want to scale your efforts, providing as much "free code" to your developers as possible is key. This "free code" ensures they don't reinvent the wheel, and you won't have to review 200 implementations of the same thing. Be sure to check out our blog post on building blocks that covers this in detail.
In some cases, especially with hard targets, you may need to do the opposite and scrutinize the "free code" more closely. You may find that the dependencies are a softer target than the main codebase relying on them.
In conclusion, "free code" is a crucial aspect of any source code review and pentest, as well as a key component of a scalable application security strategy.
