シェルという「毒杯」の扱い方：OSコマンドインジェクションの深淵を歩く
セキュリティアーキテクトとして多くのコードベースを監査してきたが、未だにアプリケーション層で「シェルを直呼び」する実装を目にする。これは、弾丸の入った銃の引き金を、ユーザーの入力という不確実な指に委ねるようなものだ。
OSコマンドインジェクションの本質は、開発者が意図した「制御データ」と、シェルが解釈する「メタ文字（制御命令）」の境界線が、メモリ上の引数処理過程で曖昧になることにある。今日は、この泥沼から脱却するためのアーキテクチャ設計について、綺麗事抜きで語ろう。
—
1. なぜ「メタ文字の無害化」は常に失敗するのか
多くのジュニアエンジニアは、escapeshellarg() や addslashes() を使えば安全だと信じている。だが、それは「シェルという巨大なエントロピー」に対する過信だ。
攻撃者は、OSのバージョン、シェルの種類（bash, zsh, sh）、そして環境変数（IFSやPATHの改ざん）を組み合わせて、エスケープをすり抜ける。例えば、あるOSのパッチレベルで特定の制御文字がどう解釈されるか、その挙動を完全に予測し続けることは不可能に近い。
根本原因: exec() や system() は、プロセス生成の過程でシェルを経由する。このとき、入力値は文字列として渡され、シェルはそれを「コマンドの構成要素」として解析する。この解析プロセスこそが、インジェクションの温床だ。
—
2. アーキテクチャの鉄則：シェルからの脱却と分離
我々が目指すべきは「無害化（Sanitization）」ではない。「回避（Avoidance）」だ。
APIによるプロセス直接起動
シェルを介さず、OSのシステムコール（execveなど）を直接ラップしている言語のライブラリを利用せよ。引数を配列（リスト）として渡すことで、OSは「どこまでが実行ファイル名で、どこからが引数か」をメモリレベルで厳密に区別する。
import subprocess
悪手: shell=True は絶対に使用してはならない
subprocess.run(“ls -l ” + user_input, shell=True)
正手: 引数をリストで渡すことで、シェルによる解析を回避する
def list_files(directory):
# 引数はリストの各要素としてOSに渡され、メタ文字は単なる「文字」として扱われる
# 例えば directory に “; rm -rf /” を入れても、lsはファイル名として探索するだけだ
return subprocess.run([“ls”, “-l”, directory], capture_output=True, text=True)
—
3. ホワイトリストによる「物理的な遮断」
入力値のバリデーションにおいて、「何が危険か」を考えるのは無駄だ。攻撃者は常に我々の想像の外側の文字コード（マルチバイト混入や制御文字のエンコード）を突いてくる。
実装すべきは、「何が許可されるか」の厳格なホワイトリストだ。
import re
def validate_input(user_input):
# 正規表現で許可する文字セット以外を徹底的に弾く
# アルファベット、数字、ハイフンのみを許可する（例: UUIDや特定ID）
if not re.fullmatch(r'[a-zA-Z0-9\-]{1,32}’, user_input):
raise ValueError(“Invalid input format detected.”)
return user_input
このバリデーションを、アプリケーションの境界（ゲートウェイ）で実行し、そこを通ったデータのみがバックエンドのプロセス起動に関与できるようにする。
—
4. プロンプトインジェクションへの応用：現代の防衛戦略
話は変わるが、最近の生成AIに対する攻撃も、構造は全く同じだ。LLMはユーザー入力を「命令」として解釈する。これはシェルがユーザー入力を「コマンド」として解釈するのと同じ脆弱性だ。
これを防ぐための「ガードレイル」の設計も、同様の考え方で行うべきだ。
1. 入力の構造化: ユーザー入力とシステムプロンプトを明確に分離する（ChatML等のフォーマット利用）。
2. 出力の検証: AIの生成したコードやコマンドを、そのまま実行環境に渡さず、サンドボックス（コンテナ等）で一度解析する。
3. トークンレベルの制約: AIが生成可能な文字種やトークン量を制限し、エスケープシーケンスの挿入を物理的に不可能にする。
—
結論：セキュリティは「規律」である
技術的なパッチやライブラリはあくまで補助輪に過ぎない。真の防御は、「外部からの入力を、システムを動かすための命令（シェルやAIのプロンプト）と絶対に混ぜない」という、開発チームの厳格なアーキテクチャ規律から生まれる。
今日から、プロジェクト内の grep -r "shell=True" や exec() の呼び出しを監査してみてほしい。そこに潜むのは、単なる脆弱性ではなく、君たちのシステムの「設計上の甘さ」そのものだ。
攻撃者は、システムの端の端まで見ている。我々もまた、最も深く、最も低いレイヤから防壁を構築しなければならない。健闘を祈る。
コメント