Checklist

Page 1
Checklist

Page 2
Checklist

Page 3
Checklist

Page 4
Checklist

Page 5
Checklist

Page 6
Checklist

Page 7
Checklist

Page 8
Checklist

Page 9
 Checklist

Important Notes (Read First!)

1. If the website is being hosted by Akamai or a CDN environment (do a nslookup on the URL and if redirects to a aka
this is by performing an nslookup using the following query “origin-<url name>” or “origin.<dns name>” If you are unab
OpenVAS/Nessus target origin.www.example.com or its real IP.

2. Some of the steps will have references to the OWASP Top 10 (ie. A1: Injection) and 2011_cwe_sans_top25.pdf rep

3. Each check has a risk rating which you can use in your report. This rating is just a suggestion and the pentester ca

4. The below sql examples use ms sql. You will need to modify the queries depending on the websites backend db. Yo
ting from the webdev team or through reconnasiance (although you should verify with the webdev team). Two good re

Items

Preparation / Scoping Activity

Determine the technical POC for the site.

Discuss the scope of the test, expectation and deliverables to the customer.
1. Understand and Inquire about the site to be assessed
- brief description of the app
- contractor will be fixing the issue?
- how critical is the site (i.e. e-commerce, e-banking)?
- what is the session management being used (cookie, non-cookie, bespoke/custom, etc)?
- is there a web application firewall or any application security layer present?
- where is the physical server located? In the cloud? I2P? China?
- is there an application proxy in front of the web servers to filter malicious request?
- site hosted by a third party location / network?
- site hosted by a virtual machine?
- site's database is hosted by another machine in a logically controlled environment?
- is there any special protocol used that we need to be aware of (i.e. Zigbee)?
- are we testing the stable release or just the beta version of the code?

Page 10
 Checklist

Discuss the scope of the test, expectation and deliverables to the customer.
2. Methodology of the activity – i.e. to be scanned externally form the internet
3. Technical Scope - passive and active scan
- (if necessary) unauthenticated and authenticated (3 accounts – admin and 2 regular
users) - verification process which includes reflected exploitation
- impact on the site (i.e. more logs, possible disruption, etc)
- technical out-of scope (i.e. DdoS, Social Engineering, etc)
- using open-source and proprietary tools
4. Limitations - only scanning standard TCP/UDP ports
5. Schedule – time and date (specify the preferred timezone – GMT, EST, EDT, etc.)
6. Reporting - executive report and supporting documents will be provided after the campaign
Use7. your
Remediation - discuss
favorite text programthe(ie.vi,
matrixemacs,
for resolving Critical, High,
Kate, notepad), Medium
to keep detailvulnerabilities
notes during the pentest. These
will8.become
Contactinvaluable
/ Steering come
Committee
report–time
provide
and the
alsocontacts incase
to reference problem
in the may arise
future.
(If necessary) Verify the 3 accounts are working.
1. Admin level account will be used for all test including exploring all functionality.
- Be careful using this account especially in the “Profile” page because during the test, it tries to change
The profille details like username and password and you might not be able to use it anymore.
If possible avoid the “Profile” page or scan it manually. In the Burp scanner tab, input the parameters to
Skip from test so that those URL's will not be included in the scan or remove them prom the scope.
2. The regular level account will be used for other testing and exploring regular user functionality.
3. The other regular level account will be used for testing account lockout and maintenance.
Identify the IP address or the hostname / URL of the target

Basic Scanning Checks

Identify the session management being used (cookie-based, bespoke/custom). Possibly no session
management is used but HTTP authentication (basic, digest, NTLM, etc) and Sessionless state (hidden
form, cookie, etc).

Is the site hosted in the network or outside (i.e. External Hosting, Cloud, etc)

Check for Web Application Vulnerabilities using automated tools (i.e. use Burp, W3af, Armitage, etc.). Don't
include change password password and username functionality while doing automated scan.

Using nmap (and/or other tools) identify open TCP & UDP ports as well as the operating system

Check for OS level vulnerabilities using automated tools (Nessus or OpenVAS) based on the information from the
previous step

Page 11
 Checklist

Check http://<url>/robots.txt for any interesting info. You can do this by browsing to the url itself or using a command line
tool such as wget, curl, or links/lynx.

The site redirects to internal URL's which violates security policy because it's not standard for those systems
to be exposed externally

Malware or infection checks

Verify if the email address of the site's contact is compromised

Verify online reputation if there are hits of issues related to the site (You can also use Jason's script)

Online Information leakage (wikileaks, pastebin, googlehacks, NVT – automated using wikto / diggity and
manual, shodanhq, social sites, forums, blogs, etc)

Authentication Checks (If applicable)

Verify that a secured protocol (HTTPS) is wrapped to process password reset, registration and pages that
requires a login

Error response during authentication

Improper Restriction of Excessive Authentication Attempts. Account lockout verification (Use 1 regular account
for this test) .

If any authentication forms are found, test authentication with the following steps

Missing authentication for critical functions. Test if you can perform actions which should require an authentication
account without authenticating

Is their a two-factor authentication implemented especially for accessing privileged root level or accounts
which can view session token? If not available, at least a minimum password length of 15 characters for
administrator accounts.

Page 12
 Checklist

Implementation of proper password strength and complexity. The longer the password the more
combinations possible combinations of characters exist and is hence more difficult to guess. (Try to change
your current password)

Password Change Functionality

Remember Me Functionality

Secure password recovery logic flow.

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet
http://carnal0wnage.attackresearch.com/2011/06/abusing-password-resets.html

During password recovery, verify if all questions can be achieve from 1 location.
(i.e. If you reset your credit card online access, check if most of the recovery questions are related to the
credit card physical information) https://krebsonsecurity.com/2011/12/loopholes-in-verified-by-visa-
securecode/

Session Management Checks (If applicable)

Session ID Name Fingerprinting

Session ID Length

Page 13
 Checklist

Incorrect Authorization Handling.

Session Fixation (sites with login section)

Concurrent Logins using the same account

A3: Broken Authentication and Session Management If any authentication forms are found, test authorization
with the following steps (check burp result)

LogOut Button

Session token generation weaknesses

Page 14
 Checklist

Token Disclosure in Logs

Generic Input Validation Checks

For any input fields (anywhere you can type), perform the following tests.

Note: If the site is XSS vulnerable and you can't produce a PoC, change the payload in the URL to 1-alert(1).
Perform direcory brute force before performing active scan and spidering (use Burp Tool for this)

If you find any fields that allow you to upload a file (Check Burp result for upload functionality found)

Page 15
 Checklist

Capture User Data and Bypass

URL Redirection to Untrusted Site

Application Logic Checks

A7: Insecure Cryptographic Storage & A8: Failure to Restrict URL Access Ensure any sensitive/confidental
data is not available without a username/password & encryption

Hard-coded credentials or keys. The software contains hard-coded credentials, such as a password or
cryptographic key, which it uses for its own inbound authentication, outbound communication to external
components, or encryption of internal data.

Check which HTTP methods are allowed (PUT and DELETE are dangerous)

Missing Encrypted on Sensitive Data

Internal IP Disclosure

Secure HTTPS content can be accessed using an insecure HTTP protocol

Architecture (This is important, ask for a network diagram if possible)

An application server located directly on the public network without firewall protection

Shared Resources (Physical Host on Virtual Machine, Switches, etc) between internal LAN, DMZ and
external network
i.e. 1 Physical host stores both the Application VM in DMZ and another Database VM in LAN

Page 16
 Checklist

Application and Database on the same machine

Application machine and Database machine in the same segment

System Process

If the site has no reset password functionality, will the administrator of the site define it for them?
(i.e. Airline ticketing system don't give their business partner an option to reset password, the outlet will
contact the airline ticketing admin to reset it for them)

To identify possible fraud, call the customer service of a company and get more details of the agent's identify
and location. Call the corporate complain desk and check if you will end up talking to the same call center
agent you previously spoke with.
https://krebsonsecurity.com/2011/12/loopholes-in-verified-by-visa-securecode/ (check the comments)

Others

Run whatweb with the following options (./whatweb <site to be scanned> --color=never -t 20) to determine
what web technology(ies) are being used. Include the results in the final report. *Note – see note #1 above
regarding Akamai

Run an nmap scan (nmap -A <ip>). Include any pertinent information in the final report. *Note – see note #1
above regarding akamai

Write report using template

To DO's

Check new techniques found in the book

Page 17
 Checklist

Load balance testing

Read SANS books to see if anything should be added

Review all books for anything else

Limit the use of dynamic SQL code by using prepared statements, queries with parameters, or stored
procedures whenever possible. (How to verify this in the application?)

Page 18
 Checklist

if redirects to a akamai.net domain, then it is) then ensure you perform scans against the site's real ip. You can usually determine
me>” If you are unable to determine it using this tecnique, then ask the web dev team. For scanning OS level issues using

sans_top25.pdf report. You can go here http://mcaf.ee/ov541 for additional information

nd the pentester can adjust the rating based on additional information gathered throughout the test.

ites backend db. You should obtain what type of db before tes
team). Two good resources to help with sqli are: http://sqlzoo.net/ & http://pentestmonkey.net/cheat-sheets/

