1-866-759-6824 | 
Guide to Plynt Certification Criteria
- What’s the logic behind the Plynt Certification Criteria ?
- My application faces threats that you don’t specify in the criteria. How will you address those?
- Why doesn’t the criteria talk about SQL Injection, Cross Site Scripting etc.?
- You missed criterion xyz!
- What do you mean by sensitive data in the criteria?
- The criteria says that the application must not allow passwords to be stolen even after the user logs out. Am I missing something?
- An application must re-authenticate the user after log out – Isn’t this what all applications do?
- You don’t mention SSL anywhere in the criteria
- Please explain, “No sensitive data in requests to external sites”?
- No sensitive data in source code available to users. What does this specifically describe?
- Why only these criteria? Does this cover everything?
- Why are you releasing this new version of the criteria?
What’s the logic behind the Plynt Certification Criteria?
The certification criteria specify the standards that an application must meet to establish that it has adequate security measures. An application must prove that it resists attacks as well as demonstrate the implementation of security features that enhance its security. Accordingly, the certification criteria reflect these two aspects: The “Security Protection Criteria” defined above in Section I, defines the threats that the application must show itself to be protected against. Section II, “Security Requirements Criteria” specifies the features and characteristics the application must maintain to enhance its security.
My application faces threats that you don’t specify in the criteria. How will you address those?
It’s quite likely that your application faces threats that are specific to its business context. For instance, a banking application needs to protect against the threat of funds being siphoned off, and a gaming application needs to defend against the rules of the game being violated. The certification criteria require the application to protect against these threats in the Criterion 2, above, Defend against Threat Profile. The threat profile is a customized listing of the threats relevant to that specific application. The threat profile is developed by the Plynt team with inputs from the application owner. The security engineers then develop test cases specific to the threat profile to verify that the application is safe against those threats.
Why doesn’t the criteria talk about SQL Injection, Cross Site Scripting etc.?
When writing the criteria, the authors first considered listing each individual attack that would be tested. However since the criteria is revised with the discovery of every new attack, and there was no agreed to standard taxonomy of attacks, it is reasonable to categorize all of the popular attacks under Criterion 1. Criterion 1, Safe against popular attacks, catches the attacks like those listed in this question. Some of the popular attacks the application must defend against are listed here:
Variable Manipulation |
Denial of Service |
Brute Force |
Bypass input validation |
Session Hijacking |
Session Fixation |
Content Spoofing |
Cross-site Scripting |
Cross Site Tracing |
Buffer Overflow |
Format String Attack |
SQL Injection |
OS Command Injection |
LDAP Injection |
XPath Injection |
SSI Injection |
Blind Injection attacks |
Directory Indexing |
Directory Traversal |
Authentication Bypass |
Filter evasion |
You missed criterion xyz!
Thank you for pointing out. We are constantly looking at ways to improve the criteria – so your suggestions will help.
What do you mean by sensitive data in the criteria?
Sensitive data is any data that if compromised could lead to:
- Loss to the business in financial or reputation terms
- Invasion of the privacy of individuals
- Adversaries gaining an advantage to launch attacks
Sensitive data includes business sensitive information, authentication credentials, session token(s), authentication token(s) and any details regarding application architecture that could aid an adversary in launching a successful attack against the application.
The criteria say that the application must not allow passwords to be stolen even after the user logs out. Please explain this ?
In general, the application must safeguard passwords. The note mentioned in Criteria 4 in Section 1 highlights that the password should be protected even when the user has logged out. Vulnerabilities in some authentication schemes enable the password to be stolen if a user who has logged out leaves the browser window open. This is described in the Paladion paper "Stealing Passwords via Browser Refresh".
An application must re-authenticate the user after log out – Isn’t this what all applications do?
Experience shows that not all applications enforce re-authentication after log out. To make matters worse, some platforms like .Net do not invalidate a user session immediately when their signout method is called. To learn more, please read the paper "ASP.Net Forms Authentication" from Foundstone. As the note points out, if an application does not invalidate a session immediately, it should protect against the session being reused. This Microsoft support document has examples of such protection.
You don’t mention SSL anywhere in the criteria
The criteria doesn’t mention SSL, or any specific encryption technology. The criterion “Protect sensitive data in transmission” requires that the application take adequate protection to safeguard sensitive data in transit. SSL is a good example of such protection. The criteria, however, does not demand SSL. The application is free to choose the technology, as long as it demonstrated that it protects sensitive data during transmission.
Please explain, “No sensitive data in requests to external sites”?
Links to external sites are often a source of data leakage. Along with the URL, the HTTP request also includes a referrer field that contains the URL of the page from which the request originated. If that URL (and the referrer field in turn) contains sensitive data, then that data will get logged in the web server logs of the external site. Administrators of the external site, or anyone who might gain administrator access, have access to those logs and can collect the sensitive information.
“No sensitive data in source code available to users”. What does this specifically describe?
This criterion refers to both client-side javascripts and the instances that occur when web server mis-configurations lead to server-side source code being available to adversaries. The criterion requires that any source code that’s available to users not contain sensitive data.
Why only these criteria? Does this cover everything?
The Plynt criteria focus on the high impact threats popular today. The certificate assures that an application is safe against those threats. The authors chose to omit criteria that are not essential or do not have a material impact on security. For example, the certificate does not require that the application catch all error messages. While that’s a good practice to follow, it would have been unduly stringent for the certificate. The standard only demands that no sensitive data be revealed in error messages as that has direct impact on the application’s security.
Why are you releasing this new version of the criteria?
New technologies, new threats, and new attacks are continually being created. The Plynt team periodically reviews the Plynt certification criteria to ensure the criteria address all known current threats. Details of the changes made to the Plynt Certification Criteria version 3.0 are listed below: Following criteria have been deleted:
- Warning required for “Remember Me”
- Password not stored in plain text for “Remember Me”
- Session timed out after period of inactivity
- Re-authentication required after logout
- Random token to track authenticated sessions
Version 2.0 Criteria 15 & 16 have been merged into Version 3.0 Criteria 8-“Sensitive data not stored on client” .With the criteria Password not stored in plain text for “Remember Me” we were trying to protect from storing the password in plain text on the client’s machine.
The “Warning required for Remember Me” is just a message to inform the user that his credentials will be stored on the computer he is accessing the application from. If the user chooses to ignore the warning and click OK, the application will not protect him. We felt it didn't really deserve a criteria on its own.
Version 2.0 Criteria 13, 14 & 18 have been merged into Version 3.0 Criteria 1 - “Safe against popular attacks” .When we are talking about strong session management, we are worried about our session being hijacked. Session hijacking is one of the popular attacks. So, session timeout, re-authentication required on logout as well as the necessity of a random token become a part of strong session management and are hence merged under “Safe against popular attacks”
Following Criteria have been modified:
Version 2.0 Criteria 17 Old password required before changing password has been modified to Version 3.0 Criteria 12 Re-authentication required on sensitive activities.
Application must re-authenticate the user before allowing the user to change the password. Note: This criterion does not apply for the special case where the user has forgotten the password and resets the password using the application’s password recovery or “Forgot Password” feature.
Along with change password option there can be other critical operations where one needs to re-authenticate; re-authentication could mean entering the same password as login or a different password as in the case of banking transactions. To ensure that all such areas are also included, this criteria has been modified accordingly.
Version 2.0 Criteria 7 Protect configuration files and directory lists has been modified to Version 3.0 Criteria 7 - Insecure configuration settings on servers accessible directly by users.
Insecure configuration includes much more than the config files and the directories. It includes the Operating System, web servers and the application configuration files, hence renamed to Insecure configuration settings on servers accessible directly by users.
Version 2.0 Criteria 6 Protect Secret Questions from guessing attacks has been modified to Version 3.0 Criteria 6 - Secure Forgot Password Implementation
A secret question/answer implementation is just a part of a complete Forgot Password implementation. Protecting just the secret question didn't make sense if the entire forgot password implementation itself was insecure.
Following Criteria have been Merged
Version 2.0 Criteria 20 - Services patched & Criteria 21 - Access to server filtered have been merged to Version 3.0 Criteria 14 Webserver protected against known vulnerabilities
The webserver must be protected against all known vulnerabilities. While it’s most important that every remotely accessible service is securely implemented, the Plynt Certification concerns itself just with the components directly associated with the application; this includes the web-server. This is hence mandatory to get the Plynt Certification. However since data used by the application can still be stolen through other misconfigured remote services, we strongly recommend you still fix all findings brought to your notice through the report. This however is not mandatory for the Plynt Certification as you might not always have complete control over these services; specially in the case of shared hosting.
