1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
|
{% extends "frame.html" %}
{% block body %}
<div class="page-header">
<h1>
pathoc
<small>A perverse HTTP client.</small>
</h1>
</div>
<p>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 <a href="/docs/language">small, terse
language</a>, which pathod shares with its server-side twin <a
href="/docs/pathod">pathod</a>. To view pathoc's complete range of options, use
the command-line help:</p>
<pre class="terminal">pathoc --help</pre>
<section>
<div class="page-header">
<h1>Getting Started</h1>
</div>
<p>The basic pattern for pathoc commands is as follows: </p>
<pre class="terminal">pathoc hostname request [request ...]</pre>
<p>That is, we specify the hostname to connect to, followed by one or more
requests. Lets start with a simple example:</p>
<pre class="terminal">> pathoc google.com get:/
<< 301 Moved Permanently: 219 bytes</pre>
<p>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 <b>-p</b> command-line
option):</p>
<pre class="terminal">> pathoc -s google.com get:/
<< 301 Moved Permanently: 219 bytes</pre>
</section>
<section>
<div class="page-header">
<h1>Multiple Requests</h1>
</div>
<p>There are two ways to tell pathoc to issue multiple requests. The first
is to specify them on the command-line, like so:</p>
<pre class="terminal">> pathoc google.com get:/ get:/
<< 301 Moved Permanently: 219 bytes
<< 301 Moved Permanently: 219 bytes</pre>
<p> 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 </p>
<p> The other way to issue multiple requets is to use the <b>-n</b> flag:</p>
<pre class="terminal">> pathoc -n 2 google.com get:/
<< 301 Moved Permanently: 219 bytes
<< 301 Moved Permanently: 219 bytes</pre>
<p> The output is identical, but two separate TCP connections are made to
the upstream server. These two specification styles can be combined:</p>
<pre class="terminal">> 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</pre>
<p> Here, two distinct TCP connections are made, with two requests issued
over each. </p>
</section>
<section>
<div class="page-header">
<h1>Basic Fuzzing</h1>
</div>
<p>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:</p>
<pre class="terminal">> pathoc -e -C 200 -t 2 -n 1000 localhost get:/:b@10:ir,@1</pre>
<p>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:<p>
<ul>
<li> Corrupting the request in this way will often make the server
enter a state where it's awaiting more input from the client. This is
where the <b>-t</b> option comes in, which sets a timeout that causes
pathoc to disconnect after two seconds. </li>
<li> The <b>-n</b> option tells pathoc to repeat the request 1000
times.</li>
<li> The <b>-C</b> option tells pathoc to ignore HTTP 200 response
codes. You can use this to fine-tune what pathoc considers to be an
exceptional condition, and therefore log-worthy.</li>
<li> The <b>-e</b> option tells pathoc to print an explanation of each
logged request, in the form of an expanded pathoc specification with
all random portions and automatic header additions resolved. This lets
you precisely replay a request that triggered an error </li>
</ul>
</section>
<section>
<div class="page-header">
<h1>Interacting with Proxies</h1>
</div>
<p>At the moment, pathoc has no explicit support for proxies, but there's a
workaround that serves many use cases. Instead of specifying just a path,
specify an entire URL to the GET request, like so (assuming there's a proxy
running on port 8080 of localhost):</p>
<pre class="terminal">> pathoc -p 8080 localhost "get:'http://google.com'"</pre>
<p>Proxy support is going to be a major focus of development for the next
version of pathoc, so keep an eye on the repo.</p>
</section>
{% endblock %}
|
