Plynt Certification Criteria
Version 4.0, Effective Date: December 15, 2015
The awarding of the Plynt Certificate establishes that a web application has adequate measures to guard against remote adversaries and protect against a wide range of threats, including the threats and vulnerabilities documented by organizations like OWASP, WASC and SANS.
This document defines the Plynt Certification Standard. It details the criteria that an application must meet in order to be awarded the Certificate.This document is organized into two parts:
- Part I lists and defines the certification criteria.
- Part II explains the logic and rationale of the criteria.
The certification standard is composed of 14 criteria. These are organized into two sections:
Section 1, “Security Protection Criteria” identifies the defenses an application and the hosting environment must demonstrate to meet the certification standard.
Section 2, “Security Requirements Criteria” specifies the features, characteristics and behavior an application must maintain to enhance its security and meet the certification standard.
For explanation of the rationale behind the criteria, refer to the Guide to Certification Criteria.
Section1: Security Protection Criteria
- Safe against popular attacks: The application must demonstrate that it is not vulnerable to popular attacks.
Note: A list of the popular attacks we test for is present under the "Guide to the Plynt Certification Criteria" section.
- Defend against Threat Profile: The application must demonstrate that it defends against the threats specified in a threat profile that has been developed specifically for the application.
Note I: A threat describes the goal of an adversary. According to the National Information Systems Security Glossary, a threat is any circumstance or event that has the potential to harm an information system through unauthorized access, destruction, disclosure, modification of data, and/or denial of service.
Note II: The threat profile is a list of all possible threats an application faces, but in this criterion we focus on threats related to business and authorization rule violations,because other threats are covered by the rest of the criteria.
- Protect sensitive data in transmission: The application must take adequate measures to protect sensitive data from being stolen over the network.
- Protect passwords from theft and guessing attacks: The application must demonstrate that a remote adversary cannot steal or guess user passwords and passphrases. At a minimum, the application must enforce a minimum length of 8-character alphanumeric passwords.
Note I: The criterion requires that even after a user logs out, the user’s password or passphrase must be protected from theft.
Note II: The criterion recognizes that there are social engineering methods that could be used to steal the password or passphrase without access to the application. These are not within the scope of this criterion.
Note III: The risk of password guessing varies depending on the predictability of the usernames used by the application.
- Secure password recovery implementation: If the application provides a password recovery feature like ‘forgot password’, then it must protect against an adversary from recovering or resetting the password of legitimate users. In addition, the application should ensure that issuance of a new password is initiated after an alternate authentication mechanism. The application should implement a secure mechanism for issuing a new password that should be short-lived and of one-time use only.
Note I: An alternate authentication mechanism may include implementations like security questions, or one-time passwords sent to a user-owned device like mobile phone or other token devices.
Note II: A secure mechanism for password issuance entails the use of tokenized links, temporary passwords, and SSL communication while resetting the password.
Note III: By password we mean any secret that is used during an authentication process, for example, passphrase, PIN, passcode and passkey, etc.
- Secure the hosting server directly accessible by the users: All services that a user can reach must be securely configured and patched to prevent leakage of sensitive information, unauthorized access, buffer overflow, remote code execution, and other publicly known exploits.
Note I: This criterion includes securing all directories, backup, log and configuration files. Configuration files include OS, web server and application configuration files.
Note II: Along with the HTTP(s) service on which the application is accessible, this criterion mandates protection of all the non-HTTP(s) services like SSH, RDP, FTP, etc. against attacks that would lead to server compromise, which would eventually affect the web application.
- Secure application's interaction with web client components: The application should ensure authentication and integrity checks for interactions with web client components.
Section 2: Security Requirements Criteria
- Sensitive data not stored on the client: The application must not store sensitive data on the client machine in easily accessible locations.
Note I: Easily accessible locations include the browser cache, the browser history, web storage, other browser menus and persistent cookies on the client machine.
Note II: The browser memory is not considered an easily accessible location for this criterion.
- Sensitive data not hidden in pages: The application must not hide sensitive data in html comments or hidden form fields embedded in the pages.
- No sensitive data in error messages: The application must not reveal sensitive information in error messages.
Note: Sensitive information includes not only business-sensitive information but also details regarding application architecture that could aid an adversary who is attempting to launch an attack against the application.
Note: The secrets in the above criterion refer to cryptographic keys, passwords and algorithms that are considered trade secrets.
- Re-authentication required for sensitive activities: The application must re-authenticate the user before allowing the user to perform an operation involving sensitive data. A few examples of operations involving sensitive data are “Change Password”, “Transfer Funds” and “Transaction Approval”.
Note: This criterion does not apply to the special case where the user has forgotten the password and resets the password using the application’s password recovery or “Forgot Password” feature.
- No sensitive data in requests to external entities: If the application maintains links to external entities i.e. sites, web services and web sockets, it must not disclose any sensitive data other than that required to conduct the operation with the external entity.
Note: Sensitive data, as used in this criterion, include personal identity, personal health and payment card information, as well as session token(s) and authentication token(s).
- No sample or test applications: The server must not make available any sample or test application to remote users.
Get a printable copy of the Plynt Certification Criteria