こんにちは！システム開発の現場に飛び込んだばかりの新人の皆さん、毎日たくさんの新しい技術を覚えて奮闘されていることと思います。
今回は、Webアプリケーションのセキュリティにおいて、絶対に避けて通れない「OSコマンドインジェクション」という怖い脆弱性と、そのスマートな防ぎ方についてお話ししていきますね。
「なんだか難しそうな名前だな……」身構えてしまうかもしれませんが、大丈夫です！身近な「家の鍵」に例えながら、一歩ずつ分かりやすく紐解いていきましょう。
—
1. 泥棒はどこから入る？OSコマンドインジェクションの正体
突然ですが、みなさんの家を想像してみてください。玄関のドアには頑丈な鍵がついていますよね。でも、もし「郵便受けの小さな隙間から針金を入れて、内側からガチャリと鍵を開けられてしまったら……」どうでしょう？めちゃくちゃ恐ろしいですよね。
Webアプリケーションの世界における「OSコマンドインジェクション」は、まさにこれと同じ現象なんです。
Webアプリを作るとき、時にはサーバーの裏側でOSの機能（Linuxのコマンドなど）を呼び出して処理をさせたいことがあります。例えば、ユーザーが入力したファイル名を受け取って、サーバー側でファイルを圧縮するような機能です。
もし、開発者が「ユーザーはちゃんとしたファイル名だけを入力してくれるはずだ」と信じ込んで、入力された文字をそのままサーバーの裏側のシェル（命令を実行する黒い画面のようなもの）に渡しちゃったらどうなるでしょうか？
攻撃者は、ファイル名の代わりに、こんな文字を入力してきます。
report.txt; rm -rf /「;（セミコロン）」は、命令の区切りを意味します。つまりサーバー側は、「report.txt というファイルを処理したあとに、rm -rf /（サーバーの中身を全部消し去る凶悪な命令）を実行しちゃえ！」と勘違いして、その通りに動いてしまうんです。
これが、家の郵便受けから鍵を開けられるように、アプリの入力欄からサーバーを乗っ取られてしまう「OSコマンドインジェクション」のメカニズムです。
—
2. 泥棒を防ぐ鉄則①：シェルを呼び出さない（APIを直接使う）
じゃあ、どうやってこの泥棒を防げばいいのでしょうか？
最初の防衛策は、「そもそもシェル（命令の通訳さん）を間に挟まないこと」です。
先ほどの例えで言うなら、郵便受けという「危なっかしい隙間」を経由して鍵を開けさせるのではなく、最初から「専用の安全なボタン」を用意してあげるイメージです。プログラミングの世界では、これを「言語の標準ライブラリ（API）を使う」と言います。
危ない書き方（シェルを呼んでしまう例）と、安全な書き方の違いを、Pythonというプログラミング言語を例に見てみましょう。
【危ない書き方】シェル経由でコマンドを実行する例
import os
# ユーザーからの入力をそのまま受け取る（非常に危険！）
user_input = "report.txt; ls -la"
# os.systemを使うと、OSのシェルがそのまま命令を実行してしまうため、
# 悪意あるコマンド（ls -la など）まで一緒に実行されてしまいます。
os.system("cat " + user_input)【安全な書き方】シェルを介さず、安全なライブラリ関数を使う例
import subprocess
# ユーザーからの入力
filename = "report.txt"
# シェルを介さず、ファイル操作専用の安全な関数や、
# 引数をリスト形式で正確に渡すことで、余計なコマンドの実行を完全に防ぎます。
# これなら仮に filename の中に 「; rm -rf /」 が含まれていても、
# 単なる「そういう名前のファイル」として扱われ、実行されません！
subprocess.run(["cat", filename], check=True)このように、os.system のようなシェルを直接起動する関数は極力使わず、OSの機能に安全にアクセスできる subprocess などのモジュールを適切に選びましょう。これだけでもセキュリティレベルがグッと跳ね上がります。
—
3. 泥棒を防ぐ鉄則②：厳しい「ホワイトリスト検証」
2つ目の防衛策は、「怪しいものはそもそも家に入れない（ホワイトリスト検証）」というアプローチです。
世の中には「ブラックリスト方式（悪い言葉を禁止する）」というものもありますが、これは攻撃者が次々と新しい手口を考えるため、すぐにすり抜けられてしまいます。
そこで私たちが使うべきなのは「ホワイトリスト方式」です。これは、「あらかじめ安全だと分かっているものだけを受け入れる」という厳格なルールを作ることです。
例えば、ユーザーが選ぶ選択肢が「1」「2」「3」のどれかであるべきなら、それ以外の文字が入力されたらすべて弾くようにします。
<?php
// 許可する値のリスト（ホワイトリスト）をあらかじめ定義する
$allowed_actions = ['start', 'stop', 'restart'];
// ユーザーからの入力を受け取る
$user_input = $_POST['action'];
// 入力値がホワイトリストに含まれているか厳密にチェックする
if (!in_array($user_input, $allowed_actions, true)) {
// リストに含まれていない場合は、処理を中断してエラーにする
// （ここで「不正なアクセスです」と優しく教えてあげましょう）
die("エラー: 無効な操作が指定されました。");
}
// ホワイトリストを通過したものだけ安全に実行する
system("/usr/bin/service mysqld " . $user_input);
?>このように、「決まった文字以外は絶対に受け付けない」という強い意志を持つことが、Webアプリを守る最高の盾になります。
—
4. 人間による確認の限界：静的解析ツールにおまかせしよう！
「よし、気をつけてコードを書こう！」と思っても、人間はうっかりミスをしてしまう生き物です。何万行もあるコードの中から、たった1ヶ所の exec や system の切り忘れを見つけるのは至難の業ですよね。
そこで現場のプロたちは、「静的解析ツール（Linterやセキュリティスキャナー）」を導入しています。
これは、人間のおまわりさんのように、コードを書き終わった瞬間に「おいおい、ここは危険な関数が使われているよ！」と自動で赤ペンを入れてくれる便利なツールです。
例えば、チームの開発ルールとして、以下のようなルールを静的解析ツール（ESLintやPsalm、SonarQubeなど）に覚えさせておきます。
exec系関数やシェルを伴うメソッドを発見したら、ビルドを強制的に失敗（エラー）させる- 未検証の入力値がそのままコマンド組み立てに使われていないかを自動で検知する
こうした仕組みをCI/CD（自動テスト・デプロイのパイプライン）に組み込んでおけば、うっかりミスで脆弱なコードが本番サーバーに公開されてしまう悲劇を、機械がガッチリ防いでくれます。
—
まとめ：一歩ずつ、安全なコードを書けるエンジニアへ
今回は、OSコマンドインジェクションの恐ろしさと、その具体的な防御策についてお話ししました。
1. シェルを呼び出す危険な関数（execやos.systemなど）の利用を避ける
2. 安全な標準ライブラリやAPIを正しく使う
3. 入力値は「ホワイトリスト」で厳しくチェックする
4. 人間の目だけでなく、静的解析ツールを頼る
最初は覚えることが多くて大変に感じるかもしれませんが、一つひとつの対策はどれも理にかなっていてシンプルなものです。「どうすれば安全にデータを扱えるかな？」と、家の戸締まりを確認するような優しさを持ってコードに向き合えば、きっと素晴らしいセキュアな開発者になれますよ。
それでは、また次回のセキュリティ解説でお会いしましょう！一歩ずつ、確実にスキルアップしていきましょうね。
コメント