Thanks for the Post sandeep. On 29 July 2010 02:03, Sandeep Thakur <[email protected]> wrote:
> 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]<nforceit%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/nforceit?hl=en-GB. > -- Regards, kishore sangaraju -- 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.
