Prior to testing it's important to determine what parts of the application require authentication and authorization. Security testing should approach the application from both a non-auth and pre-auth perspective. The goal of the non-authenticated assessment is to identify any security risks which are openly exposed by the application. The authenticated assessment is to identify the security risks once a valid user logs in. For an authenticated assessment ensure that the project team provides credentials in advance.
Browser (e.g. Firefox, Chrome) Manual crawling of the application and support manual testing of the application. Firefox has a number of built-in plugins such as Web Developer and Firebug that can provide easily viewable information on the source including hidden fields and HTML parameters.
Burp Suite Pro Web proxying tool that supports automated crawling, intercept and manipulation of HTTP requests, replay, injections, randomness of session identifiers, etc. The pro version also supports passive and active scanning.
Nikto (Kali distro) Web server vulnerability scanner that can fingerprint the web server and identify any known vulnerabilities with the web server software or installed application components (e.g. Tomcat) residing on the web server.
Nmap (Kali distro) Port scanner that can quickly identify open application ports on the systems as well as fingerprint the services bound to each port. Nmap additionally provides power in the NSE scripts which can probe services for detailed information, e.g. SSL supported ciphers.
Web Inspect Automated vulnerability scanning of web applications and web services. This is particularly useful for large, complex applications.
SQLmap (Kali distro) SQL injection and blind SQL injection tool used to pinpoint and execute proof of concept SQL injections.
Dirbuster (Kali distro) Brute-force directory guessing to find hidden web interfaces (e.g. admin pages, server status pages).
In order to gain better understanding of the risk associated with a vulnerability, one must gather contextual information related to an application's use.
For example, a cross-site scripting (XSS) vulnerability found post-authentication on an internal app accessible to only 10 employees within the organization will have a lower risk of exploitation than a pre-authentication XSS found on an Internet-facing app.
Questions to ask:
Business Purpose What business function does the application serve? How important is the application to the success of the business' goals?
User Population How many and what type of users are anticipated to use the application?
Data Types What type of data does the application process and/or store? Are there any PII or PCI elements?
Access Roles How many roles does the application offer and to what granularity?
Depth of the Application How many pages/components does the application consist of? [Crawl the application]
Web/application server What web and application server product does the application run on? [Fingerprint the front end]
Back end server Is data stored in a relational database (e.g. SQL) or flat file? [Fingerprint the back end]
Does the application set redirect or forward targets within parameters? Are redirect(s) and forward(s) not validated by the server prior to redirecting the user?
Does the application display to screen full debit or credit card numbers? Does the application store PCI data in an unencrypted format? Does the application transmit PII/PCI data over an unencrypted channel? Does the application display to screen full SSN? Are application tokens or keys hardcoded into source code or HTML source pages? Does the application use weak cryptography (e.g. keys less than128 bits or crypto protocols with known vulnerabilities)?
Is the web server running outdated or unsupported software? Are built-in accounts still enabled or set with default passwords? Are built-in extraneous features (i.e.debug pages, sample code, demo/test functionality) accessible? Do application error messages reveal stack traces or debug information? Does the web server support unnecessary HTTP methods?
Does the application display object references (e.g. acct=100001) in the URL? Can a user access other application functions for which they are not authorized? Are administrative functions directly accessible via direct URI reference?
Is the application vulnerable to persistent (stored) XSS? Is the application vulnerable to reflected XSS? Is the application vulnerable to Cross-Frame Scripting (XFS)?
Are session IDs displayed in the URL string? Are session IDs vulnerable to session fixation? Are session IDs predictable? Are session cookies exposed to unauthorized access? Are sessions not properly terminated after a timeout or after a user-initiated termination? Does the application lack a proper logout function?
Does the application submit authentication credentials over an unencrypted connection? Does the application store authentication credentials in cleartext or weak format? Do application functions allow for anonymous enumeration of valid user accounts? Does the application allow for caching (i.e. remembering) of a user password?
Is the application vulnerable to SQL injection?
Custom-coded apps (both in-house and 3rd party), commercial of the shelf (COTS) app, web service, thick client/desktop app