PCI Requirement 6.5.1 – Injection Flaws
by Randy Bartels / October 13th, 2017
What are Injection Flaws?
PCI Requirement 6.5 requires that your organization addresses common coding vulnerabilities in software-development processes to ensure that applications are securely developed. One of the common coding vulnerabilities associated with secure application development is injection flaws, which is outlined in PCI Requirement 6.5.1.
PCI Requirement 6.5.1 requires that your organization’s applications are immune from injection flaws, especially SQL injection. Injection flaws are commonly used by malicious individuals to compromise applications. Injection flaws are a type of security vulnerability that allow a user to “break out” of the application and, according to OWASP, “allow attackers to relay malicious code through an application to another system. These attacks include calls to the operating system via system calls, the use of external programs via shell commands, as well as calls to backend databases via SQL.” The PCI DSS says, “Injection occurs when user-supplied data is sent to an interpreter as part of a command or query. The attacker’s hostile data tricks the interpreter into executing unintended commands or changing data, and allows the attacker to attack components inside the network through the application, to initiate attacks such as buffer overflows, or to reveal both confidential information and server application functionality.”
Best practice recommends data coming into the application should be validated. To verify compliance with PCI Requirement 6.5.1 and protection from injection flaws, an assessor will examine your policies and procedures related to application development and interview the responsible personnel.
When developing applications, we need to make sure they are immune from any type of injection flaws; specifically, the PCI DSS calls out SQL injection. One of the things we look for is that you have some type of parameterized queries or you’re making sure the string of data that’s coming into the application is vetted before it’s run. Where you have a parameterized query, you’re not taking the data stream provided by the end-users and developing your query based on that. Make sure that when your team is developing software, they are not subject to SQL injection. As part of your secure code development testing, as part of your SDLC, make sure that you write test scripts, testing for SQL injection as part of this requirement.
