Without any data, in the Attack Surface interface, there isn't much to discuss, so let's work on that first. It must be made clear that Attack Surface is not designed to analyze the data in a session followoing an attack. An attack will cause thousands of hits to the web server. Attack Surface pulls all the request/response data from the current session into memory for processing. You would almost certainly run out of memory if you used Attack Surface following an attack. Attack Surface is designed to be used once you have followed all the navigation paths in your app. Note, any path you don't walk through, Attack Surface won't know about. You can use the spider function to speed up this process, but you will likely still need to fill in forms manually.
For demonstration purposes, we'll use the deliberately vulnerable OWASP WebGoat application. First you must ensure Burp is set up to proxy. Note, WebGoat runs on port 8080 by default and Burp and ZAP both listen on port 8080 by default, which can be problematic. Hence, it is recommended that you choose a different port to run your proxy. Assuming your Burp or ZAP instance is proxying properly, you can now navigate to the front door of WebGoat at http://localhost:8080/WebGoat. Note, you will not see any new data in Attack Surface until you click the Refresh button at the bottom right corner of the GUI:
After we click the refresh button, we'll see something like this in the Worksheet tab:
These are the domains that were accessed during the current session. These domains are in a tree within the Worksheet tab. By drilling down into the tree, you can see the hierarchy of untrusted data (i.e. Domains, paths, parameters, cookies, and headers). The Worksheet tab is where you record the results of your process of confirming or eliminating all untrusted data as vulnerable or secure. Let's drill down a little:
We can ignore the detectportal.firefox.com domain. This must be an artifact from the FireFox browser, but it is irrelevant as we are not trying to protect detectportal.firefox.com. In the drill-down image above, we can see all the domain, paths, and headers that were involved in loading the WebGoat front door page. You will notice there is a red square in each node. This means each node is currently considered vulnerable. This is the default state of each node. However, once you have eliminated a node as being vulnerable, you can add a rule to indicate it is not vulnerable. A node can have one of three states:
The objective of the Worksheet tab is to add enough rules such that the entire of hierarchy of the domain you wish to protect is in Green state.
Let's now add a rule to demonstrate. Let's assume that we have assessed the User-Agent header and concluded it is not vulnerable. To create a rule, right-click on the User-Agent node to be presented with a pop-up menu that has a Create Elimination Rule... menu item:
Click on the menu item to see the following dialog:
We have the following fields:
You can change the values in these fields, but generally you will want to leave the pre-populated values. Assuming, we have determined that the User-Agent header is secure for all paths, we can click the All radio button for the Apply to Paths field. Let's also add some text to the Explanation field which justifies adding the User-Agent rule and then click Okay. Here is the result:
The circles above should draw your attention to:
Let's now select the /WebGoat path and create an elimination rule for it. Here is editor dialog:
Once we click Okay, we'll have the following:
Note, that the /WebGoat path is now orange. This happens because this node had been deemed secure, but there are still potentially vulnerable nodes underneath it. In order for it to be green, elimination rules must be created to make all of its descendant nodes green. Once the http://localhost node is green, you have secured your entire web site.
Let's now take a look at Worksheet tab's content pane. As you drill down into the tree in the left-hand pane, the content pane on the right will update accordingly. If the Merge All Requests field is selected, the Requests / Responses table will be populated with all the untrusted data found in the selected node in the navigation pane and all of its descendant nodes. If the Merge All Requests field is not selected, the Request field becomes enabled. You can then use this field to select any request corresponding to the selected node in the navigation pane or any of its descendants. The columns in the Requests / Responses table should be mostly self-explanatory, except perhaps the Order field. This field can be considered the unique identifier of a given request, but also represents the order of which the requests were made.
Next, let's examine what happens when you select a row in the table. Just below the Requests / Responses table is an area that displays request information and below that is a third area to display response information. Here is what you might see when you click on a row in the Requests / Responses table:
The Request Data and Response Data tables are immediately populated with the untrusted data associate withe request and its corresponding response. You can see the Type, Name, and Value of piece of untrusted data. To the right of each of these tables is a space to display Request Body information and Response Body information. The Request Body area will only be populated when a row in the Requests / Responses table is selected that has a Request Body size greater than 0. For HTML traffic, this happens with file uploads most of the time. The Response Body area will only be populated when a row in the Requests / Responses table is selected that has a Response Body size greater than 0. In the Requests / Responses table above, there are no entries with a Request Size greater than 0, but the third row has a non-zero response size. If you click that row, you will see the following:
This response type is text/html, so it will display a Rendered tab, which will attempt to render the HTML and will also display a Raw tab, which shows you the raw HTML:
Most HTML requests do not have a body, but file uploads are probably the most common exception. To see what that might look like, we'll skip over to gofile.io to upload a file. We'll upload a jar from the Apache Commons Collections project so we can see what Attack Surface can do with a zip upload:
In this screen shot, you'll see in the Requests / Responses table that the selected Request Content Type value is multipart/form-data and the Request Size is 588736. Also, in the Request Body area, the table on top has the row selected with Content Type application/octect-stream. Lastly, in the table on the bottom, you will see all the files contained in the jar.
The last area to explore in the Worksheet tab is the top row of buttons in the bottom right-hand corner. We have the following buttons:
The first four buttons are mostly self-explanatory, but the Export functionality can be explained in more detail. The export functionality could be used with any number of tools, but is intended to work with another Discotek.ca product called Deep Dive. Deep Dive is a static code analyzer that can look for vulnerabilities in most JVM-targeted deployment units (ear, war, jar and also apk). By exporting the untrusted data names to Deep Dive, you can search for all references to untrusted data within the deployment unit for the web site you are assessing (of course, this is considered "white box testing", where you have access to the source code, deployment unit(s) etc.).
Assuming you just logged into the front door page of WebGoat (which has form data, headers, and cookies) and clicked the Export... button, you would see a dialog similar to the following:
The dialog above contains a table of Domains and this one contains only one entry for localhost. You must select the domains for which you want to export the untrusted data. By default, all domains are selected, but most likely, you will want to select only a portion of the domains. There is also a Network Host and a Port fields. These fields allow you to connect to the export client. Deep Dive's default listen port matches Attack Surface's default export port, which is 5678. You will likely not need to edit the Network Host field unless you wish to export to a separate machine on the network.
Once you have edited the Domain table and the other fields appropriately, click the Okay button. If you don't have Deep Dive already running and configured to receive the export data, you will see the following dialog:
Attack Surface bundles the Deep Dive software, so it can be launched from Attack Surface. If you click Yes in the above dialog, Deep Dive will be launched so it can import the untrusted data. In Deep Dive, you will be asked to create a new project:
If you click Okay on this dialog, the Deep Dive analyzer configuration editor will be displayed, which should show the following:
Now click the Okay button on the analyzer configuration editor. The next step requires access to the webgoat deployment unit, webgoat-container-7.1.war. Drag this file to the left pane of the Deep Dive interface. Then in the File menu, click the Generate Report menu item. A dialog similar to the following will be displayed:
This dialog gives you the option of tailoring the default analyzer configuration. Each analyzer is designed to hunt for a different pattern in the deployment unit(s). The analyzers in this screen shot are the built-in System analyzers. We are not interested in these analyzers, so let's uncheck the box next the System node and collapse it to get the following:
Next, click Okay and wait for the report to be generated. Depending on how many uniquely named parameters, headers, and cookies have been discovered by Attack Surface, this searching can take a long time. You should note that by default, Attack Surface configures Deep Dive to only search in .xml, .class, and .properties files. To look in other files, you would have to manually edit each analyzer configuration. Once Deep Dive has finished processing the deployment unit, you will get a result similiar to the following:
There is too much output to show you the entire Deep Dive report, but you should be able to now see how you can easily comb through a deployment unit(s) to determine whether untrusted data is vulnerable using DeepDive.
Also, if you are new to Deep Dive, you should know that if you configure your operating system such that .class files are associated with a decompiler and .ear, .war, and .jar files are associated with a decompressor (like WinZip or WinRar), you can click the hyperlinked text in the Deep Dive output to investigate potential issues without requiring access to the source code.
Let's now take a look at the Potential XSS tab. The intention of this tab is to highlight where you might have a Cross-Site Scripting (XSS) attack. It does so by searching for all untrusted data (parameter, cookie, header values from all requests) in the bodies of all responses. You will likely find many more false positives than real positives using this functionality. However, it provides a systematic approach to eliminating XSS and provides all the relevant data all in a single view. You should note that in all Attack Surface tables that display request / response data, there is a right-click popup menu, which allows you to send the selected request / response to the repeater functionality within Burp or ZAP ("Resend...").
Here is a screen shot of the GUI without any data:
In the left-hand pane, there is a tree, which organizes all untrusted data by:
Any value that appears as untrusted data in any request, but also appears in the body of a response will appear under one of thes nodes, according to its data type. On the right-hand side, at the top, there is a table for Requests. This table will be populated is populated when a value is selected in the left-hand pane. It will contain all the requests that contain the selected value and type. Just below, this table, is the Responses table. This table contains all responses that have a response body that contains the value selected in the left-hand pane. When you select a row in this table, the bottom table, Response Body Content, will be populated with data, depending on the type. A response of content type text/html will cause this pane to be populated with two tabs: one to render the HTML and a second to display the raw HTML.
Let's now take a look at an example in WebGoat. WebGoat has a section to teach the basics of Cross Site Scripting (XSS):
Let's see how effective Attack Surface is at identifying potential XSS using an app with known XSS vulnerabilities. First, click the Phishing with XSS link (highlighted below) in the navigation menu to see the following page:
This page allows to submit data in a form and which will be reflected back into a subsequent response. Let's enter something unique like ILoveAttackSurfacePlugin and see what happens.
Here we see that the text we entered is displayed in the response page. WebGoat is designed to be vulnerable and if you enter a typical basic XSS test value such as <script>alert('Hi!')</script>, the resulting page will pop up a dialog displaying the text "Hi!", which is considered confirmation of a vulnerability.
Let's now see what Attack Surface observed. By default, the Potential XSS tab does not refresh unless you explicitly click the Refresh button on the Potential XSS tab. This functionality can be very resource intensive if there are many request / response objects to process. We first have to click the Refresh button in the bottom, right-hand corner of the window, then click the Refresh button above it to process the data. You won't see any results until you manually expand the Url Parameter Values, Form Parameter Values, etc nodes. Here is what you may see:
Let's now select the ILoveAttackSurface value under Form Parameter Values to get the following:
We can see here there are two opportunities to exploit XSS vulnerabilities and we can see the raw HTML in the Raw tab:
If we hadn't already known about the search vulnerability, we would now know where to start looking. But did Attack Surface find anything else? Let's now click the first value under URL Parameter Values:
If we look in the Raw output of the request selected in the Responses table, we see that it makes up part of the path for a form's action (and I won't bother providing screen shots, but the same thing can be said of the "900" URL Parameter Value too). While this isn't part of WebGoat's XSS demonstration, let's see if we can exploit it anyway. Select one the rows in the Requests table and right-click to get the following pop-up menu:
Next, click the Replay... menu item to resend the request. In Burp, you must next click the Repeater tab, to see the following:
If we now google for web sites that do URL encoding, we can convert this:
We can then copy the encoded value and paste it in the potentially vulnerable parameters in the Repeater tab:
Once we click go, we can see the response:
Fortunately, our attack script does not show up in the response body and indicates that these parameters are not vulnerable to XSS.