Plynt Certification Criteria
Version 3.0, Effective Date: April 15, 2010
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.
This document defines the Plynt Certification Standard. It details the criteria that an application must meet in order to be awarded the Certificate.
The certification standard is composed of 16 criteria. These are organized in two sections:
Section 1, “Security Protection Criteria”, identifies the defenses an application must demonstrate to meet the certification standard.
Section 2, “Security Requirements Criteria”, specifies the features and behavior an application must have to meet the certification standard.
For explanation of the rationale behind the criteria, refer to the Guide to Certification Criteria.
The older version of the criteria is archived here.
Click here for Plynt Certification Criteria for Mobile Applications.
Security Protection Criteria
- Safe against popular attacks: The application must demonstrate through testing that it is not vulnerable to popular attacks.
Note: “Popular attacks” include but are not limited to exploits documented by organizations such as, The Open Web Application Security Project ( owasp.org),The Web Application Security Consortium (webappsec.org), The Open Source Security Testing Methodology Manual ( osstmm.org), SANS Common Weakness Enumeration (CWE) TOP 25 (cwe.mitre.org/top25), etc.
- 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 this 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 to an application. These threats include violating the business rules and authorization rules of the application.
Note III: This criterion applies to high and medium risk vulnerabilities that let threats be realized.
- Protect sensitive data in transmission: The application must take adequate measures to protect sensitive data from being stolen over the network.
- Safeguard passwords: The application must demonstrate that a remote adversary cannot steal user passwords from the application.
Note I: The criterion is inclusive of post-login. That is, it requires that even after a user logs out the user’s password must be protected from theft.
Note II: The criterion recognizes that there are social engineering methods that could be used to steal passwords without access to the application. These are not within the scope of this criterion.
- Protect against password guessing: If the password used by the application has less than 10,000 possible values, the application must protect against manual password guessing attacks.
Note I: A 4-digit numeric PIN is an example of a password with less than 10,000 possible values.
Note II: The risk will vary depending on the predictability of the usernames used by the application.
- Secure Forgot Password Implementation: If the application provides a password recovery or ‘forgot password’ feature with secret question(s), it must protect against an adversary guessing the answer to the secret question(s). In addition the application should ensure that upon issuance of a new password, it is securely communicated to the user.
- Insecure Configuration Settings on servers accessible directly by users: All services that a user can reach must be securely configured so there is no leakage of sensitive information. This includes securing all directories and configuration files that are publicly accessible.
Note I: Configuration files, as used in this criterion, include OS, web server and application configuration files.
Note II:Directory listings, as used in this criterion, refer to a listing of all files and directories in a folder, regardless of whether there are links to those objects from the application. While an adversary can compile a list of links in the application by studying the html pages, such compilations are not considered directory listings.
Security Requirements Criteria
- Sensitive data not to be stored on 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, 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 included 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 when attempting to launch an attack against the application.
Note: The secrets the above criterion refers to include cryptographic keys, passwords, and algorithms considered a trade secret.
- 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 an operation 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 applications password recovery or “Forgot Password” feature.
- No sensitive data in requests to external sites: If the application maintains links to external sites, it must not disclose to the external site any sensitive data other than that required to conduct the operation with the external site.
Note: Sensitive data, as used in this criterion, includes business sensitive information, as well as session token(s) and authentication token(s).
- Webserver service protected against known vulnerabilities:The web server service running on the server which houses the application must not be vulnerable to publicly known exploitable vulnerabilities. Private information on the web server that is accessible remotely must be revealed only after the user is securely authenticated.
- No sample or test applications: The server must not make available any sample or test applications to remote users.
- No sensitive data in source code: The application must not disclose sensitive data in any source code that is accessible to remote users.
Get a printable copy of the Plynt Certification Criteria