Twelve Days of ZAPmas - Day 5 - Scope and Contexts

Twelve Days of ZAPmas - Day 5 - Scope and Contexts
Mic Whitehorn
Author: Mic Whitehorn
Share:

Normally I don’t like having my interception proxy hide out-of-scope traffic. Doing so creates a blind spot for third-party interactions that might be important to see. For example, if I’m feeding attack payloads into a form field, and they’re being sent to an out-of-scope service, I might accidentally attack that service, which wouldn’t be very good. Also, it might hide vulnerabilities like referer leakage.  However, once you have thoroughly mapped the app, sometimes it’s nice to create grouping for your request traffic, or to eliminate some out-of-scope traffic that you’re capturing to make it easier to look for specific requests. ZAP has two loosely-related mechanisms for dealing with this, scopes and contexts. This was a departure from Burp, which I normally use, and which has the concept of Scope but doesn’t have a good analog to ZAP’s contexts.

What’s the difference between Scope and Context?

  • A Context in ZAP consists of a grouping of paths described by one or more inclusion rules. Subpaths or individual resources can be removed from the context by adding exclusion rules. There are additional settings and metadata related to contexts, such as the technologies used, and authentication related information. These are useful groups for targeting ZAP’s automated tools, which we’ll dig into later in the series.
  • Scope is what you’re actually allowed to attack. You can use it to filter several views in ZAP, and the automated tools shouldn’t ever send attack payloads to paths outside your scope. I construct the scope by marking one or more Contexts as in-scope.

Before Beginning…

There’s a drop-down just about the Sites tab for setting ZAP’s mode. The default was Standard Mode. I actually discovered a bit later on, that Protected Mode is a better option to help keep you in-scope.

The OWASP ZAP desktop app with the Mode dropdown open, and Protected Mode highlighted.

Even resending requests and fuzzing will be prevented against out-of-scope paths when you’re in Protected Mode.

Creating a new context

I found a few ways to create a context, but my preference was just to use the New Context button at the top of the Sites pane.

ZAP Sites tab with the Add Context button highlighted.

This will open up the New Context dialog, as shown below.

ZAP's New Context Dialog and Select Node dialog open with the controls for 5 steps highlighted. 1. the Context Name textbox in the New Context dialog. 2. The select button for the Top Node field in the New Context dialog. 3. A specific node in the tree of the Select Node dialog. 4. The select button in the Select Node dialog. 5. The Save button in the New Context dialog.

  1. Add a nice descriptive name
  2. Use the select button next to the Top Node box to open the node tree.
  3. Find the root of the app you want to include.
  4. Click Select to confirm your node selection.
  5. Use the Save button on the New Context dialog to create your context.

You might also notice the In Scope checkbox was checked on my New Context dialog. The Wayfarer App entry now appears under the Contexts section at the top of the Sites tree as pictured.

The Sites tab with the Wayfarer App context highlighted.

Marking Contexts as In-Scope or not In-Scope.

The red circle in the middle of the Wayfarer App context’s icon indicates that it’s in scope. Your default context might also be in-scope by default. Marking it out-of-scope is as simple as right-clicking on it in the Sites pane and selecting Remove From Scope.

The ZAP context-menu with the Remove from Scope option highlighted.

For a context that is already out-of-scope, the same right-click menu will have an Add to Scope option.

Modifying the Context

Adding an Additional Host

Using the right-click context menu, I can add items to the context from the History pane or the Sites tree view on the left side of ZAP’s main window. For example, I added wayfarer.test:3000, which is the single-page app, but it uses an API on port 3001. If I locate the wayfarer.test:3001 entry in the Sites menu, I can add it to my Wayfarer App context, as pictured.

ZAP's sites list with the wayfarer.test:3001 entry highlighted and the context-menu open. The Include in Context submenu is open, with the Wayfarer App option highlighted.

This will open the Session Properties dialog, with the Wayfarer App context selected, and populate the new entry under the Regex list for the host I added. I don’t really need to do anything at this time, so I can just click OK when I’m done.

The Session Properties dialog with the Include in Context panel open. The entry created for wayfarer.test:3001 is highlighted.

You might have noticed that the Include in Context submenu and had a New Context option as well. I could have created my context from there in the first place, but I haven’t found a way to give it a descriptive name if it’s created that way. (Update: In Simon's feedback post, he pointed to where the renaming box is in the contexts top node of the  session properties).

Excluding items from the context

Now, let’s imagine there’s a particular subtree or a specific path of the API that I’m treating as out-of-scope. I can use my right-click context menu once again, but this time to select an item to remove from the context. Again, this is available on both the Sites pane and the History pane. I’m going to use the History pane for this example, selecting the entry for wayfarer.test:3001/auth/refresh. 

A highlighted path in ZAP's History pane, with the context menu open to the Exclude from Context submenu, with the Wayfarer App item highlighted.

This again opens the Session Properties, this time showing the Exclude from Context options with an entry prepopulated for the path I’d selected. If I wanted a whole subtree, I would want to see the regex ending with a regex wildcard (.*).

ZAP's session properties dialog with the Exclude from Context panel open, highlighting the name the panel.

Again, ZAP has already added the entry to the list, so I can just use the Save button to close the dialog. If I open up the tree for the wayfarer.test:3001 host on the Sites pane, I’ll see that the In-Scope target icon is not present on the GET:refresh resource.

ZAP's Sites pane with the Wayfarer.test:3001 subtree open. The highlighted icon under auth/GET is missing the in scope (target) symbol the other nodes have.

Filtering Views based on Scope

Several panes in ZAP have a target button that can be toggled on and off. When on, it limits the view to only in-scope items. In the picture below, I’ve enabled it for the History pane.

ZAP's History Pane with the In-Scope (target) filter button highlighted.

In Summary…

It makes sense to construct at least one context and include it in the scope even if you’re exclusively doing manual testing. When we look at the automated tooling in ZAP, scope and context will be essential to targeting those tools correctly.

Check out Day 6 for leveraging ZAP’s passive analysis to see flaws it has been detecting all along.

Join the professionally evil newsletter