This repository was archived by the owner on May 6, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Proxy Architecture
Bharadwaj Machiraju edited this page Aug 30, 2015
·
4 revisions
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.
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
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 anyWRITE
events. The handler function will call theproceed_with_request
method with the updated request object from the cache file. - If
False
, call theproceed_with_request
method directly with existing request object.
- If
-
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 anyWRITE
events. The handler function will call theproceed_with_response
method with the updated response object from the cache file. - If
False
, call theproceed_with_response
method directly with existing response object.
- If
-
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.
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.