Validating vulnerabilities found in WebInspect

Today I would like to cover how to use WebInspect to validate its findings rather than just reading the remediation details. This is a common stumbling block for users who are new to web application security testing and not simply this HP product. While the tools discussed here are all included with the WebInspect product, the included user documentation is unfortunately aimed at how the features work or which buttons are available and used for and not truly focused on how to use this sort of tool for penetration testing. I guess that's why they call it a product guide and not a job training guide. ;-)


Data At-Hand

WebInspect offers a lot of details right there in the Session Info panes. Raw HTTP Request, HTTP Response, parent and child Links, general Details, et al. The HTTP Request will include a request header called "Memo" by default, unless you disabled that under the General scan settings, and this Memo header lists in HP developer short-hand a description as to what generated this individual request. There is even a way to change a configuration file and expand the Details pane before or after a scan to expose a lot more data regarding this single session. The Request and Response data will frequently have the significant items (attack) colorized with red high-lighting and this will carry over into the vulnerability reports, although this feature is only available on an individual security-check-by-check basis, at the time they were being defined by HP's researchers.


Right-click Menu

To make the review and editing of scan results simpler, WebInspect offers a right-click menu both within the Vulnerabilities pane (bottom of screen) and in the Site Tree pane (left of screen). This menu is nearly identical in both panes except that the one available within the Site Tree starts with four options for managing the branches of the tree, a tree export function, and an option to generate a small Single Session report for this one single page/session.

The right-click menu offers the following general capabilities.

* load original HTTP Request into browser ready for replay.

* edit the vulnerability description, its severity, or add additional findings (factory-provided or customized ones).

* mark the finding as a False Positive or even remove the finding completely. The FP items will then be charted on the Dashboard, and shifted from the Vulnerabilities pane to a new False Positives panel, and will be suppressed from all reports except the False Positives report, naturally.

* add a comment to the Vulnerability or the Session (page), which can be included as part of the Vulnerability Summary report later. Such annotations can be located from the overall Notes panel in WebInspect if one loses track of them.

* load the original HTTP Request into some side tools for replay, e.g. HTTP Editor or SQL Injector.

* Send the finding and all remediation details into your available defect tracking system, if it happens to be HP Quality Center or IBM ClearQuest. This will add a vulnerability note with the resultant defect number and such details to the WebInspect session thus affected. Nice way to close the "air gap" between the security tester and the developers who need the data to fix the issue. Who needs PDFs?


HTTP Editor

This side tool is a raw request editor allowing you to perform hands-on hacking, very similar to using common freeware intercept proxies or the Tamper plug-in for your browser. Send the Request and see the Response in real-time, including Raw, Browser, and Hex views of the results. There is a Show History button so you can compare or review the requests you have been making, and the data can be saved in order to share with another user who also has access to a copy of the HTTP Editor.

This tool can also be used as a step-mode browser, so if session state is fouled up and the single replay is not initially working as expected, you can use the Response's Browser window to log into the application and then go deliver the payload desired. This process is done (slowly) by filling out the login fields shown in the Browser view, notice that the Request gets altered, click the "Send" button, see the Browser view response, click a button or link there to modify the Request accordingly, click "Send", and keep repeating that use of the Send button to walk through the site. Once session state is established, you can jump directly to the page by modifying the URL field and Request as needed.


Intelligent Engines - XSS and SQLi

These patented engines from SPI Dynamics/HP circa 2007 actually send an entire series of appropriately-encoded probing requests against the page/form and review the responses to ensure that the attack was not sanitized but is indeed vulnerable. The trouble for the user is that the WebInspect UI or its scan database can only seem to show/store one single Request/Response pair, and that is typically the final one made. So the user may be looking at something relatively basic like a single-tick OR probe ("'%20OR") with a 200OK or 500 error and then wondering how HP's tool figured that this means there is "Confirmed Blind SQL Injection", when truthfully this Request/Response pair was the last of a series of perhaps up to 20+ probes.

