Web Application Security Certification

What is Web Application Security Certification?

This is an award winning security assurance programme, launched by Plynt in 2006 and used by software development companies, software as a service (SaaS) providers, service providers and organisations using or developing their own web applications.

The Plynt certification programme measures a web application's ability to defend against relevant and specific security threats, whilst benchmarking the security of the web application against globally accepted security standards - OWASP, OSSTMM, SANS CWE Top 25, WebAppSec and PCI DSS.

Our web application security testing and security source code review services benchmark web applications against the Plynt Certification Criteria, detailed below.

The awarding of the Plynt Certificate establishes that a web application has implemented measures to guard against remote adversaries and protect against a wide range of threats.

Below are listed the criteria that an application must meet in order to be awarded the Plynt Certificate.

The certification programme is composed of 16 criteria. These are organised in two sections:

Section 1, “Security Protection Criteria”, identifies the defences an application must demonstrate to meet the certification standard.

Section 2, “Security Requirements Criteria”, specifies the features and behaviour an application must have to meet the certification standard.

Section 1.  Security Protection Criteria

1. 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 organisations 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.

2. 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 unauthorised 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 authorisation rules of the application.
   Note III: This criterion applies to high and medium risk vulnerabilities that let threats be realised.

3. Protect sensitive data in transmission: The application must take adequate measures to protect sensitive data from being stolen over the network.

4. 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 recognises 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.

5. 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.

6. 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.

7. 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.

Section 2.  Security Requirements Criteria

1. 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.

2. Sensitive data not hidden in pages: The application must not hide sensitive data in html comments or hidden form fields embedded in the pages.

3. 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.

4. Code obfuscation for secrets: If Javascripts, Applets or ActiveX controls contain secrets, they must use strong code obfuscation techniques to protect the secrets.

   Note: The secrets the above criterion refers to include cryptographic keys, passwords, and algorithms considered a trade secret.

5. 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.
   

6. 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).

7. 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.

8. No sample or test applications: The server must not make available any sample or test applications to remote users.

9. No sensitive data in source code: The application must not disclose sensitive data in any source code that is accessible to remote users.

What to do next.

Contact us on 0844 488 0963, email us at info@securityalliance.co.uk or complete our Enquiry Form to discuss requirements, get an online demonstration, request a sample report or arrange a meeting.