Web Application Security Checklist

Web Application Security Checklist

Somnath Guha Neogi(OSCP,CNSM)

Test password quality rules Test for username enumeration Test resilience to password guessing Test any account recovery function Test any "remember me" function Test any impersonation function Test username uniqueness Check for unsafe distribution of credentials Test for fail-open conditions Test any multi-stage mechanisms Test authentication bypass using SQL injection

Test tokens for meaning Test tokens for predictability Check for insecure transmission of tokens Check for disclosure of tokens in logs Check mapping of tokens to sessions Check session termination Check for session fixation Check for cross-site request forgery Check cookie scope

Understand the access control requirements Test effectiveness of controls, using multiple accounts if possible Test for insecure access control methods (request parameters, Referer header, etc)

Fuzz all request parameters Test for SQL injection Test for reflected XSS Test for HTTP header injection Test for arbitrary redirection Test for stored attacks Test for OS command injection Test for path traversal Test for script injection Test for file inclusion Test for SMTP injection Test for native software flaws (buffer overflow, integer bugs, format strings) Test for SOAP injection Test for LDAP injection Test for XPath injection

Identify the logic attack surface Test transmission of data via the client Test for reliance on client-side input validation Test any thick-client components (Java, ActiveX, Flash) Test multi-stage processes for logic flaws Test handling of incomplete input Test trust boundaries Test transaction logic

Test segregation in shared infrastructures Test segregation between ASP-hosted applications

HTTP methods>

Sensitive Data Secrets are not stored unless necessary. (Alternate methods have been explored at design time.) Secrets are not stored in code. Database connections, passwords, keys, or other secrets are not stored in plain text. Sensitive data is not logged in clear text by the application. The design identifies protection mechanisms for sensitive data that is sent over the network. Sensitive data is not stored in persistent cookies. Sensitive data is not transmitted with the GET protocol.

Administration interfaces are secured (strong authentication and authorization is used). Remote administration channels are secured. Configuration stores are secured. Configuration secrets are not held in plain text in configuration files. Administrator privileges are separated based on roles (for example, site content developer or system administrator). Least-privileged process accounts and service accounts are used.

Platform-level cryptography is used and it has no custom implementations. The design identifies the correct cryptographic algorithm (and key size) for the application's data encryption requirements. The methodology to secure the encryption keys is identified. The design identifies the key recycle policy for the application. Encryption keys are secured. DPAPI is used where possible to avoid key management issues. Keys are periodically recycled.

All input parameters are validated (including form fields, query strings, cookies, and HTTP headers). Cookies with sensitive data are encrypted. Sensitive data is not passed in query strings or form fields. HTTP header information is not relied on to make security decisions. View state is protected using MACs.

The design outlines a standardized approach to structured exception handling across the application. Application exception handling minimizes the information disclosure in case of an exception. The design identifies generic error messages that are returned to the client. Application errors are logged to the error log. Private data (for example, passwords) is not logged.

The design identifies the level of auditing and logging necessary for the application and identifies the key parameters to be logged and audited. The design considers how to flow caller identity across multiple tiers (at the operating system or application level) for auditing. The design identifies the storage, security, and analysis of the application log files.

Check for DOM-based attacks. Check for frame injection. Persistent cookies. Sensitive data in URL parameters. Forms with autocomplete enabled. Follow up any information leakage Check for weak SSL ciphers.