2026.05.01 2026.05.14

【コマンドインジェクション編】OSコマンドに混ざる悪意とRCEの経路｜CTF思考フレームワーク #16

安全に生きたい編集部

📖 この記事はシリーズの一部です

「CTF思考フレームワーク」　Web脆弱性編　#16 / 公開中 10記事　→　シリーズ一覧を見る →

コマンドインジェクションは、Webアプリが裏側でOSコマンドを呼び出すときに、ユーザー入力がコマンドの一部として解釈されてしまう脆弱性です。ping診断、画像変換、PDF生成、ファイル圧縮、動画変換、アーカイブ展開など、サーバー側で外部CLIツールを使う処理では特に注意が必要です。

本来は「ファイル名」「ホスト名」「URL」「変換オプション」として扱うはずの入力が、OSやシェルに別の意味として解釈されると、意図しない処理が実行される恐れがあります。古典的な脆弱性ですが、便利な外部ツール呼び出しとセットで、今でも見落とされやすいテーマです。

注意：この記事で扱う考え方は、必ずCTF・自分の検証環境・許可された診断範囲でのみ使ってください。実在するWebサービスや他人のサーバーに対して試すことは、不正アクセスや業務妨害につながる恐れがあります。

この記事の難易度

難易度：★★☆（中級）　／　所要：10〜12分　／　前提：CTF思考フレームワーク #15

OSコマンドにユーザー入力を混ぜる設計は、RCEにつながる危険な入口になりやすいよ💀

Contents

👀 観察フェーズ：まず何を見る？
🤔 仮説フェーズ：攻撃者は何を考える？
🔬 検証フェーズ：どうやって確かめる？
⚔️ 攻撃フェーズ：CTFで見る典型パターン
🛡️ 防御フェーズ：どう守る？
🔑 あわせて見直したい基本対策
⚠️ よくある落とし穴
🧰 ツール早見表
🎓 本気で学びたい人へ
📚 もっと深く学びたい人へ
📚 次に読みたい
🧪 自分で検証してみる
⚖️ 大事なお約束

👀 観察フェーズ：まず何を見る？

まずアプリが外部コマンドを呼ぶ箇所を探す！画像処理、PDF生成、ping診断、アーカイブ展開は要注意🔍

観察するポイントは、「ユーザー入力がどこまでサーバー側の処理に渡っているか」です。ファイル名、ホスト名、URL、変換対象、出力形式、圧縮形式などが、そのまま外部コマンドの引数に使われていないかを確認します。

シェル経由の実行、文字列連結でのコマンド生成、ユーザー入力を含むファイル名・URL・引数は重点的に確認します👀

「ただのファイル名」や「ただのURL」のつもりでも、サーバー側ではコマンドの一部として扱われることがあるんだね…😱

🤔 仮説フェーズ：攻撃者は何を考える？

コマンドインジェクションの典型は4分類で考えると整理しやすいよ。

🔗 仮説①：コマンド文字列への混入

ユーザー入力がコマンド文字列に直接連結されている場合、OSやシェルが入力を単なるデータではなく、別の意味を持つ文字列として解釈する恐れがあります。文字列連結でコマンドを組み立てている処理は、最初に疑うべきポイントです。

⚡ 仮説②：引数・オプションの注入

外部コマンドに渡す引数やオプションがユーザー入力から作られている場合、本来許可していない動作モードや危険なオプションが有効化される恐れがあります。ファイル変換、圧縮、画像処理、ネットワーク診断系の機能では特に注意が必要です。

🤐 仮説③：Blind型の実行確認

コマンドの実行結果が画面に表示されない場合でも、処理時間、エラー内容、サーバー側ログ、外部通信の有無などから、意図しない処理が走っている可能性を推測されることがあります。

📦 仮説④：ファイル名・アーカイブ・変換処理経由

ファイル名、展開先パス、変換オプション、アーカイブ内のメタ情報などが外部コマンドに渡る場合、想定外の解釈が起きることがあります。アップロード処理や変換処理では、ファイルの中身だけでなく、名前や属性の扱いも確認します。

コマンドインジェクションの本質は、「データとして扱うべき入力が、命令として解釈されてしまうこと」です。守る側は、入力値をコマンド文字列として扱わない設計にする必要があります。

ポイントは、入力を命令として解釈させないことなんだね💧

🔬 検証フェーズ：どうやって確かめる？

CTFやローカル検証環境では、入力値がOSコマンドの引数として安全に扱われているか、またはシェルに解釈される可能性がないかを確認します。見るべきポイントは、レスポンス内容、エラーの出方、処理時間、サーバー側ログの変化です。

検証は必ずCTF・ローカル環境・許可された診断範囲で。実サービスに対して試すのは絶対NGだよ🧪

