概要
https://qiita.com/whoami_priv/items/59df45fd40a31ab9b110
詳細内容
## SSRFのやられアプリを作ってみた ~Gemini CLIを活用して~
https://qiita.com/whoami_priv/items/59df45fd40a31ab9b110
セキュリティエンジニアがGemini CLIを使ってSSRFの脆弱性を持つアプリを構築し、その攻撃手法と対策を具体的に解説します。
**Content Type**: 📖 Tutorial & Guide
**Scores**: Signal:4/5 | Depth:4/5 | Unique:3/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 85/100 | **Annex Potential**: 79/100 | **Overall**: 80/100
**Topics**: [[SSRF, Web Application Security, Vulnerable Applications, Docker, Gemini CLI]]
この記事は、セキュリティエンジニアが自身の学習のため、Gemini CLIを駆使してSSRF（Server-Side Request Forgery）の脆弱性を持つウェブアプリケーションを構築し、その仕組みと具体的な攻撃手法を解説するものです。筆者は普段アプリ開発をしない立場から、Gemini CLIの強力さを体感し、本業のセキュリティ学習と結びつけて「やられアプリ」作成に至ったと述べています。
SSRFとは、ウェブアプリケーションがユーザー指定のURLを適切に検証せずに外部リソースへアクセスする機能（例: OGPプレビュー生成、外部API連携）が悪用され、サーバーが攻撃者の意図しない内部ネットワークやクラウドのメタデータサービス、さらにはローカルファイルシステムにアクセスしてしまう脆弱性です。これにより、外部から到達不可能な内部情報の漏洩、認証回避、機密データ（クラウド認証情報など）の窃取、内部システムへの攻撃といった深刻な影響が生じます。
具体的な「やられアプリ」は、Docker環境でfrontendと外部非公開のinternal_apiを連携させ、OGPプレビューを生成する機能を模倣しています。このアプリでは、OGPプレビュー用URL入力欄に内部APIのURLや`file:///etc/passwd`のようなローカルファイルパスを入力すると、frontendがそれらのリソースに代理でアクセスし、本来外部からは見えない情報を漏洩させてしまう様子がデモンストレーションされます。原因は、`frontend_app.py`の`/fetch`エンドポイントにおけるURLの入力値検証の欠如にあります。`http(s)`スキームだけでなく`file`スキームまで処理する実装が、脆弱性を一層悪化させています。
ウェブアプリケーションエンジニアにとって、この事例は、ユーザーが指定するURLをサーバー側で処理する際には、厳格な入力検証と許可リスト方式のスキーム・ホスト制限が必須であるという重要な教訓を示します。安易なURL処理が内部システムへの深刻な脅威につながることを認識し、堅牢なセキュリティ設計を心がけるべきです。特にGeminiのようなAIツールを活用した開発においても、セキュリティの基礎原則を忘れてはならないと警鐘を鳴らしています。