【OSコマンドインジェクション編】入力をシェルへ渡さない設計と守り方｜CTF思考フレームワーク #30

こんにちは、アンペンです！

前回は、サーバ側フレームワークでのデシリアライズRCEを扱いました。

今回は、サーバの裏で動くOSコマンド呼び出しに潜むOSコマンドインジェクションを、サーバ視点で改めて深掘りしていきます。シェルに入力が繋がる経路と、その守り方を一緒に見ていきましょう。

コマンドインジェクションも#16でやったよね。何が違うの？

#16は概要中心。今回はサーバ側の言語別の危険関数と『シェル経由の有無』を、もう少し細かく見ていくよ。

コマンドインジェクションは#16でも学びました。今回はその“実装編”——『コードをどう書くか』で、防げるか防げないかがハッキリ分かれる、という話をします。実はこの攻撃、エスケープを頑張るより、たった一つの“書き方の選択”でほぼ封じられます。その分かれ目が『シェルを経由するかどうか』。今日はそこを、受付係への伝言のたとえで、コードレベルまで踏み込んで整理します。

『シェル経由』が分かれ目

サーバから外部コマンドを呼ぶときの選択肢は、大きく2つあります。

• シェル経由：OSのシェル(bash/cmd)に文字列を渡す。; | ` 等の区切り文字が解釈される
• シェル非経由：コマンドと引数を配列でOSに直接渡す。シェルが介入せず、区切り文字は『ただの文字』に

シェル経由を選んだ瞬間、利用者入力が混ざると『次のコマンド』が成立する可能性が常に生まれます。だから、コードレベルで非経由を選ぶ設計が最強の防御になります。

ここがこの回の核心です。シェルを経由しない（非経由）と決めるだけで、「この記号は危ない？許していい？」という悩みが、まるごと消えてなくなります。なぜなら、危険なのは“シェルが記号を解釈すること”であって、シェルがいなければ、 ; rm -rf / と書かれても、ただの“長い文字列”として安全に扱われるから。エスケープで一個ずつ記号と戦うのではなく、戦う土俵そのものをなくす——これが一番ラクで、一番確実な守りです。

もう少しかみくだきましょう。サーバが外部コマンドを呼ぶとき、道は2つあります。一つは『コマンドを一本の文章にして、通訳さん（シェル）に読んでもらう』方法。もう一つは『コマンド名と引数を、最初からバラバラの部品として、OSに直接手渡す』方法。前者では、文章の中の ; などをシェルが“区切り”と解釈してしまう。後者では、シェルが登場しないので、何が書いてあっても“ただの部品の中身”として扱われます。この違いが、運命を分けます。

図解：文字列連結 vs 引数配列

同じ画像変換処理でも、引数の渡し方によって、入力に混ざる悪意の効き方がまったく違います。

言いかえると、攻撃を防げるかどうかは“どんな入力チェックをしたか”ではなく、“どう呼び出したか”でほぼ決まる、ということ。入口で頑張るより、出口（コマンドの呼び方）を正すほうが、ずっと効きます。

メタ文字をエスケープで防ぐ道も一応ありますが、おすすめしません。理由は#16でも触れたとおり、記号の種類が多く、OSやシェルで挙動も違って、“漏れ”が必ず生まれるから。一個でも見落とすと、そこから抜けられます。非経由なら、そもそもエスケープという作業自体が要らない。「頑張って正しくエスケープする」より「エスケープしなくていい構造にする」。守りは、頑張りに頼らない形が一番強いんです。

言語別 危険関数の代表

次に、自分の言語の“危ない関数”を知っておきましょう。どの言語にも、たいてい“シェルを呼んでしまう便利関数”が用意されています。Pythonの os.system、Node.jsの exec、PHPの shell_exec……名前は違っても、共通点は「文字列を渡すと、裏でシェルに流す」こと。まずは自分の使う言語のこのリストを頭に入れて、コードの中で見かけたら“立ち止まる”クセをつけるのが第一歩です。

注意すべき関数

• Python： os.system / subprocess.run(..., shell=True) / os.popen
• Node.js： child_process.exec / execSync
• PHP： shell_exec / system / exec / passthru
• Java： Runtime.exec(String) 文字列形式・ ProcessBuilder 文字列連結
• Ruby： バッククォート `cmd` / system(str) 文字列形式

これらに利用者入力を文字列として渡している箇所は、最優先で見直す対象です。画像変換・PDF生成・ping・grep等の便利機能は、内部でこれらを使うことが多いため、ライブラリ仕様も合わせてチェックしましょう。

見落としがちなのが、“自分では呼んでいないつもりの”コマンド実行です。画像変換、PDF生成、ping確認、圧縮・解凍——こうした便利機能の中には、裏でこっそり外部コマンドをシェル経由で呼んでいるライブラリが少なくありません。あなたのコードに os.system が無くても、使っているライブラリが内部で呼んでいれば、同じ穴が空きます。だから自分のコードだけでなく、“依存ライブラリが何をしているか”まで目を向けることが大切です。

練習は、コードを検索して『外部コマンドを呼んでいる場所』と『シェル経由かどうか』を一覧にするだけ。攻撃ではなく棚卸しです。あわせて、そのプロセスがどんな権限で動いているかも見てみましょう。もし全部rootで動いていたら、それは別の意味で危険信号。本物のサービスにメタ文字を送るのは厳禁、確認は自分のラボの中だけで。

CTFでやってみよう：コマンド呼び出しを棚卸し

守りの4点セットのうち、最後の『最小権限』について補足しておきましょう。

非経由にしたなら、もうプロセスの権限まで気にしなくていいんじゃない？

そう思いたくなるけど、これは“もしもの保険”として効くんだ。万一どこかでコマンドインジェクションが成立しても、そのプロセスが“ほとんど何の権限も持たない専用ユーザ”で動いていれば、攻撃者にできることはごくわずか。逆にrootで動かしていたら、一発でサーバ全部を握られる。入口を塞ぐ（非経由）と、破られた後の被害を小さくする（最小権限）。デシリアライズのときと同じ“二段構え”が、ここでも効くんだよ。

守る側なら、「非経由+配列+絶対パス+最小権限」

コマンドインジェクションの守りは、「シェルを経由しない」「引数は配列」「絶対パスでコマンド指定」「プロセスは最小権限」の4点が中心です。

『非経由+配列』にするだけで、ほぼ防げるんだね。

そう。エスケープに頼るより、シェルを介在させない構造が一番強いよ。

ここまでをひと言で言うと、コマンドインジェクションの守りは『シェルという土俵を、最初から用意しない』。記号と戦うのではなく、戦いが起きない構造にする。コマンドと引数を配列でOSに直接渡し、絶対パスで指定し、最小権限で動かす。この4点は、暗記というより“クセ”にしてしまうのがおすすめです。

まとめ：『シェルを介在させない』が王道

今日の持ち帰りは『エスケープより、シェル非経由』です。多くの人はつい“危ない記号をどう弾くか”を考えますが、本当に強いのは“そもそもシェルを呼ばない”という一手。shell=True を避け、引数は配列で。この書き方を標準にするだけで、OSコマンドインジェクションはほとんど起きなくなります。

次回は、ファイルパスに紛れるパストラバーサルを扱います。 ../ でディレクトリ階層を越える攻撃と、その守り方を見ていきましょう。

次に読みたい記事

参考資料