Before the release of an extension or a different kind of functionality in ZAP, it is important to make sure everything works as expected. Code that is committed to the ZAP repository is naturally tested by the core team, however these tests can be
3.7 Test Strategy 41
Must have Nice to have Create, modify, persist sequences as Zest scripts •
Active scan sequences •
Mark alerts as scanned with sequence •
Sequence functionality included in API •
Sequence mechanism available as one .zap file •
Code well documented •
Code follow same style as the rest of ZAP • Code not dependent on non-core extensions •
Avoid unnecessary use of resources •
Verify functionality with tests •
GUI texts internationalized •
Ease of use •
Table 3.12: An overview over which requirements are Must have, and which are Nice to have.
superficial, and should ideally only be for verifying and making sure that code struc-ture is as it should be. Therefore it is important to make sure that the implemented code is sufficiently tested before actually committing it.
The ZAP workspace provides an additional project which is only intended for unit-testing. Ideally this extension should likewise have targeted unit-test, however since the developed functionality is comprehensive and is dependent on several external factors, it might not be possible to create satisfactory unit-tests. Alternatively effort should be put into creating test-cases that proves that scripted sequences support ZAP functionality. The following features should be functional and tested before an actual release:
• Session handling
• Anti-CSRF tokens
• Authentication
Furthermore it should be tested that it is possible to locate unique vulnerabilities using sequence scripts. The problem was initially that it would not be possible to find persistent XSS in cases where data would require several steps in order for it to be persisted. This behaviour was observed on the WackoPicko test site, which would therefore be ideal for testing a sequence solution.
CHAPTER 4
Design
This chapter serves to explain some of the choices for the design of the sequence mechanism for ZAP. The chapter begins with an explanation on how to extend func-tionality in ZAP, followed by a section on hooking into specific funcfunc-tionality. The following sections will explain how to handle sequences, and how to define a useful user interface for custom functionality in ZAP, thereby creating a good user experience.
4.1 Extending ZAP
Adding new functionality to ZAP can be done by creating a class which extends ExtensionAdaptor, which is a class that originates from the Paros Proxy part of the codebase. By overriding thehook method and using the ExtensionHook pa-rameter which the method provides, an extension class can gain access to different parts of the ZAP functionality. This means that an extension can use data and func-tionality that is stored elsewhere in ZAP, and create GUI elements in places that would normally require an update to the core of ZAP.
Newly created extensions will usually be placed in the Alpha development branch.
It is possible for new extensions to reference other extensions, in order to use any functionality they provide. However, this creates dependencies for the newly created extension. Guidelines from the ZAP development team suggest that it is not a prob-lem to reference extensions that are part of the core of ZAP. However, if a reference is created to an extension that is not part of the core, problems might occur if both extensions are not in the same package or development branch.
The sequence mechanism should ideally be created as a self-contained extension, using only functionality available from the ExtensionHook class, and from core-extensions. However since this sequence extension will interact with the Zest exten-sion (which is currently in the Beta branch), the extenexten-sion may need to be placed in the Beta branch.
Along with the ExtensionHook class, ZAP also provides a few interfaces for classes to implement, to react to certain events in ZAP. One of these is the Scan-nerListener interface. This interface provides methods that will be invoked by the scanner when different events occur. Classes that want to react to these events, can register themselves with the Scanner class, and when an event happens, all the
classes that implementScannerListener will have the corresponding method run.
An example is thescannerComplete method. When an active scan is completely finished, the scanner iterates through all the classes that have registered as a Scan-nerListener, and runs the scannerComplete method. This is useful, if classes want to update GUI elements, or otherwise use the complete results from the active scan.
The sequence extension will handle all interactions regarding sequences, while performing an active scan. The actual sending of HTTP requests during an active scan, is handled in the plugin classes, that define an active scan rule. Not all scan rules send requests, as some scan rules simply aim to find specific patterns or tokens in the response of a message. Accordingly, the handling of sequences should only be relevant, for plugins that send requests to a server. TheAbstractPluginclass, that all plugins extend from, has a method,sendAndReceivewhich sends a request and populates the response object of aHttpMessagewith the result. Plugins will usually modify the original request in some way, before passing it to thesendAndReceive method, and inspecting the response afterwards. In order to handle sequenes, the message needs to be intercepted before it is sent.