-
Notifications
You must be signed in to change notification settings - Fork 73
Configuration
SSRF Proxy configuration options fall within several main categories:
The proxy server accepts --interface and --port options.
Server options:
-p, --port=PORT Listen port (Default: 8081)
--interface=IP Listen interface (Default: 127.0.0.1)
These options specify settings used to connect to the host vulnerable to SSRF.
--ssl Connect using SSL/TLS.
--proxy=PROXY Use a proxy to connect to the server.
(Supported proxies: http, https, socks)
--insecure Skip server SSL certificate validation.
--timeout=SECONDS Connection timeout in seconds (Default: 10)
The SSRF request options specify the details required to both craft a valid HTTP request to the vulnerable server and craft a valid SSRF request to a user-supplied destination URL.
The destination URL is signified by the placeholder (xxURLxx by default) which must be present somewhere in the URL, headers or body. All instances of the placeholder will be overwritten by the client request before the SSRF request is sent to the vulnerable server.
-u, --url=URL Target URL vulnerable to SSRF.
-f, --file=FILE Load HTTP request from a file.
--placeholder=STR Placeholder indicating SSRF insertion point.
(Default: xxURLxx)
--method=METHOD HTTP method (GET/HEAD/DELETE/POST/PUT/OPTIONS)
(Default: GET)
--post-data=DATA HTTP post data
--cookie=COOKIE HTTP cookies (separated by ';')
--user=USER[:PASS] HTTP basic authentication credentials.
--user-agent=AGENT HTTP user-agent (Default: none)
--rules=RULES Rules for parsing client request
(separated by ',') (Default: none)
--no-urlencode Do not URL encode client request
Of particular note is the rules option. This option allows specifying a series of rules to be applied to the client request, before the placeholder is overwritten, to ensure the request to the vulnerable server is compatible with the SSRF vulnerability. Rules are executed in the order in which they're provided.
For example, consider a SSRF vulnerability where the destination URL is first base64 decoded before the server requests the URL. In this instance, the --rules base64 argument would be provided, to ensure the client request was base64 encoded before replacing the URL placeholder, thus ensuring the request is well formed.
The following rules are available:
when 'noproto'
str = str.gsub(%r{^https?://}, '')
when 'nossl', 'http'
str = str.gsub(%r{^https://}, 'http://')
when 'ssl', 'https'
str = str.gsub(%r{^http://}, 'https://')
when 'base32'
str = Base32.encode(str).to_s
when 'base64'
str = Base64.encode64(str).delete("\n")
when 'md4'
str = OpenSSL::Digest::MD4.hexdigest(str)
when 'md5'
md5 = Digest::MD5.new
md5.update str
str = md5.hexdigest
when 'sha1'
str = Digest::SHA1.hexdigest(str)
when 'reverse'
str = str.reverse
when 'upcase'
str = str.upcase
when 'downcase'
str = str.downcase
when 'rot13'
str = str.tr('A-Za-z', 'N-ZA-Mn-za-m')
when 'urlencode'
str = CGI.escape(str).gsub(/\+/, '%20')
when 'urldecode'
str = CGI.unescape(str)
when 'append-hash'
str = "#{str}##{rand(36**6).to_s(36)}"
when 'append-method-get'
separator = str.include?('?') ? '&' : '?'
str = "#{str}#{separator}method=get&_method=get"Request modification options can be used to format the client HTTP request appropriately for the SSRF vector and the destination web server accessed via the SSRF.
--forward-method Forward client request method.
--forward-headers Forward all client request headers.
--forward-body Forward client request body.
--forward-cookies Forward client request cookies.
--cookies-to-uri Add client request cookies to URI query string.
--body-to-uri Add client request body to URI query string.
--auth-to-uri Use client request basic authentication
credentials in request URI.
--ip-encoding=MODE Encode client request host IP address.
(Modes: int, ipv6, oct, hex, dotted_hex)
--cache-buster Append a random value to the client request
query string.
Several request modification options allow converting portions of the client request such as cookies and the request body to query string parameters:
--body-to-uri--auth-to-uri--cookies-to-uri
This is useful in instances where the destination server accepts
values supplied in GET or POST parameters interchangeably, or the
destination application server supports cookies in the URL -
most notably JSESSIONID and PHPSESSID.
Similarly, basic authentication credentials can be forwarded
to the destination server by leveraging the --auth-to-uri option
which moves the decoded credentials supplied in the Authorization
header of client requests to the authentication portion of the
destination URL, for example: http://user:pass@example.local
In instances where the SSRF vector allows forwarding client request headers - typical of web based proxies intended for web browsers, and curl.php style SSRF-by-design - various portions of the client request, such as HTTP headers, cookies and the request body, can be forwarded using the appropriate option:
--forward-method--forward-headers--forward-cookie--forward-body
Response modification options can be used to infer information about the response from the destination server and format the response such that the vulnerable intermediary server is mostly transparent to the client initiating the HTTP request.
--match=REGEX Regex to match response body content.
(Default: \A(.*)\z)
--strip=HEADERS Headers to remove from the response.
(separated by ',') (Default: none)
--decode-html Decode HTML entities in response body.
--unescape Unescape special characters in response body.
--guess-status Replaces response status code and message
headers (determined by common strings in the
response body, such as 404 Not Found.)
--guess-mime Replaces response content-type header with the
appropriate mime type (determined by the file
extension of the requested resource.)
--sniff-mime Replaces response content-type header with the
appropriate mime type (determined by magic bytes
in the response body.)
--timeout-ok Replaces timeout HTTP status code 504 with 200.
--detect-headers Replaces response headers if response headers
are identified in the response body.
--fail-no-content Return HTTP status 502 if the response body
is empty.
--cors Adds a 'Access-Control-Allow-Origin: *' header.
Of most importance is the --match option, which expects
a regular expression formatted as a string, to extract the relevant
HTTP response to the client request out of the response from
the vulnerable server. Specifying an accurate regex is
especially important should SSRF Proxy be used by web browsers,
as unwanted junk in the response is likely to corrupt binary
data such as images and other application assets such as
JavaScript and CSS files.
The --guess-status option attempts to infer the appropriate HTTP
status code and reason message by scanning the HTTP response for
known strings and updating the response code and message
appropriately.
The --detect-headers option can be useful should the target SSRF
server be particularly chatty. In instances where the SSRF server
discloses both the response headers and the response body, this option
can be used to identify the HTTP headers in the response and merge
these headers with the response headers sent to the client.
Several response modification options are also provided for
convenience purposes, such as adding wildcarded CORS headers,
performing content-sniffing to automatically apply the appropriate
Content-Type header, or guessing the Content-Type from the file
extension in the request URL.
--cors--guess-mime--sniff-mime
The --fail-no-content option is generally reserved for port scanning
through the proxy.
This option returns a 502 HTTP status code if the response body is empty.
When used in combination with an accurate --match, this option allows
accurate port scanning through some SSRF servers.