Skip to content

Unorganized Notes

Jump to bottom
David Scrobonia edited this page Sep 15, 2017 · 2 revisions

Contents

  1. The Break Problem

Using ZAP Break in the HUD

What is the HUD?

The HUD is a new way of using ZAP that runs as javascript injected into web pages being proxied by ZAP. The injected javascript builds a client side interface that overlays on top of the proxied web page, which we call the HUD. The HUD is built from iframes, web workers, service workers, postMessages, and ZAP API calls.

The HUD displays various buttons that correspond to different features of ZAP - like adding a page to the scope, spidering, active scan, etc... The HUD sends API requests from the browser to ZAP to interact with these features.

Integration with Break

One of the buttons on the HUD uses the break feature of ZAP. This is how (I think) it works:

  1. The user presses the break button.
  2. An iframe (the display frame) expands to fill the screen and show a dialog message that asks if you'd like to start breaking
  3. Selecting yes will send an API request to ZAP to turn on break and shrinking the display frame. The user loads a new page, perhaps by clicking a link.
  4. ZAP intercepts this request. A web worker (already running) has been polling the ZAP API, and receives a response indicating break has intercepted an http message.
  5. The web worker passes the contents of the http message to a service worker via postMessage.
  6. The service worker (hosting all of the scripts that define the different feature interactions) receives the message and passes it to the display frame.
  7. The display frame shows the message asking if the user would like to step or continue.
  8. Selecting step will send an API request to ZAP to step (sending the intercepted request) and close the display frame.
  9. ZAP will then release the intercepted request.
  10. Eventually ZAP will receive the server's response and intercept it.
  11. The web worker (still alive and polling) will receive a response indicating break has intercepted an http message.
  12. The web worker passes the contents of the http message to a service worker via postMessage.
  13. The service worker (hosting all of the scripts that define the different feature interactions) receives the message and passes it to the display frame.
  14. The display frame shows the message asking if the user would like to step or continue.
  15. Selecting step will send an API request to ZAP to step (sending the intercepted response) and close the display frame.
  16. At this point the browser will receive the respone and begin to tear down the old page.
  17. This will kill the web worker. Polling (and our only communication with) ZAP will stop.
  18. As the new web page is parsed, the browser will find external resources that need to be loaded: images, scripts, iframe html, stylesheets, etc...
  19. The browser asynchonously requests these resources, with NO GUARANTEE on order of requests (though resources earlier in the document tend to get requested earlier)

If the HUD is not cached:

  1. The first resource on the target page that is requested will be intercepted by ZAP, and thus halting any of the following requests queued up in ZAP to be processed, including the HUD.
  2. Which means there is no HUD UI to interact with to release the intercepted message
  3. The HUD will not be displayed until the continue button on the Desktop ZAP is bressed.

OR

  1. The browser can also only request a limited number of resources at the same time, which means if it is attempting to load 12 other resources before trying to load the HUD, and all of those resources are caught at ZAP, then the HUD won't even be requested by the browser.

If the HUD is cached: It loads completely fine regardless of any other resources being loaded by the web page.

Possible solutions:

I've done a lot of brainstorming around trying to force the browser to load the HUD resources before the other resources are requested, but its really hard to try to trick the browser into GUARANTEEING anything from a naturally asynchronous process

The best solution in my mind is to have ZAP identify when a response is going to be sent while breaking, and then force a browser pre-cache of the HUD, which will fix the problem.

Clone this wiki locally