Gartner estimates that through 2020, 99% of vulnerabilities exploited will continue to be ones known by security and IT professionals for at least one year. Month after month, major organizations face major hacks and breaches which often involve security vulnerabilities that are well known to security professionals. From SQL injections to weak encryption, the astronomical costs associated with exploits which can, and should be, remediated prior to production, should make organizations constantly reconsider, revisit and revise their software development lifecycle and strive towards creating a secure software development lifecycle (sSDLC). Read these tips for sustainable and secure coding practices and be sure to add your own in the comment section below!
1 Never Trust User Input
All user input should be considered “evil” until validated otherwise. While input validation is not the primary method for preventing cross-site scripting (XSS) and SQL injections (SQLi), input validation is able to help detect unauthorized input before it is processed by your application. OWASP recommends that input validation should be applied to all data while defining both the allowed set of characters to be accepted as well as a minimum and maximum length for the data that will be inputted by the user.
Further reading: Input Validation Cheat Sheet
2 Perform Threat Modeling
Application threat modeling is a structured approach that allows developers to identify, quantify and address any security risks within an application. You should perform threat modeling before testing to understand where you need to focus your testing. Threat modeling will allow you to secure your code from the earliest stages of development by allowing you to fully understand which are the greatest threats and risks contained within the code and then prioritize their fixes. Be sure to perform source code analysis (SCA) on both applications in their design stage as well as legacy applications, or software with legacy code.
Further reading: Using Source Code Understanding as a Risk Barometer
3 Layer your Security Testing
Use a layered approach to security testing to dramatically cut down on security issues prior to deployment. While application security testing solutions have progressed immensely over the last few years, the best way to ensure that your application is as secure as possible is to utilize multiple layers of security testing to be sure your sensitive data is as secure as possible both during development and while on production. Combining a static application security testing (SAST) with a dynamic application security testing (DAST) solution will secure your application with both the early detection of SAST and the runtime detection capabilities of DAST to provide a complete security analysis.
Further reading: Incorporating AppSec from the Start: How SAST and DAST Work Together
4 Keep Brute Force Attacks at bay with Error Messages
Brute force attacks are an old, and common, attack vector that organizations continue to face where applications are pummelled with different character combinations at the user authentication portal until a match is found. OWASP notes that depending on the complexity of your password requirements, the possible combinations could be in the trillions.
Brute force attacks are easy to detect, but difficult to prevent. An effective way to counter these pesky attacks is by simply avoiding predictable behavior when displaying error messages on your web application for failed login attempts. Use varied error messages like “incorrect username or password” to help fight off brute force attacks. Avoid identifying to the user, or hacker, which data was incorrect. OWASP recommends “to vary the behavior enough to eventually discourage all but the most dedicated hackers. You could, for example, use different error messages each time or sometimes let a user through to a page and then prompt him again for a password.”
Further reading: Blocking Brute Force Attacks
5 Consider Breaking the Build for Medium and High-risk Findings
While everyone has their own agenda and business goals that rely on getting an application live on production as soon as possible, the hazards of releasing a build with medium or high-level vulnerabilities is far costlier than the time and effort needed to remediate high and medium-level vulnerabilities prior to the code progressing to production. Breaking the build to fix these vulnerabilities helps secure your software development lifecycle (SDLC) while avoiding the financial damage and loss of reputation that organizations are faced with following hacks and breaches of all sizes. Never ship with potentially dangerous vulnerabilities.
6 Run a Security Analysis on any Third-Party Code
It’s critical that you either run your own security tests on the code or insist on a security report from the code’s supplier. Open source security should be a major cause for concern when they are integrated into your application. All open source components should be analyzed for security and regulatory issues. “In an age when companies are heavily using open source components, it is no longer sufficient to just scan one’s own code. OWASP A9 requirement emphasizes this issue,” said Rami Sass, CEO and Co-Founder of WhiteSource.
To help ensure that all open source components are vulnerability free, Checkmarx and WhiteSource, the continuous open source component management solution, have partnered to provide Checkmarx users with a comprehensive Open Source Analysis (OSA) solution. The new capability adds full visibility of the open source components used by developers. It reports known security vulnerabilities contained in the open source code and suggests available fixes. It also highlights licensing and compliance issues in any used open source components.
Further reading: How Secure Are Your Open Source Components?
7 Use the right Hashing Algorithm and Salt User Passwords
Make sure that you are using the most secure hashing algorithms and salting before storing passwords in your database. Start off by MD5 hashing as your method of choice and keep in mind that it’s critical to also avoid SHA-0 since it has been conclusively broken, SHA-1 as well as DES as it can be broken by the average desktop computer’s GPU.
Further reading: All About Encryption: Security, News and a Brief History
Be sure to follow the Checkmarx blog throughout October as we’ll be posting content aimed to empower and educate developers about secure coding best practices as part of our initiative for 2016’s National Cyber Security Awareness Month (NCSAM).