Web site vulnerability checklist

Some of the security vulnerability to be considered during web development.

1. Cross-Site scripting: This means that a script can be sent and executed in a web request. A simple test to check this is write a sample javascript alsert script in the input control (ex: textbox) and see if in the postback the script is executed. Note that if the postback doesn't result in the alert message, then it doesn't mean the website is cross-side scripting safe. Google out for more possible script attacks.
2. Privilege Escalation: Make sure the URL cannot be changed (ex: query string parameters) and the user is granted access to the resource that he/she is not intended to
3. Clear-Text submission: This usually happens in non-secured sites. I.e. websites access via http protocol. Sensitive information (ex: passwords) are transferred as non-encrypted plain text. Where-ever possible either make the website as secured channel (https) or make sure the sensitive information is custom encrypted (client side) before passing over the network.
4. Cacheable HTTPS response: This usually means the rendered code (the code you see in viewsource) is cached by the browser in temporary internet files folder; making it prone for hackers to scan the temporary internet files for any sensitive information. Check the response header for the attribute cache-control. This should ideally be set to no-cache.
5. Autocomplete password: This mean the browser is capable of auto filling the password fields from the saved passwords. This is prone to attack, for hackers to steel the passwords from browsers. Set the autocomplete attribute of form tag to "off", to disable autocomplete on the complete web page or just on the password textbox, to disable autocomplete for just the password textbox
6. Unsecure Cookies: Cookie information can be read by an injected script (ex: type the below javascipt in the browser url bar javascript:alert(document.cookie);). If this alerts the cookie information in the plain text, then the cookie for the website is not secured - prone to hack. Secure the cookie by using httponly flag.
7. Web Server information leakage: Response headers has the information of web server in Server attribute. Revealing this information helps hackers to hack the system on the know security vulnerabilities. Remove the Server header information if found (http://blogs.msdn.com/b/varunm/archive/2013/04/23/remove-unwanted-http-response-headers.aspx)
8. Click-jacking: This means that your webpage is rendered in the iframe of the hackers webpage. End users may not see this and may start filling the username and password - and you know the rest. To avoid a web page to be rendered as part of an iframe, use X-Frame response header attribute. Set the value of this attribute to DENY (to completely deny) / SAMEORIGIN (allow only in the same origin/website pages).