This checklist is a helpful reference when performing a web application security test. It is not a complete list though - there are often application-specific vulnerabilities and subtle issues that this does not cover.
*Authentication* Logging in with an invalid user name does not reveal whether the user exists Accounts are locked after a number of failed logins An attacker cannot reset the lockout (e.g. by removing cookies) Can't easily lockout an account to cause a denial of service After login a redirect is issued, to prevent refresh attacks Both "change password" and "logout" functions are provided User is informed of last login time Change password requires provision of old password Passwords are proactively checked for strength Password is never revealed (e.g. in the source of change password) *Session Management* Session tokens are at least 128-bit Session tokens are unpredictable A new session is allocated at login (i.e. session fixation is prevented) Logout invalidates the session token on the server Cookie has "secure" and "httponly" options set and is non-persistent Sessions have an inactivity timeout Sessions have an absolute timeout *Injection Attacks* Cross-site scripting HTTP response splitting SQL injection LIKE pattern injection LDAP injection XPATH injection Mail header injection Directory traversal Null-byte injection Shell script / batch injection Server-side script injection (PHP, Perl, etc.) XML injection Try to bypass filters using over-long utf-8 encodings Try to bypass filters using wide-ASCII, or other Unicode equivalents *Content Checks* No script or CSS tags reference resources on other servers No script or CSS tags on a page that can be accessed over HTTPS use URLs beginning http:// Use of eval, document.write, innerHTML, etc. does not cause XSS Comments in files do not reveal sensitive information Frames/iframes, if used, have frame spoofing protection autocomplete=off is set on all forms asking for personal information Private IP addresses *Server Side Script Behaviour* Arbitrary redirection Arbitrary message inclusion File upload features restrict uploaded content to prevent compromise JavaScript Hijacking Scripts that cause write actions require POST with a CSRF token Scripts that act as an open proxy or mail relay Exponential format accepted Server compromise by uploading XML that sources a stylesheet Source code disclosure through scripts that allow read access to files *Authorisation* All protected resources check for a valid session All protected resources check for user permissions (forced browsing) Parameter tampering does not allow access to others' data Page-to-page flow is correctly enforced where required Form POST targets perform the same authorisation as form views *Miscellaneous* cache-control: private or stronger is used on sensitive pages All client-side validation is repeated on the server Site supports HTTPS, and sensitive pages forbid HTTP access All pages are displayed with status and address bars All URLs are expected from a customer's point of view No "Mixture of secure and insecure content" warnings *Server Configuration* There are no "orphaned" files (exist on the web server, but not linked) No backup versions of files are accessible (may reveal source code) No common insecure scripts (e.g. snoop servlet) are accessible Error messages do not provide overly-detailed information *Special Cases* Dynamic login questions: question cannot be changed by the user Application forms: restarting a transaction doesn't leak information Smoke & mirrors: generated emails are appropriately protected Domain auth: domain accounts cannot be locked out from the Internet Forgotten password: understand any information leaked or risks created *SSL Client Certificates* Does login check user name matches certificate? Can you lock out an account without holding the certificate? Is certificate required for every request? Does it check the certificate matches the session ID? Can you login using a self-signed certificate? Are test/pre-prod certificates separated from live? *Nested Web Service* Is the WSDL file accessible? Does access to the web service require a web session? Does it check the web session user matches the WS user? Also, most of this checklist also applies to the web service. Further, Very good article on Web Application Security Checklist: http://www.enterpriseitplanet.com/security/features/article.php/2214631/Web-Application-Security-Checklist.htm Various Security Checklists for your reference: http://iase.disa.mil/stigs/checklist/ -- You received this message because you are subscribed to the Google Groups "nforceit" group. To post to this group, send an email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nforceit?hl=en-GB.
