From d33d3663ecb166461d9cb5a78a29b44ee7a8fbb7 Mon Sep 17 00:00:00 2001 From: Maximilian Hils Date: Thu, 18 Feb 2016 13:03:40 +0100 Subject: combine projects --- pathod/templates/docs_pathoc.html | 211 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 211 insertions(+) create mode 100644 pathod/templates/docs_pathoc.html (limited to 'pathod/templates/docs_pathoc.html') diff --git a/pathod/templates/docs_pathoc.html b/pathod/templates/docs_pathoc.html new file mode 100644 index 00000000..d38c3a77 --- /dev/null +++ b/pathod/templates/docs_pathoc.html @@ -0,0 +1,211 @@ +{% extends "docframe.html" %} {% block body %} +
+

+ pathoc + A perverse HTTP client. +

+
+ +

+ Pathoc is a perverse HTTP daemon designed to let you craft almost any conceivable + HTTP request, including ones that creatively violate the standards. HTTP requests + are specified using a + small, terse language, which pathod shares with + its server-side twin pathod. To view pathoc's complete + range of options, use the command-line help: +

+ +
pathoc --help
+ +
+
+

Getting Started

+
+ +

The basic pattern for pathoc commands is as follows:

+ + 
pathoc hostname request [request ...]
+ +

+ That is, we specify the hostname to connect to, followed by one or more requests. + Lets start with a simple example: +

+ + 
+        > pathoc google.com get:/ << 301 Moved Permanently: 219 bytes
+
+ +

+ Here, we make a GET request to the path / on port 80 of google.com. Pathoc's output + tells us that the server responded with a 301. We can tell pathoc to connect + using SSL, in which case the default port is changed to 443 (you can over-ride + the default port with the -p command-line option): +

+ + 
+        > pathoc -s google.com get:/ << 301 Moved Permanently: 219 bytes
+
+
+ + +
+
+

Multiple Requests

+
+ +

+ There are two ways to tell pathoc to issue multiple requests. The first is to specify + them on the command-line, like so: +

+ + 
+        > pathoc google.com get:/ get:/ << 301 Moved Permanently: 219 bytes <<
+        301 Moved Permanently: 219 bytes
+
+ +

+ In this case, pathoc issues the specified requests over the same TCP connection - + so in the above example only one connection is made to google.com +

+ +

The other way to issue multiple requets is to use the -n flag:

+ + 
+        > pathoc -n 2 google.com get:/ << 301 Moved Permanently: 219 bytes << 301
+        Moved Permanently: 219 bytes
+
+ +

+ The output is identical, but two separate TCP connections are made to the upstream + server. These two specification styles can be combined: +

+ + 
+        > pathoc -n 2 google.com get:/ get:/ << 301 Moved Permanently: 219 bytes <<
+        301 Moved Permanently: 219 bytes << 301 Moved Permanently: 219 bytes <<
+        301 Moved Permanently: 219 bytes
+
+ +

Here, two distinct TCP connections are made, with two requests issued over each.

+
+ + +
+
+

Basic Fuzzing

+
+ +

+ The combination of pathoc's powerful request specification language and a few of + its command-line options makes for quite a powerful basic fuzzer. Here's + an example: +

+ + 
+        > pathoc -e -I 200 -t 2 -n 1000 localhost get:/:b@10:ir,@1
+
+ +

+ The request specified here is a valid GET with a body consisting of 10 random bytes, + but with 1 random byte inserted in a random place. This could be in the headers, + in the initial request line, or in the body itself. There are a few things + to note here: +

+ + +
+ + +
+
+

Interacting with Proxies

+
+ +

+ Pathoc has a reasonably sophisticated suite of features for interacting with proxies. + The proxy request syntax very closely mirrors that of straight HTTP, which + means that it is possible to make proxy-style requests using pathoc without + any additional syntax, by simply specifying a full URL instead of a simple + path: +

+ + 
> pathoc -p 8080 localhost "get:'http://google.com'"
+ +

+ Another common use case is to use an HTTP CONNECT request to probe remote servers + via a proxy. This is done with the -c command-line option, + which allows you to specify a remote host and port pair: +

+ + 
> pathoc -c google.com:80 -p 8080 localhost get:/
+ +

+ Note that pathoc does not negotiate SSL without being explictly instructed + to do so. If you're making a CONNECT request to an SSL-protected resource, + you must also pass the -s flag: +

+ + 
> pathoc -sc google.com:443 -p 8080 localhost get:/
+
+ + +
+
+

Embedded response specification

+
+ +

+ One interesting feature of the Request sppecification language is that you can embed + a response specifcation in it, which is then added to the request path. Here's + an example: +

+ + 
> pathoc localhost:9999 "get:/p/:s'401:ir,@1'"
+ +

+ This crafts a request that connects to the pathod server, and which then crafts a + response that generates a 401, with one random byte embedded at a random + point. The response specification is parsed and expanded by pathoc, so you + see syntax errors immediately. This really becomes handy when combined with + the -e flag to show the expanded request: +

+ + 
+        > > pathoc -e localhost:9999 "get:/p/:s'401:ir,@1'" >> Spec: get:/p/:s'401:i15,\'o\':h\'Content-Length\'=\'0\'':h'Content-Length'='0'
+        << 401 Unoauthorized: 0 bytes
+ +

+ Note that the embedded response has been resolved before being sent + to the server, so that "ir,@1" (embed a random byte at a random location) + has become "i15,\'o\'" (embed the character "o" at offset 15). You now have + a pathoc request specification that is precisely reproducable, even with + random components. This feature comes in terribly handy when testing a proxy, + since you can now drive the server repsonse completely from the client, and + have a complete log of reproducible requests to analyse afterwards. +

+
+{% endblock %} -- cgit v1.2.3