PCI Requirement 6.5.5 – Improper Error Handling
What is Improper Error Handling?
Improper error handling is one of the common coding vulnerabilities outlined in PCI Requirement 6.5. PCI Requirement 6.5.5 states that improper error handling must be addressed in your coding techniques.
PCI Requirement 6.5.5 alerts organizations that improper error handling introduces many security issues to your website because it can unintentionally leak information to an end-user or malicious individual. For example, a 500 Internal Sever Error could show database connection strings, configuration information, error codes, stack traces, data dumps, local directories, or information about the back-end application. These details should never be revealed, but especially not to an attacker. OWASP warns, “Such details can provide hackers important clues on potential flaws in the site and such messages are also disturbing to normal users… Even when error messages don’t provide a lot of detail, inconsistencies in such messages can still reveal important clues on how a site works, and what information is present under the covers.” The last thing you want to do is provide your attacker with clues on how to exploit your system. The PCI DSS explains, “If a malicious individual can create errors that the application does not handle properly, they can gain detailed system information, create denial-of-service interruptions, cause security to fail, or crash the server.”
A common example of improper error handling is user ID and password input. If an attacker receives the message, “incorrect password provided,” that error message is telling them they’ve given a correct user ID. Now, they can focus on hacking the password. The PCI DSS recommends using generic language in your error messages so that no useful information is accidentally given to attackers. Instead of saying “Incorrect password provided,” try giving the error message, “Data could not be verified.”
When in the development phase with an application, you must ensure that your error message does not disclose any unnecessary information. If your application is going to error-out, it needs to do so in a secure way. In order to verify your compliance with PCI Requirement 6.5.5, an assessor will need to review your policies and procedures related to application development and interview the responsible personnel to ensure that your system is properly handling error messages.
How many times have you been surfing the Internet, go to a website, and all of the sudden you see this 500 Error. In this error, it shows all sorts of information – database connection strings, information about the back-end application, the local directories. Once in a while, you’ll see this. it’s not as prevalent as in years past, but it’s still something that we see today. From a development perspective, you need to make sure that if your application should error-out in some way, it errors-out in a secure state so it’s not disclosing any unnecessary information or an insecure information to the end-users. While it’s absolutely acceptable to dump all of that stuff back into an error log and then de-bug and find out what went wrong, the last thing that you want to do is provide more information to the attacker to might allow them to further their attack.