Basic Web Application Vulnerability Tests
by Eric Thomas Black

This document is meant to provide a basic overview to the most basic and common security concerns when implementing web based products. The purpose of this document is not to provide a comprehensive list of all possible vulnerablities but rather to establish a baseline security model.
Passwords

  • Passwords should have a minimum and maximum length set
  • Users should not be able to selet their username, easily guessed, or common passwords
  • For sensitive accounts the addition of non-alphanumeric characters should be considered
Cookies
  • Cookies should not contain password information
  • Usernames and other identifying information should be encrypted
  • Open the cookie in a text editor to ensure that important information is not in clear text
URL Manipulation
  • Can users get to pages they should’t through direct manipulation of the URL Test by adding common directories and files such as index.html. A misconfigured index file can reveal the entire directory structure of the site.
  • Check that session IDs can not be changed merely by changing the number in the URL.
Source Code
  • Check the source code of each page for information that a user should not have. Check for comments or references that may reveal user logins, passwords, directory structure, or the identity of engineers. As HTML code is readable by any browser it should be kept free of comments when on a production machine.
  • Avoid using hidden tags as much as possible. It is possible for an attacker to change those values. If a hidden tag contains price there should be a mechanism that verifies that value on the backend as well.
Buffer Overflow
  • Ensure that forms have a cap on the maximum number of characters entered into the fields. If possible this should be set without the use of hidden tags.
Sever Side Includes
  • Make sure that any SSI scripts that are used includes a pre-parser script to read in any HTML file and strip out any unauthorized SSI lines before passing it on to the server.
Business to Consumer specific considerations:
Registration Subsystem
  • Test to see if false and incorrect information can be entered
  • Check to see if the application checks for a valid email address
  • Attempt to view registration information of other individuals.
  • Attempt to change registration information of other individuals
Login Subsystem
  • Check for the ability to have multiple current login sessions
  • Check to see if account is disabled after multiple login failures • Check to see if a daily report on failed login attempts including source IP address, timestampt, Cookie Session ID and User ID is generated
Shopping Cart Subsystem
  • Validate Credit Card for valid address and expiration dates using generated credit card numbers and address information
  • Test to see if the Credit Card Account Billing Address is requested and validated
  • Test to see if the order can be placed with a Ship To address that is different than the Billing Address Can the Ship To Address be cross referenced against known fraudulent addresses
  • Does application have the ability to generate a daily transaction report that contains source IP Address, Cookie Session ID, Credit Card Number, Account Billing address and ship to address.