検証時は、次のような観点で整理すると分かりやすくなります。

入力値がそのまま外部コマンドに渡っていないか
コマンド全体を文字列連結で組み立てていないか
シェル経由で実行していないか
引数配列形式で安全に渡しているか
エラーやログにコマンド実行の痕跡が出ていないか
外部コマンドを使わずに済む処理ではないか

具体コマンドを覚えるより、入力がどこで命令に変わるかを見るのが大事なんだね🌐

⚔️ 攻撃フェーズ：CTFで見る典型パターン

ここでは実サービスに対して試せる手順ではなく、CTFやローカル検証環境でよく出る「考え方」だけを整理します。具体的な検証は、必ず自分の環境・CTF問題・許可されたラボ内で行ってください。

コマンドインジェクションの代表パターンはこの3つで整理できるよ。

① コマンド連結型

ユーザー入力がコマンド文字列に混ざり、意図しない追加処理として解釈されるパターンです。シェル経由の実行や文字列連結がある場合に起きやすくなります。

② 引数注入型

外部コマンドのオプションや引数として、想定外の値が渡されるパターンです。コマンドそのものを安全に呼んでいても、許可していないオプションを受け入れる設計だと危険です。

③ Blind型

画面には結果が出なくても、処理時間、エラーログ、外部通信の有無などから、意図しない処理が実行された可能性を推測されるパターンです。

CTF{never_build_shell_commands_from_user_input}

原則はシンプルです。ユーザー入力を文字列連結でシェルに渡さない。これだけで、コマンドインジェクションの多くは防ぎやすくなります。

🛡️ 防御フェーズ：どう守る？

コマンドインジェクション対策は、「そもそもシェルに渡さない」のが最強だよ🛡️

🚫 可能ならOSコマンドを使わない

画像処理、圧縮、PDF生成、ファイル操作などは、可能な限り言語標準ライブラリや安全なSDKを使います。外部コマンド呼び出しそのものを減らすことが、最も強い対策です。

✅ 引数配列で渡し、シェルを介さない

外部コマンドを使う場合も、コマンド全体を文字列連結で組み立てず、実行ファイル名と引数を分けて渡します。シェル解釈を避ける設計にします。

🔒 入力は許可リスト方式で検証

ファイル名、形式、拡張子、ホスト名、出力形式などは、許可した値だけを受け入れます。禁止文字リストに頼るのではなく、許可する文字種・長さ・形式を明確にします。

🛡️ 最小権限・隔離環境で実行

Webアプリや外部コマンド実行用のプロセスは、非rootユーザーで動かし、不要なファイルやネットワークへアクセスできないように制限します。コンテナ、読み取り専用ファイルシステム、ネットワーク制限なども検討します。

🧾 実行ログと監査ログを残す

外部コマンドを呼ぶ処理では、誰が・いつ・どの機能から実行したかを記録します。異常な引数、失敗ログ、想定外の実行時間を検知できるようにします。

「シェルを介さない」「許可リストで絞る」「最小権限で動かす」が基本なんだね💪

🔑 あわせて見直したい基本対策

コマンドインジェクションの直接対策ではありませんが、セキュリティ全体を見直す際に、パスワードの使い回しも同時に改善しておくと安心です。パスワード管理ツールを使って、サービスごとに異なるパスワードを管理しましょう。

※ 上記は他社サービスへのリンクです。購入は各自でご判断ください。

⚠️ よくある落とし穴

一部の危険文字だけを禁止して、別の特殊な解釈を見落とす。
エスケープ関数を使っただけで安心し、引数全体の設計を見直していない。
引数配列で渡しているつもりでも、内部でシェル経由になっている。
ファイル名や出力形式にユーザー入力をそのまま使っている。
画像処理・PDF生成・アーカイブ展開など、外部ツールの安全設定を確認していない。
ブラックリスト方式の禁止文字列リストに頼り、許可リスト方式にしていない。
外部コマンドを実行するプロセスに、不要なファイル・ネットワーク・環境変数へのアクセス権がある。

🧰 ツール早見表

コマンドインジェクションは、攻撃ツールよりも「危険な呼び出し方を見つける力」が重要です。補助ツール・資料としては、以下のようなものが役立ちます。

ツール・資料	用途	ひと言
Burp Suite	リクエスト確認	CTF・許可された診断で、入力値の流れを確認する
アプリケーションログ	実行経路の確認	外部コマンド呼び出しの有無や失敗ログを見る
静的解析・コードレビュー	危険な呼び出しの発見	シェル経由の実行や文字列連結を重点的に確認する
コンテナ・権限制御	被害範囲の限定	非root実行、読み取り専用FS、ネットワーク制限を確認する
OWASP Command Injection関連資料	防御設計	安全な実装方針を確認する