Blame it on SQL Injection – Again?
As my colleague, Bill Oakes, CISSP, recently wrote in his overview piece The Open Web Application Security Project, “The OWASP Top 10 list is a good starting point for identifying and addressing the most common security threats.” In fact, many of these threats continue to make headlines.
Just this week it was revealed that the U.S. Securities and Exchange Commission (SEC) is investigating the MOVEit mass-hack that has exposed the personal data of at least 64 million people. Considered the biggest hack of 2023, it began May 27, 2023 when CL0P Ransomware Gang began exploiting a previously unknown SQL injection vulnerability in Progress Software’s managed file transfer solution known as MOVEit Transfer.
The danger of injection attacks
According to the OWASP Top 10 List, injection is the third most common type of vulnerability in web applications. SQL Injection is just one of several common injections. In addition to SQL injection, the most dangerous injection attacks 2023 include: Code injection, command injection, cross-site scripting injection, XPath injection, mail command, CRLF injection, host header injection, LDAP injection, XXE injection.
Injection attacks, which are prevalent in legacy code, allow attackers to insert malicious code or commands into a system or application. Successful injection attacks may completely compromise or destroy a system. In order to change the behavior of the program or obtain unauthorized access to data, this attack takes advantage of careless handling or a lack of validation of user input.
Depending on the accessibility, different actions must be taken in order to fix them. In its “Cheat Sheet,” OWASP provides good guidance about how to prevent SQL Injection attacks. To fully protect against SQL injection – or any kind of injection – you need to ensure the proper validation of the data at every level. OWASP’s Top Ten List, Software Assurance Maturity Model, and Web Security Testing Guide provide excellent security protocols and guidelines to protect today’s enterprises against injections and other types of attacks. It’s important to do continuous assessments to determine where you are from a “maturity” point of view. As another proactive measure, both developers and security teams need to periodically check Mitre’s Common Weakness Enumeration (CWE) and (CVE) lists.
The importance of code quality
To protect applications from any vulnerabilities, code quality is critical, which is why I think it should be added to the next OWASP Top 10 List (the current list was updated in 2021). Without strong code quality, weaknesses can be introduced, which become a vulnerability, and can be exploited. Enterprises need to impose a stronger static-code analysis and much stronger secure CI/CD automation process to avoid poor code quality. Any unauthenticated or unauthorized user can access poor coding or poorly designed web applications to trigger DDoS attacks using a bot or any kind of a scripting language.
Insecure Design, a OWASP Top 10 security risk, is another reason why code quality is so important. There is a difference between insecure design and insecure implementation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation.
Security is a shared responsibility
Developers need to work hand in hand with their security and enterprise teams to create a secure software development lifecycle. Developers need to have the right set of tools and technologies in their libraries, the right CI/CD process, and the right pipeline. Everything needs to be streamlined. A developer should only be able to take something from the web and add it to the code using a pre-approved template or a style or format. That way, there is no weakness that has been introduced into the application. Every web application needs to have its own templates and their own library set of tools and technologies that they recommend.
Security is a shared responsibility – enterprise cybersecurity teams must provide overall protection for the enterprise, but they also need to talk about security requirements to their developers. Developers, in turn, need to have a certain discipline when it comes to using a certain tool or concept to help create a more secure software ecosystem. Developers need to follow certain software design protocols and agreed-upon company security processes and procedures and remember to say to themselves, “Oh, I need to follow this template, I need to follow this library, I need to make sure this is approved.”
By taking a decentralized governance approach, both the security team and the developer takes ownership and together helps to provide a more secure environment for their organization, which reduces the risk of injection attacks and other security threats.