SSRF攻撃：サーバー自身への攻撃（続き）

Hello there, ('ω')ノ

SSRF（Server-Side Request Forgery）の攻撃が成功する理由の一つに、 「サーバーがローカルからのリクエストを信頼してしまう」 という問題があります。
この信頼関係のせいで、本来 認証が必要な管理機能 などに SSRF経由でアクセスが可能 になってしまいます。

1. なぜアプリケーションはローカルリクエストを信頼するのか？

① フロントエンドのアクセス制御をバイパスできる

多くのアプリケーションでは、アクセス制御を ロードバランサーやリバースプロキシ などのフロントエンドで実装していることがあります。
この場合、通常の外部リクエストは適切に制限されますが、 サーバー内部からのリクエストには制限が適用されない ことがあります。

例:
- https://admin.company.com/ は外部ユーザーにはブロックされる
- しかし、内部ネットワーク や localhost からのリクエストは制限がない
- SSRFを利用すれば サーバー経由でアクセスできてしまう

② システム復旧のための「管理者バックドア」

一部のシステムでは、 障害発生時の管理者用バックドア として、 ローカル環境からのアクセスを特別に許可 することがあります。

例:
- あるアプリケーションでは、管理者が パスワードを忘れた場合でも システム復旧ができるように、 localhost からのアクセスを認証なしで許可 する仕組みがある
- これにより、SSRFを利用すれば 認証不要で管理画面にアクセス可能 になってしまう

攻撃シナリオ:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://127.0.0.1/admin/reset-password

→ パスワードリセット機能が実行され、攻撃者が管理者アカウントを乗っ取れる

③ 管理機能が「別のポート」で動作している

管理者向けのインターフェースは、 一般ユーザーがアクセスするアプリとは別のポート で動作していることがあります。

例:
- https://www.company.com/（一般ユーザー向け）
- https://www.company.com:8080/（管理者用）

通常、外部のユーザーは 8080 ポートにはアクセスできませんが、 SSRFを使ってサーバー内部からアクセスすることが可能 です。

攻撃シナリオ:

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://127.0.0.1:8080/admin

→ 管理画面の情報が攻撃者に漏洩する可能性がある

2. なぜSSRFが「重大な脆弱性」となるのか？

① 通常のアクセス制御を回避できる

ローカルからのリクエストが 信頼される設計 になっていると、 認証なしで管理機能にアクセス可能 になってしまう
IP制限だけでは不十分（サーバー自身が攻撃に加担するため）

② 内部ネットワーク全体にアクセスできる

SSRFを利用して、企業の 内部システムやバックエンドAPI にリクエストを送ることが可能
例：
- http://127.0.0.1/admin → 管理画面アクセス
- http://10.0.0.1:3306/ → データベースへアクセス
- http://192.168.1.100:5000/api/internal → 内部APIの情報を取得

③ クラウド環境ではさらに危険

AWS, GCP, Azureなどのクラウド環境では、http://169.254.169.254/latest/meta-data/ にアクセスすると、 クラウドの認証情報（IAMクレデンシャルなど）が取得できる
これにより、 クラウドの全リソースが乗っ取られる 可能性がある

3. SSRF対策

① ローカルIPへのリクエストをブロック

127.0.0.1, localhost, 169.254.169.254 などへのリクエストを禁止する
プライベートIPレンジ（10.0.0.0/8, 192.168.0.0/16 など）へのリクエストも制限する

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リクエストをホワイトリスト制限

許可されたドメインのみにアクセスできるようにする
例：
- ❌ http://127.0.0.1/admin（ブロック）
- ✅ https://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）を導入
CSRFトークンを使用し、外部リクエストをブロック

④ ファイアウォールの設定

サーバー自身のリクエストを制限（localhost へのHTTPリクエストを禁止）
クラウドメタデータサービス（169.254.169.254）へのアクセスをブロック

AWSの例：IAMポリシーでメタデータAPIをブロック

{
  "Effect": "Deny",
  "Action": "ec2:DescribeInstanceMetadata",
  "Resource": "*"
}

4. まとめ

SSRFは、サーバーの「ローカルからのアクセスを信頼する設計」を悪用し、管理機能や内部ネットワークに不正アクセスする攻撃手法です。
特に、クラウド環境では 認証情報の漏洩による重大な被害 につながる可能性があります。

✅ ホワイトリストによるURL制限
✅ ローカルIP・メタデータサービスへのアクセスブロック
✅ 管理画面のセキュリティ強化

これらの対策をしっかり行い、SSRFによる被害を防ぎましょう。

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.