15 Practices to Shield APIs from Attack: #7 – OWASP Top 10, Injection
Every few years, the Open Worldwide Application Security Project (OWASP) updates its top attack vectors. To illustrate how our work and the practices we’ve discussed in this blog series truly help improve security posture, this post goes through the second of the top 10 attack vectors and reviews which of the practices helps to prevent this kind of attack.
A03:2021-Injection
Injection attacks involve an attacker tricking your software into executing instructions, supplied through additional or specially formatted parameters.
It’s hard to protect against these attacks without following basic development practices and using well-built and supporting software libraries. Checking for and even discovering such attacks can also be difficult. Of the practices we have talked about, our teams rely on the following ones to prevent this kind of security risk.
Good pen-testing services will attempt to exploit injection techniques specifically. One of the early reviews of our system found that we were allowing XML style-sheets in a request to reference an off-site URL, which could perhaps expose us to injection or tracking risks. The configuration option to disable off-site requests was missed by the team. Rather than simply fix the issue in the code and move on, the team encoded the check for the issue into an Automated Security Test to ensure the proper behaviour, forever. They also did some research to see if there were similar patterns in other parts of the system. Having the DevSecOps Product Team and their Product Owner empowered to prioritise this work means similar issues have never been detected by future pen tests.
Injection often takes advantage of unparsed or unhandled customer-provided strings. Code analysis tools can check for these mistakes. Additionally, eXtreme Programming Concepts like Pair Programming make them less likely to occur in the first place (the old adage of “two heads are better than one” definitely applies to complex and creative practices like software development).
The idea of “trust but verify” is important in security. While the above practices can help a team avoid injection security vulnerabilities, we also want to be sure they have not occurred. Good event logging, flowing into an SEIM such as Splunk or Splunk Enterprise Security, can help to catch unusual behaviours or events that can help identify security exposures. Although our team did not have active security use cases, we were able to clearly see in our security logs the attempts of external parties to probe the system being rejected by our platform. These attacks often include injection attempts. We are able to verify regularly, via reporting in the observability platform, that these requests too were being rejected by our system in all cases.