Sub Steps (if applicable)

Setup a conference call if needed to outline the methodologies or you can email the items that you need clarification.

Page 19
 Checklist

Setup a conference call if needed to outline the methodologies or you can email the items that you need clarification.

*if 2 or more assessors are involved on assessing a site, use an online collaboration tool to share the result across (i.
framework, sharepoint, wiki, excel, etc)

Use any tools to identify this or contact dev (Refer to item #1 about akamai hosted sites)

Check this using Burp, for critical system like online banking, non-cookie based session management mechanish is u
as bespoke/custom. Ask the developer to confirm if its obfuscated.
Note:. If HTTP Authentication and Sessionless state are used, focus on the non session related checks (look at acc
control or code injection issues).

Confirm the value of the token if indeed its the real token being used by the application. Change a single value in the
and try re-submitting it to the application. Changing the value of the token should give you an error message. Use bur
tamper data plugin.

You can also check the vhost result (http://www.yougetsignal.com/tools/web-sites-on-web-server/)

Run 2 scans using authenticated and un-authenticated. Make sure you manually browse all the links and buttons/drop
the site before performing automated spidering.

Target the real IP address and not the IP of akamai

Use nmap-enum.nse

Target the real IP address and not the IP of akamai

Page 20
 Checklist

Check if some of the links are related to the following: Identity System Management, Webmail System and some Main
Systems.
Verify infection using:
Malzilla tool
http://urlvoid.com/
http://safeweb.norton.com/
http://wepawet.cs.ucsb.edu/index.php (for http only)
Use this link to verify (check the result of Burp automated scan all the email address found)
https://shouldichangemypassword.com/

Go to the following site and check

http://xssed.com/
http://zone-h.org/
http://www.vs-db.info/
http://www.unmaskparasites.com/
http://www.google.com/safebrowsing/diagnostic?site=EXAMPLE.COM
http://www.mywot.com/
http://www.thehackernews.com/search/label/Hacker News
www.google.com (check also the cache version)
Search the web for possible information leakage related to the site. When using google search engine, take note of th
result, it will provide wealth of information.

http://www.wired.com/images_blogs/gadgetlab/2012/09/Screen-Shot-2012-09-04-at-3.52.38-PM.png

Enter an valid username and invalid password, if the error response only says Invalid password (not generic error). Login pa
bruteforce to guess the password

Try 3 to 10 attempts (determine if account lockout policy is implemented)

A1: Injection See if the login fields are suspecitble to sql injection by using the following query: <username>'-- (this sh
work for mssql, you need to include a space after the double hyphens for mysql)

Check if there are hidden URL to access a higher functions without authentication i.e. /admin/ImpersonateUser.jsp
/admin/
?admin=true
?Id=123 or ?docid=123 (you can used burp to guess which ID number is successful)

Most applications use HTML forms-based authentication. External facing critical webapps should use two factor
authentication (something you have + something you know) especially for the administrators of these apps. This could
either a hardware or software token which requires a PIN code, it can be restriction by ip or mac address along with u
and password, etc.

Page 21
 Checklist

Not enforcing strong password quality. Register / Change your account in the web application and try setting the pass
Check also the password set in the applciation to determine the application password handling:
1. Very short or blank password
2. Common dictionary words
3. Set to the same as the username
4. Still set to as default value
5. No combination of alpha numeric for characters
6. Applications that validate only the first n characters – try to remove some characters during
the test (password should be valid in full)
7. No case-sensitive checking – try to use all upper caps
8. Check if application generates password automatically – check for patterns

Use minimum password length of 8 characters for standard users:

Important applications: Minimum of 8 characters in length
Critical applications: Minimum of 15 characters in length
Highly critical applications: Consider multi-factor authentication

Verify this functionality if present and give users option to change their password:
1. Can change their password quickly
2. Periodic enforced password change (30 – 90 days)

This is an insecure design and leave user exposed to attack. Check the cookie value if uname=username or
RememberUser=1328.... or any saved data in the cookies present (check for predictable values). The attacker can
the cookie value to guess / attack a user without authenticating.

If the system will use a username or email address to verify the existence of the user account without captcha or secr
(not basic questions like mother's maiden name) before pushing the reset, then a bruteforce attack can be done to ma
username or email address.

https://www.owasp.org/index.php/Session_Management_Cheat_Sheet

Session ID should be generic such as “id” . If you see that the session ID is PHPSESSID (PHP), JSESSIONID (JSE)
can be easilly fingerprinted.

Session ID must be atleast 128 bits (16 bytes) to prevent bruteforce attacks. An attacker can go through the whole ran
values and verify the existence of valid sessions.
Note: 8 bits = 1 byte = 1 character

Page 22
 Checklist

Verify if cookie is not randonmly generated per session. It means that even if your admin, your cookie should change
randomly in every session. Using Tamper Data plugin or Burp Sequencer or other web proxy tools. Dont use “static” t
tokens created from username (check hex, base64, XOR value of a string). Log in from different machine using the sa
user.
Session ID should change when the user logs IN to the application. “The web application authenticates a user withou
invalidating the existing session ID, thereby continuing to use the session ID already associated with the user”. If it did
change the sessionID after a successful login, follow the procedure to confirm the vulnerability.
1. Use another machine and login using the sessionID of the victim using Tamper Data plugin
2. If the login is successful and no new token is issued, then its vulnerable. (You can also use
URL to test it www.example.com/login.php?Sessid=xxxxx
Note: If sessionID is not provided by the application before login, its not vulnerable.

Attack Form: http://www.youtube.com/watch?v=jxwgpWvRUSo

1. Attacker will supply the sessionID to the victim (attacket don't need to be a thief to know
the session ID).
Sample XSS to pass ID= <script>document.cookie=”JSESSIONID=xxxxxxx”;</script>
2. Attacker will capture the sessionID from the victim and use it (M-I-T-M or a vulnerability
Like XSS to capture cookie or session).

Note: A fresh session should be created after successful authentication to mitigate this problem

Session should be terminated if another session is open from another location using the same account. Any existing s
belonging to the user should be disposed of as if she had logged out from it. It should trigger an alert if possible. Test
conditions:
1. The same local network.
2. Different ISP provider

If the site includes a session id in the URL, try to open this URL in a different browser/computer and check if you are l
to the account (check burp authenticated scan result)

Log Out button should be visible for users.

Log out first. Increment the value of the token, if successfully access other users, meaning the randomness of the ses
token is weak and authentication is easy to break.
Note: This will work if cookie value don't include username=xxxx parameters.

Page 23
 Checklist

Check if token is transmitted via URL. Possibly the logs will be store in the web/user browser logs. Inurl:jsessionid. C
the application if administrators can view session logs. Use CacheViewer plugin or in the browser type about:cache t
the history of your browser and check for sessionID value.

A1: Injection If you are unsuccessful in testing for a traditional sqli queries, but you still believe the db is suspectible (b
you are getting db errors or anomalies of some kind), then test for blind sqli. A good query to use is ')waitfor delay '0
This is telling the db to wait 10 seconds before returning the results. If it takes at least 10 sec to load the page, then it
suspecitble. Also, you can test for SQL using your accounts. Use SQLMAP or HAVIJ tool to further the SQL attack if th
is vulnerable. For ' sql issue, use Vulnerability Master tool.

A2: Cross-Site Scripting (XSS) In every page which has an input field, drop down menus, input aaaaaaaaa or 1111111
click the dropdown menu choices and proceed with the search. Go to the Burp-Proxy-History and scan the previous r
with GET method with parameter value aaaaaaaaa or 111111111.

Note: Browse the whole application/site, check if the URL changes and if you can possibly input some statement. Exa
site www.example.com, after browsing a couple of pages you notice it changes to www.example.com/index.php?user
Always note the = operator in the URL. You can exploit the GET parameter by inputting malicious tags like www.exam
com/index.php?user=<script>alert('xss')</script> or you can set martin as the payload for fuzzing using intruder.

A2: Cross-Site Scripting (XSS) Test for XSS by using the following strings: <script>alert('xss')</script> and \";alert('XS
two strings that have worked for me in the past. If you get you get a popup box with “XSS” then it is vulnerable. This is
considered a non-persistent (or reflected) XSS vulnerability. You can use xss_assistant or burp to automate Rsnakes att
Note: Test basic scripts for username and password field (XSS can be done in POST/GET Request, HTTP Headers and Cookies

A2: Cross-Site Scripting (XSS) Test the Referer and/or User-Agent HTTP Headers (ie. try to include a single quote at
of either of these values to see if it produces an error. You can do this with Burp or Tamper Data)

Try to upload a backdoor program (ie. a metasploit payload) and see if you can execute it by going to that file directly
URL path

Upload 4 files with a size of 10/50/100/500 MB respectively. Lacks of restriction in size or number of upload files (whic
resource consumption issue)

Page 24
 Checklist

1. if the input requires only 3 char (input 3 chars in the field), intercept the request using burp
and input more chars and check if it fails or not, check in the code for maxlength attribute to
determine the chars required. If success, meaning the client-side validation (3 chars only) is
not replicated on the server. You can further the attack via SQL, XSS or Buffer Overflow.
Note: Check for password / username change field

2. Check for forms or registrations that supports javascript validation. For instance, zipcode
requires only numbers, while name only requires characters. This are restricted in the
javascript in the client-side. Check to intercept and bypass those client-side restrictions

Note: You can disable javascript in the browser to bypass this client-side checks

In the URL, redirect a query or search to another site. Look for equal (=) sign and supply the site after it (i.e. www.cnn
add this at the last string ?url=http://www.xssed.com If the page will go to www.cnn.com then its vulnerable. For exam
https://www.myseus.schneider-electric.com/mysedv/search.do?newSearch=www.cnn.com

Use the http-methods.nse (run both website and original IP)

The software does not encrypt sensitive or critical information before storage or transmission.

Use burp or http://web-sniffer.net/ (use the original IP not the akamai IP)

Access the site using both HTTP and HTTPS

Page 25
 Checklist

Ensure the least number of ports are open (rating: high)

Check the version and verify if there are vulnerabilities. Exploit it and if successfull, give a high rating

Page 26
Checklist

Page 27