Most false positives I encountered are caused by URL rewriting. WebInspect looks for directories that are not referenced by the web site, usually because they are supposed to be hidden (e.g.,/admin,/test). But if you use URL rewriting to map, for example,http:// mydomain.net/forums/ to the folder/groups, WebInspect reports /groupsas a hidden folder event, although it has exactly the same content as the virtual folder/forums. WebInspect may also report a lot of malicious finds from a directory that uses URL rewriting. It is common to rewrite URLs that have a lot of variables into a user-friendly URL that uses a directory structure—for example, http:// www.domain.com/product.asp?category=clothes&brand=mybrand&id=1 turns into
http://www.domain.com/products/clothes/mybrand/1. WebInspect thinks /products/ clothers/mybrand/clothes is a folder and 1 is a filename. So it looks for /products/
doesn’tt return a 404 File Not Found because the actual file is alwaysproduct.asp,
admin.exe, ordebug.pl, which are only parameters of a URL for the server. Web- Inspect doesn’t check the content of the file return (since it could change) and relies on the web server response code. But you can work around this type of issue. If the scriptproduct.aspis well designed, it should return an error when the ID is malformed (not a number) or doesn’t exist. You can add this error message to the list of custom 404 in the WebInspect settings; see “Settings Tuning,” earlier. Another set of false positives is due to the fact that tests are not correlated with the web server version shown in the HTTP reply. For example, the availability of/iconstells an attacker that you are very likely running Apache, and if its content is browsable, the version of Apache could be figured out. But this does not matter at all, as the server name and version are part of the HTTP reply. However, this information could be faked. There is a tradeoff between false positives and false negatives. WebInspect seems to have chosen to give more information to avoid false negatives; this is always a good choice for a security tool, even if it means more work to analyze the results. Whenever you find a false positive, you can mark it as such by right-clicking on the vulnerability in the left pane and choosing Annotate➝Mark As False Positive. You can also edit the vulnerability information to change its severity and probability. Under Session Info, there are also a number of very useful features to analyze each vulnerability. The most used are probably the HTTP Request and Reply that shows Figure 3-8. WebInspect scan result details
the request from WebInspect, and the reply from the server. This is usually enough to determine whether this is a legitimate hit or a false positive.
The Web Browser feature under Host Info opens the page requested by WebInspect in a real web browser. If WebInspect did a successful cross-site scripting, you can actually see the JavaScript being executed.
WebInspect Tools
Once the audit of a web site is finished, you can use tools embedded in WebInspect to go deeper in a vulnerability analysis or even to exploit a vulnerability found. They are available under Tools. Here are a few of them:
HTTP Editor
You can tune any request done by WebInspect. If you think WebInspect pointed out something interesting but did not do enough, you can tweak the request to add a custom header, a cookie, modify a variable, and replay it, as shown in Figure 3-9. It includes a hexadecimal editor if you need to add non-ASCII char- acters. There are a lot of encoding mechanisms (Base64, encryption, hash) acces- sible by right-clicking on the text you want to encode.
SPI Proxy
WebInspect has integrated an advanced web proxy. In the Search view, you can search on the requests and the replies. It is interesting to see all the replies from a particular script to understand how it behaved against bad attacks.
You must start the proxy before you start the scan. Then, in the last screen of the scan wizard, choose “Specific proxy server” and type127.0.0.1for the address and8080 for the port. Figure 3-10 shows that all traffic is recorded, just like a regular proxy.
SQL Injector
This tool can be used to both confirm and exploit an SQL injection vulnerability. If you find a confirmed or possible SQL injection vulnerability in the report, copy the URL into the SQL Injector tool. WebInspect uses different tests to determine the database version. Unlike some simpler injection tools, it does not rely on a generic database error message because it could be masked by the server. This tool works with Oracle, DB2, MySQL, and SQL Server. If the database detection is successful, it can grab the database structure and the content of each table. WebInspect can be turned from an audit tool into an exploitation tool.
SPI Fuzzer
WebInspect includes an easy-to-use HTTP fuzzer (see Chapter 22). To start from an existing request, select Session➝Raw Create, and paste the data copied from an HTTP Request. Then highlight the part you want to fuzz and right-click to choose Generator. There are a number of predefined generators—for example, a number generator. Click on Configure to select the minimum (e.g., 0), maxi- mum (e.g.,100), and increment (e.g.,1). You get a request that looks like this:
GET /product.asp?id=[IntGenerator-0] HTTP/1.0 Connection: Close
Host: domain.net
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0) Pragma: no-cache
Content-Type: text/plain
Given our example configuration, WebInspect generates 101 requests fromid=0
to id=100 and displays the 101 replies. If you know what you are looking for (e.g., a specific error message, a 404), you can add a filter to keep the interesting replies only.
All these tools are very powerful and can be used independently of the regular crawl and audit. I personally use them for further analysis of potential vulnerabilities found during the audit.