Introduction
Many security specialists rely solely on web application vulnerability scanners for security testing. Depending only on automated vulnerability scanners will lead to a false sense of security because it leaves out many tests that can only be run manually.
In this article we will give you a better understanding of the capabilities and limitations of automated vulnerability scanners so you can make educated decisions when conducting web application security assessments.
What is a web application vulnerability scanner?
Web application vulnerability scanners are the automated tools that scan web applications to look for signatures of known security vulnerabilities such as cross-site scripting, SQL injection and others. There are several commercial and free vulnerability scanners available on the market – here is a list of the most popular tools:
- AppScan (IBM)
- Burp Suite (PortSwiger)
- Nessus (Tenable Network Security)
- NeXpose (Rapid 7)
- WebInspect (HP)
- Websecurify Suite (Websecurify)
- Zed Attack Proxy (OWASP)
Some of the scanners require nothing except the link to the target websites, while others need some configuration before you run them. Most of them have advanced configuration options where the user can fine-tune the scanner (disable unneeded modules, set up the maximum number of threads, configure test and risk levels, etc.) before running the test.
What do vulnerability scanners identify?
Despite the difference in configuration, the automated web app scanners mentioned above, and others on the market, can detect the following:
- Some SQL Injections using common techniques like causing database errors (i.e. by sending a single quote), a time delay (by injecting the “sleep()” function in the query on MySQL server or “waitfor delay” on MS SQL server)
- Most of the reflected Cross-site scripting (XSS) vulnerabilities – where malicio JavaScript code can be injected in the request and is returned in the response
- Some of the stored XSS vulnerabilities – where malicious JavaScript is stored on the server and is displayed every time somebody (can be the attacker or an unsuspecting user) is requesting a specific page
- Very few DOM-based XSS vulnerabilities – where user-controllable data is used by client-side JavaScript
- Path traversal vulnerabilities – arbitrary read of the files on the vulnerable web server (/etc/passwd or win.ini are usually used for this test)
- File inclusion vulnerabilities – arbitrary file from the internet can be included in the response (i.e. random text file from attacker controllable server)
- Command injection vulnerabilities by injecting a command, which will delay the response (i.e.: ping localhost 20 times) or return specific output in the response (i.e. ipconfig)
- Hidden pages and files
- Directory listing
- Webserver vulnerabilities
- Other vulnerabilities like cleartext password submission, session tokens in URL, password field autocomplete, SSL cookie without secure flag, frameable responses, which can be determined by analyzing the requests and responses of the web application
What can go wrong?
In some cases the web application vulnerability scanners may fail to detect some of the vulnerabilities mentioned above or may not work properly. Below is a list of top reasons why automated vulnerability scanners might not work:
- Custom-built authentication mechanism – when a web application uses proprietary approaches to authenticate the users (multi-step authentication, non-standard session management, etc.), sometimes the scanner my fail to login and only scan unauthenticated parts of the web application
- Web applications with heavy use of AJAX – many of the web scanners spiders do not handle dynamic AJAX content properly
- Websites with a lot of content or a high number of dynamically generated pages – sites like Amazon, Facebook, eBay and YouTube where there are thousands of similar pages with different content, new pages are generated because of user actions (including vulnerability scanner generating new pages while doing the scan) or when each request receives a unique response URL
What are vulnerability scanners not able to do?
In addition to the limitations mentioned above, the scanners are not smart enough to test for specific vulnerabilities in the application logic. Web application vulnerability scanners are not able to test for:
- Authentication vulnerabilities such as username enumeration, resilience to password guessing, any account recovery functions, credentials predictability or any other logic flaws in the authentication
- Session management flaws like meaningful or predictable tokens, session fixation, mapping tokens to session, session hijacking, etc.
- Vulnerabilities in access controls where a user can access others’ user data or admin functionality without having admin privileges assigned
- Application logic flaws such as ordering negative number of items, skipping a stage in multistage processes (i.e. going straight to shipping page, skipping the payment page) etc.
- Shared hosting vulnerabilities – test segregation in shared infrastructure or between ASP-hosted applications
- Leakage of sensitive information such as password hashes in the hidden fields or user logs
Know your tools
To summarize, automated web application scanners are essential tools for any vulnerability assessment or penetration tests, but you should know their capabilities and limitations. However, a qualified penetration tester is still required to know how to interpret the results, perform advanced manual testing and understand the risks to the organization.
