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
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
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.
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:
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:/
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.