User:Djgreen/Web Application Security

From an excellent source page at http://www.plynt.com/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 in web sites like owasp.org, webappsec.org, osstmm.org, etc.

Defend against Threat Profile

The application must demonstrate through testing that it defends against the threats specified in its threat profile.

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

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 through testing that a remote adversary cannot steal user passwords from the application.

Note I: The criterion requires that even after a user logs out, it must not be possible to steal the user’s password.

Note II: The criterion recognizes that there are social engineering methods that could be used to steal passwords outside the application. They are not within the scope of this criterion.

Protect against automated password guessing

If the application uses passwords for authentication, it must protect against brute force password guessing attacks.

Protect against manual 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: A 4-digit numeric PIN is an example of a password with less than 10,000 possible values.

Protect secret questions from guessing attacks

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

Protect configuration files and directory lists: The application must not reveal configuration files and directory listings to remote users.

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 or not. While an adversary can compile a list of links in the application by studying the html pages, such compilations are not considered directory listings.

Sensitive data not 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 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 launch a successful attack against the application.

Known, strong cryptographic algorithms

Any cryptographic algorithm used on the client to protect sensitive data must be a publicly known algorithm that is secure for the intended use.

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.

Session timed out after period of inactivity

The user session must be timed out after an appropriately defined period of inactivity.

Note I: The criterion requires that the application define and enforce a value for the minimum period of inactivity. It does not specify the minimum value.

Note II: The criterion requires that the inactivity period chosen to timeout a user be adequate to address the threat of an inactive session being hijacked by an adversary. The criterion recognizes that the minimum period could be different for different applications, based on their pattern of usage.

Re-authentication required after log out

Once the user has logged out, the application must require authentication before granting access to private pages.

Note: The criterion requires the application to invalidate the authenticated session at the server when the user logs out. If the application does not invalidate a user session at the server immediately on log out, it must take adequate protection against the session being reused.

Warning required for “Remember Me”

If the application provides a “Remember Me” feature, it must warn the user against enabling while using shared computers to access the application.

Password not stored in plain text for “Remember Me”: If the application provides a “Remember Me” feature, it must not store user passwords on the client machine in plain text or in a form that can be decrypted by an adversary. Old password required before changing password: The 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.

Random session token

Session token(s) must be random and difficult to predict.

Note: “Session token(s)”, as used in this criterion, is the set of tokens that the application uses to track the state of the user session, regardless of whether the token is implemented as a HTTP Cookie, a URL query-string variable, a Hidden form field value, or a combination of any of these.

New authentication token on log in

The application must assign new, random authentication token(s) to a user when the user logs in.

Note I: “Authentication token(s)”, for the purpose of this criterion, is the set of tokens the application uses to track the authentication status of a session and the identity of the user of that session.

Note II: If the application uses session token(s) to play the role of the authentication token, this criterion requires that the session token take a new, random value when a user logs in.

No sensitive data in requests to external sites

If the application links to external sites, it must not disclose to the external site any more sensitive data than is required by 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).

Services patched

The services exposed by the server must not be vulnerable to publicly known, remotely exploitable bugs.

Note: “Exposed”, as used in this criterion, refers to services accessible remotely.

Access to server filtered

The server must be protected by a filter that allows access only to ports required for the use and administration of the server.

Note: The criterion does not specify the ports that must be blocked or allowed; the specific ports may vary with applications. The criterion however requires that only those required by remote users and administrators be allowed by the filter.

No sample or test applications

The server must not make available any sample or test application 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.