なぜ今さら「OSコマンドインジェクション」なのか？——現場で生き残るための防御論
現場のエンジニア諸君、日々お疲れ様。CISSPの知見をベースに一つ言っておく。「OSコマンドインジェクションは過去の脆弱性だ」なんて甘い考えを持っているなら、今日その考えを捨ててくれ。
確かに、FWやWAFの普及で「昔ながらの派手な攻撃」は減った。だが、クラウドネイティブな環境、マイクロサービス化が進んだ現代において、この脆弱性は「権限昇格」や「ラテラルムーブメント（横展開）」の決定打として、攻撃者に常に狙われている。
今日は、教科書的な「外部入力を避ける」という抽象論ではなく、なぜコードが汚染されるのか、そしてどうやって「シェルを使わずに」安全を担保するか、その実装の作法を叩き込む。
—
1. 攻撃者の視点：なぜ「exec」が地雷なのか
まず、PoC（概念実証）の恐怖を思い出してほしい。攻撃者は、あなたの書いたコードの「わずかな隙間」を狙う。
例えば、ユーザーの入力値を元にファイル変換を行うようなコードだ。
// 【危険な実装例】絶対にやってはいけない
$filename = $_GET[‘file’];
system(“convert ” . $filename . ” output.jpg”);
ここで攻撃者は image.jpg; rm -rf /; といった入力を送る。セミコロンによるコマンド連結だ。OSは convert image.jpg を実行した後、間髪入れずに rm -rf / を実行する。Webサーバーの権限で動いているプロセスが、その権限の範囲内でシステムを破壊し尽くす。これがOSコマンドインジェクションの正体だ。
—
2. 鉄則：「シェルを呼び出さない」が最強の防壁
多くのエンジニアが陥る罠は「エスケープ処理で頑張ろうとすること」だ。escapeshellarg() を使えば大丈夫？ 確かに有効だが、OSやシェルのバージョンごとの仕様差異まで完璧に制御できる自信はあるか？
セキュリティの基本は「複雑性の排除」だ。
シェルを介さず、OSのAPIを直接叩く実装に切り替えろ。これが「安全な開発」の極意だ。
【Python】安全なプロセス実行（subprocessモジュールの正しい使い方）
Pythonで外部コマンドを呼ぶときは、os.systemや shell=True を使ってはいけない。リスト形式で引数を渡し、シェルを経由させないのが鉄則だ。
import subprocess
def convert_image(filename):
# shell=False (デフォルト) を維持し、引数はリストで渡す
# これにより、セミコロンやパイプなどのシェルメタキャラクタは「ただの文字列」として扱われる
try:
result = subprocess.run(
[“/usr/bin/convert”, filename, “output.jpg”],
check=True,
capture_output=True,
text=True
)
return result.stdout
except subprocess.CalledProcessError as e:
# エラーハンドリングは詳細を隠蔽し、ログにのみ残すこと
print(f”Error: {e.stderr}”)
return None
【Node.js】child_process.exec を避けろ
Node.jsでも同様だ。exec はシェルを生成するため危険だが、execFile を使えば引数を配列で分離できる。
const { execFile } = require(‘child_process’);
function processFile(userInput) {
// ユーザー入力を直接コマンド文字列に埋め込まず、配列の要素として渡す
// これにより、攻撃者が “;” 等を入力しても、単なるファイル名として解釈される
execFile(‘/usr/bin/some-command’, [userInput], (error, stdout, stderr) => {
if (error) {
console.error(‘実行失敗:’, error);
return;
}
console.log(‘結果:’, stdout);
});
}
—
3. 多層防御：アプリケーションの外側で守る
コードを修正するのは当然だが、万が一のバグに備えて、インフラ側でも「動かさないための制約」を課すべきだ。
WAFによるフィルタリング（AWS WAFの例）
AWS WAFを利用しているなら、「SQLインジェクション」だけでなく「コマンドインジェクション対策」のマネージドルールセットを有効にせよ。
AWSManagedRulesCommonRuleSetを適用する。- 特に
SizeRestrictions_BODYなどを設定し、異常に長い入力値を弾く。
IAM権限の最小化
Webサーバーが root で動いているか？ 即刻やめるべきだ。
コンテナ環境であれば、SecurityContext を使い、読み取り専用ファイルシステム (readOnlyRootFilesystem: true) を適用し、プロセスが勝手にバイナリを落として実行できないように制限する。これが「多層防御」の現場レベルでの運用だ。
—
最後に：セキュリティは「態度」だ
後輩たちによく言っていることがある。「セキュリティはパッチを当てることではなく、思考の習慣だ」と。
外部入力は常に「悪意あるもの」と仮定せよ。そして、実装するたびに自問自答してほしい。「この処理をシェルなしで実現する方法はないか？」 と。
この問いを立て続ける限り、君たちは脆弱性を作り込まないエンジニアになれる。もしコードレビューで exec や system という文字列を見かけたら、即座に修正を要求すること。それが、君たちのプロダクトと、何よりユーザーの信頼を守る唯一の道だ。
さあ、今日も堅牢なコードを書いてくれ。現場からは以上だ。
コメント