How to protect your code against malicious hackers without spending days on refactoring
During our work as penetration testers, we found that there are lots of vulnerabilities being introduced in applications. Vulnerabilities that could have been prevented in an early stage of development. Sadly these are often the same vulnerabilities over and over again.
Luckily the IT development landscape is changing.
We can see the latest trend in integrating security tooling into CI/CD pipelines (Continuous Integration/Continuous Delivery). However, security tooling integrated in your security pipe-lines will not cover the complete attack surface. The alternative on the other hand, resources in the form of manual verification, can often be scarce and expensive.
Why is tooling coverage this low?
This is because the tooling can never understand the full context of the applications functions and logic.
A good classic example for this would be a “Insecure direct object reference”.
Imagine you are authenticated against an application and in the URL you find the following parameter “?loggedinUserID=1”
This identifier correlates to your personal information and displays this information in the application for whatever purpose.
Now, whenever we change the value to “?loggedinUserID=2”, the identifier is now correlated to somebody else his personal information.
As a result, another person his personal information is shown to us by the application.
Was the behaviour intended?
The tooling can make no estimation because if we had an administrator account we probably should have been able to manage al this personal information right?
It’s all about the right balance
Where do we find the right balance between security test automation and manual verification? You might ask.
Even more importantly, how do we train the developers understand the metrics and make security part of their process and culture? wouldn’t it be much more beneficial for a company to have a culture that prevents the introduction of security leaks in the first place?
A perfect decorated (S)SDLC has four very important steps we should take into consideration:
1. Security requirements && threat modelling
Whereas most security tools can only discover injection and configuration flaws because the security tools do not have proper context about the business logic of the application. The right set of security requirements and threat modelling can help developers get insights of evil use cases, or abuse cases, before writing a single line of code.
When developers think about security in the design phase of the application we often see that the code becomes very pro-active and resilient against attacks.
2. Test automation.
Test automation helps us to determine the overall status of the project under test. The quality of the code under test is a good defining factor of the level of maturity in terms of security.
• Is over complex code introduced?
• Is there repudiated code?
• How about dead-end code?
• How maintainable is the code base?
When these quality gates are not met, it is less likely developers get time to iterate and refactor over their code base. Because of technical dept, this will take considerably more effort to fix security vulnerabilities.
3. Security test automation
With security test automation we introduce SAST ( Static Application Security Testing ) and DAST (Dynamic Application Security Testing) tools into the CI/CD pipelines. Which can detect if any security vulnerabilities are introduced, in a very early stage of development.
4. Manual verification (security code audit, penetration testing)
The final phase of the (S)SDLC consists out of manual verification by means of a security professional. This professional can do a deep dive in the business logic of the application and to find more complex vulnerabilities and injection flaws that would normally go undiscovered by most SAST and DAST tools.
With all these checks in place, there is a layered defence in-depth solution for security. In which all different resources work, as efficiently as possible. Involving the developers and making them responsible and accountable for security. This way, they will ultimately make applications more resilient and defensible.
This in addition to where we do the testing for QA and code quality with normal test automation eliminates a lot of technical depth. Security test automation than is a good safety net that finds critical low hanging fruit in an automated fashion with a very short feedback loop to the developers. Than ultimately, the penetration test or code review makes sure that even the most professional attackers will have a hard time compromising the system. This (S)SDLC prevents spending this valuable resource on reporting vulnerabilities, that could easily have been discovered in an early stage!