LaMeH@CkeR

a. Find all linked content using both passive and active spidering (use Burp Spider).

b. Find all none linked content (use Wikto BackEnd, and Google by using inlink, filetype and site
keywords).

c. Find all default content (use Nikto, Wikto BackEnd).

d. Find all cached web site content from search engines (e.g. use the above Google keywords to check cached information).

a. Login functions (if concurrent logins are allowed then check for session hijacking ).

b. Logout functions (check if proper session termination is done).

c. User registration mechanism (to test trust boundaries).

d. Password recovery mechanism (the error messages allow user enumeration?).

e. Major Web Application functionality (find the purpose of web site functionality).

a. Programming language used (see ending of web page, php, jsp etc.).

b. Web Application platform used (see http header with Burp for banner advertisement or server ip
disclosure).

c. Web Server used (use Httprint).

d. Make sure if any Web Application firewall or proxy, or IPS is in front of the Web Application.

a. Check if client side cookie manipulation is done (with the use of Javascript or VBScript).

b. Check if client side session management exists (with the use of Javascript or VBScript).

c. Check if client side input validation is not the only input validation used (by passing client validation is trivial).

d. Check data transmission by making sure secure flag is set.

e. Check data transmission by making sure httpOnly is flag is set.

f. Check data transmission by making sure that proper SSL enforcement is applied by requesting pages without the s in https.

h. Verify non critical variables are passed through hidden fields (see how core web site functionality uses hidden variables).

i. Verify that no Javascript or Html or VBScript comments exits that reveal the web application internals.

j. Test all client side components (e.g. decompile Java Applets returned back from the web
application, use ollyDebuger to debug activeX controls).

k. Test possible function identifiers, and try to perform identifier guessing (e.g. /admin?licenseId=123).

a. Go through the whole authentication mechanism (e.g. locate login mechanism, password recovery mechanism, registration process etc.).

b. Test password and username security policies (e.g. validate and try to bypass the default password complexity and make sure each user name is unique and is associated with only one password).

c. Test lock out mechanism (e.g. brute force the web application using the Burp intruder)

d. Run a brute force attack or a dictionary attack against the web application, then log the errors returned from the web application and make sure there is no information disclosure issues.

d. Try to perform user enumeration using the responses from the server (e.g. try login using many different valid usernames with invalid password and analyse the error messages).

e. Test for auto generated credentials predictability if applicable (e.g. generate a large amount for usernames and
passwords to see how predictable are).

a. Test for session fixation. Go to the home page, capture the generated token session, then login, if no new session token is generated then session fixation is possible.

b. Capture a large amount of sessions tokens and test for token predictability (Use the Burp sequencer). If the tokens are predictable then there is session fixation issue.

c. Login using some valid user credentials then go back to the login page and login using some other user credentials, if no new session token is generated then there is a session fixation issue.

d. If the application does not support login but you can access sensitive data (e.g. such as payment details) using an old sessions then there is a session fixation issue.

e. If the web application relies only in cookie session, does not distinguish between GET and POST requests and is vulnerable to XSS then is also vulnerable to XSRF attacks.

f. If the session token is passed inside URL’s or the Http Header referer then there is a session information
disclosure issue (e.g. off site links, web server logs and proxy logs). g. Check if session termination de validates properly the user session by using terminated sessions access data.

h. Check if the cookie scope restricts cookies only to the current cookie.

a. Test for user information disclosure using the broken links.

c. Test for vertical privilege escalation by replaying requests of users with the same privileges trying to access resources of different users using the same privilege cookie.

d. Test for horizontal privilege escalation using the broken links identified earlier and try to replay requests of users with higher privileges using the a low privilege cookie.

e. Test for insecure access control implementations.

a. Test for SQL injections.

b. Test for XSS attacks.

c. Test for XSRF attacks (if concurrent logins are allowed and the web application is ).

d. Test for Path traversal attacks.

e. Test for Perform fuzzing.

f. Test for String format attacks.

g. Test for command injection issues

a. Check for default content using Nikto and Wikto Back End.

b. Check for default user credentials while trying to access administrative control panels.

c. Check for Http methods, such as OPTIONS, PUT, DELETE, TRACE and CONNECT.

d. Check if WebDav is enabled using a WebDav client.

e Check for weak SSL ciphers using SSLdigger or THCSSLCheck.

f. Check for directory listing.

g. Check Http header injection using the Line Feed character and return carriage character (encoded %0a and %0d).