Injection Vulnerabilities – 20 Years and Counting

Injection vulnerabilities are one of the oldest exploitable software defects, which unfortunately are still prevalent today. Doing a simple search on cve.mitre.org com for the term injection returns with over 10,852 injection-related vulnerabilities in commercial and open source software since the year 2000, and the number of injection vulnerabilities continues to grow daily. The earliest tracked injection vulnerability was CVE-2000-1233 which was discovered in that year, allowing remote attackers to execute arbitrary code on a vulnerable system. So what exactly are injection vulnerabilities? Before going into a short explanation, first let’s discuss how abundant injection vulnerabilities are. For example, Injection has made the OWASP Top 10 for the most critical Web Application Risks in 2010, 2013, and 2017. Injection also made the list on the OWASP Top 10 for API Security in 2019 as well. Clearly, injection risks and associated attacks have been in existence for nearly 20 years and have often been the catalyst in many reported data breaches. Injection vulnerabilities cause computing systems to potentially process malicious data that attackers introduce. To put it in its simplest terms, attackers inject code into a vulnerable piece of software and change the way the software is intended to be executed. As a result, injection attacks can be somewhat disastrous, since they normally involve data theft, data loss, data corruption, denial of service, etc. According to OWASP Top 10 2017, “Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.” For more information on SQL injection and LDAP injection for example, Checkmarx provides detailed descriptions in our vulnerability knowledge base. In light of nearly 20 years of widespread injection vulnerabilities, I asked our guest expert Inon Shkedy to provide his insight on a few questions as shown below. Inon worked closely with Erez Yalon, Head of Security Research at Checkmarx, on the OWASP API Security Project. Together, they spearheaded the development of the OWASP API Security Top 10 2019, which defines the top ten most critical API security risks. … Question: Why is injection still making the list of Top Ten risks, and shouldn’t this problem have been remedied by now? Inon: There are two main trends in the field of injections: On one hand, some types of injections become less and less prevalent, because of proper security education and a set of modern technologies which address them. On the other hand, new frameworks and technologies open a door for new types of injections. For example, NoSQL injection is a relatively new attack vector for systems that use NoSQL. These two trends make injections less severe and prevalent, but at the same time they still have a place on the list. Question: What is the cause of developers writing injection vulnerabilities into the code they produce? Inon: There are a few main reasons: Lack of awareness: it’s common to see junior software engineers writing code that is vulnerable. The “injection” concept may be not very intuitive for them, and they deliver vulnerable code because it’s the easiest / fastest way for them to implement a specific component. Rush: we all know how stressful and demanding modern software development environments can be. Concepts like Agile and CI/CD are great for fast delivery, but when developers are focused only on delivering the code, they might forget to check for security issues. Complexity: APIs and modern apps are complex. A modern app, like Uber for example, might look very simple from the UX (user experience) perspective, but on the backend there are many databases and microservices that communicate between them behind the scenes. In many cases, it’s hard to track which inputs come from the client itself and require more security attention (as filtering and scanning), and which inputs are internal to the system. Question: What will it take to finally get developers to stop writing injection vulnerabilities into their code, and / or organizations releasing code with injection vulnerabilities? Inon: Raising awareness: I believe that secure coding is a result of education. It’s super important to raise awareness by providing security guidelines for new software engineers in the company and to have ongoing training, talks, and discussions about security. Pre-production automation: use automatic tools like SAST and IAST to find injections vulnerabilities in your code before it gets exposed to the whole world. Use ORMs: It’s harder to write vulnerable code when you use ORMs. They provide security mechanisms by design. … Clearly, injection flaws must be addressed during the software development process by first detecting them, then mitigating them by fixing the vulnerabilities. If applications with injection flaws make their way to the internet, it’s only a matter of time before they’re found by attackers, and are eventually exploited.