Verifying the XSS findings is usually straight-forward. Load the HTTP Request into your browser or HTTP Editor and replay the attack, reviewing the response closely. The Web Browser View pane within WebInspect's UI can also be used for many of these instances, as it has Active Content enabled in the application settings by default. Some of these probes are simple alert pop-ups, others require User Interaction (e.g. onmouseover), and others will require that you understand Javascript and can "just see" with your developer's eye that the Response is unsafe. If you want to see the XSS engine in full action, you will need to repeat the assessment using the same scan settings but focused just on the page of interest, running the scanner through an intercept proxy such as the included Web Proxy tool.

Verifying SQL Injection is a similar process of replay, with different tools. Bear in mind that HP will identify four primary types of SQLi in two classes: Possible SQLi, Possible Blind SQLi, Confirmed SQLi, and Confirmed Blind SQLi. The two "Possibles" indicate that WebInspect did not get into the database, but saw varying results to its True/False probes. These "Possible" findings generally boil down to input validation issues, such as "Why did the Zip Code field permit script characters and 67 characters of input?" ;-) The "Confirmed" findings indicate that WebInspect went beyond the initial True/False probes and actually got valid SQL server responses to direct SELECT statements. These "Confirmed" items are ripe for a probe with the SQL Injector tool.

And yes, the SQL Injection engine works on more than just MS SQL, specifically MS SQL, MySQL, Oracle, Postgres, DB2, and (sometimes) MS Access.


SQL Injector

Assuming you have a "Confirmed" SQLi finding, I would load the vulnerable session/request into the SQL Injector via the aforementioned right-click menu, as this automatically carries over any Authentication settings you may have had in the original assessment. You could also do all of this set-up the hard way, by manually launching the tool separately from the Tools menu or Windows Start menu and then building out the necessary settings and session state. Once the vulnerable request is loaded in the Injector, simply click the tool's "Send" button and wait for the status on the lower-right section of the Injector's screen. If the tool says injection is possible you may now proceed to dumping the entire database or select quantities of Tables/Columns/Rows using the buttons at the top toolbar of the screen. The stolen data can be saved as a *.SDF (SQL Database File), and that data can be managed or queried using SQL Studio Express for real shock-and-awe at your presentation later.

Sometimes the SQL Injector tool will state some other status message, such as "Data Extraction Not Possible". This does not mean "not vulnerable to SQLi", it simply means that some complication (permitted queries, clustered databases, MS Access in use, et al) is preventing the use of SELECT queries to steal the data. Both WebInspect and the SQL Injector only make use of the SELECT query method, as this is the safest in most conditions. It is quite possible that the injection point will permit you to exploit other methods such as DROP, UNION, et al, all of which will require a bit of coordination with the DBA before you start those types of actions with other tools.

If you want to see what the SQL Injector does, or you want to capture the data so HP's ASC Customer Support can take it to the developers for review, you can capture it in an intercept proxy. First, modify the SQL Injector's settings to use an intercept proxy such as the included Web Proxy tool (default = 127.0.0.1:8080), prepare your proxy, run the SQL Injector attacks through the proxy, save the sessions captured in the proxy, and also save the SQL Injector data (*.SDF) to accompany it.


Repeat Scans

Sometimes you need to reassess the site, or just the portion of it that the developer corrected. This can benefit from the use of a saved scan settings file. If you did not save the settings during the original Scan Wizard, you can still acquire the settings file from your completed scan by opening it on screen and clicking on the Edit menu > Current Scan Settings > Save As. Once saved you can further modify these settings from the Manage Settings item found under the same Edit menu. Repeating a scan then only requires selecting this saved XML file from the available choices shown on the Settings button pick-list at the bottom-left of the Scan Wizard screens. I would select the desired settings file on the first screen, as it will reset everything else and you will need to refill the necessary fields.

If you do not want to scan the whole site just to validate a small portion, there are the following features available, based on your need, and assuming that you are using the saved scan settings.

* Audit-Only scan method - no Crawl or Discovery of the rest of the site!

* Deep-linked (long) Starting URL coupled with one of the Restrict To Folder options and using the Audit-Only scan method.

* List Driven Assessment - use a simple input file, or harvested folder listing from the web server. When used with the Audit-Only, only those pages will be scanned.

* Workflow Driven Assessment - Similar to the List Driven, except it uses a prerecorded Start Macro of the desired pages or business process.

* Session Exclusions - Omit all URI's containing a keyword or partial folder path.



.