Skip to content
This repository was archived by the owner on May 6, 2018. It is now read-only.

Proxy Architecture

Bharadwaj Machiraju edited this page Aug 30, 2015 · 4 revisions

Introduction

In the distributed architecture, each Manager/Grunt machine has a proxy. This proxy exposes the following functionalities on the same machine.

  • HTTP Interception

We will see how these are implemented.

HTTP Interception

This will be implemented using our current File System cache. Please bear in mind that we have multi instance proxy, so we will have multiple processes which will have few shared variables. The shared variables for this interception scope are

  • request_intercept_mode : boolean
  • response_intercept_mode : boolean
  • url_intercept_regex: regex_string
  • request_header_intercept_regex: regex_string
  • request_body_intercept_regex: regex_string
  • response_header_intercept_regex: regex_string
  • response_body_intercept_regex: regex_string
Proxy Flow

The typical flow of a request in the proxy will be as follows

  • Receive a HTTP request (apart form CONNECT)
  • Do a cache check and request should be written to cache if it is a new request.
  • Check the value of request_intercept_mode
    • If True and one of the regex matches, add an event handler to that request cache file to observe any WRITE events. The handler function will call the proceed_with_request method with the updated request object from the cache file.
    • If False, call the proceed_with_request method directly with existing request object.
  • proceed_with_request does the request to the target and gets back response object.
  • Write the response to the cache using cache handler.
  • Check the value of response_intercept_mode
    • If True and one of the regex matches, add an event handler to that response cache file to observe any WRITE events. The handler function will call the proceed_with_response method with the updated response object from the cache file.
    • If False, call the proceed_with_response method directly with existing response object.
  • proceed_with_response writes back the response to the connection.

By using the file ioloop handlers, we are not blocking any tornado process when multiple requests arrive in intercept mode.

UI Flow

The typical flow of the intercept UI will be as follows when user accesses intercept UI and enables intercept.

  • Cache file system will be checked for request and response files which don't have a complete flag associated with them. (Complete flag in owtf cache is indicated using the same file name but with .rd extension)
  • These files should be read and displayed as a list of requests and responses in intercept queue ordered according to their timestamps.
  • When user clicks submit, then apply the necessary changes if nay and write back to the file. This will trigger the event handler and the request/response is processed by the proxy.
Clone this wiki locally