mirror of
https://github.com/Grasscutters/mitmproxy.git
synced 2024-11-27 18:31:22 +00:00
153 lines
5.4 KiB
HTML
153 lines
5.4 KiB
HTML
{% 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>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::</p>
|
|
|
|
<pre class="terminal">> pathoc -p 8080 localhost "get:'http://google.com'"</pre>
|
|
|
|
<p>Another common use case is to use an HTTP CONNECT request to probe
|
|
remote servers via a proxy. This is done with the <b>-c</b> command-line
|
|
option, which allows you to specify a remote host and port pair:</p>
|
|
|
|
<pre class="terminal">> pathoc -c google.com:80 -p 8080 localhost get:/</pre>
|
|
|
|
<p>Note that pathoc does <b>not</b> 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 <b>-s</b> flag:</p>
|
|
|
|
<pre class="terminal">> pathoc -sc google.com:443 -p 8080 localhost get:/</pre>
|
|
|
|
</section>
|
|
|
|
|
|
{% endblock %}
|