【メモ】Webアプリで押さえるべき代表的な脆弱性
はじめに
セキュリティ技術入門でWeb脆弱性を扱うのは、攻撃手法を面白く学ぶためではありません。
入力、出力、権限、ファイル、通信といった実装上の弱点が、どう業務リスクになるかを理解するためです。1
この章では、代表的な脆弱性を「何が危険か」「なぜ起きるか」「どう守るか」の3点で整理します。
なぜ脆弱性の名前だけでは足りないのか
SQLインジェクション、XSS、CSRFのような名前は有名ですが、名前を知っているだけでは守れません。
重要なのは、どの脆弱性も次のどこかで起きるという理解です。
- 入力を信じすぎる
- 出力の扱いが雑である
- ユーザの操作意図を確認していない
- ファイルやパスの扱いが曖昧である
- OSや外部コマンドへの橋渡しが危険である
SQLインジェクション
何が危険か
入力値がデータとしてではなく、SQL文の一部として解釈されると、本来想定しない検索、更新、削除が起きる可能性があります。1
なぜ起きるか
文字列連結でクエリを組み立てる、入力をそのまま埋め込む、といった設計が典型です。
どう守るか
- プレースホルダやパラメタライズドクエリを使う
- 入力値の型や形式を検証する
- DB権限を必要最小限にする
XSS
何が危険か
画面に表示する値を安全に扱わないと、意図しないスクリプト実行や、利用者のブラウザ上での不正動作につながることがあります。1
なぜ起きるか
ユーザ入力や外部データを、そのままHTMLやスクリプト文脈へ出してしまうからです。
どう守るか
- 出力時に文脈に応じたエスケープを行う
- 危険なHTML挿入を安易に使わない
- 入力値検証だけに頼らない
CSRF
何が危険か
利用者が意図していない状態変更を、別の画面やサイトを経由して実行される可能性があります。
なぜ起きるか
ログイン済みセッションがあるだけで重要操作を受け付けると、利用者本人の意思確認が弱くなります。
どう守るか
- 状態変更操作にCSRF対策を入れる
- 重要操作で再確認や再認証を検討する
- セッション管理を適切に行う
パストラバーサル
何が危険か
ファイルパスの指定を適切に制御しないと、本来見せるべきでないファイルやディレクトリへ到達される可能性があります。
なぜ起きるか
ユーザが指定したパスやファイル名を、そのまま信じて処理してしまうためです。
どう守るか
- 許可した場所、形式、名前だけを扱う
- パスを直接組み立てない
- アプリ実行権限とファイル権限を最小化する
OSコマンドインジェクション
何が危険か
アプリがOSコマンド実行を仲介しているとき、入力処理が弱いと、想定外のコマンド実行につながる可能性があります。
なぜ起きるか
入力文字列をコマンドへそのまま渡したり、コマンド組み立てを文字列連結で行ったりするからです。
どう守るか
- そもそもOSコマンド呼び出しを避けられないか検討する
- APIやライブラリで代替できるならそちらを使う
- 引数を安全に扱い、入力を厳格に制限する
ファイルアップロード不備
何が危険か
危険な形式のファイル、巨大なファイル、意図しない実行可能ファイルを受け入れると、保存領域の汚染や不正実行、サービス障害の原因になります。
なぜ起きるか
拡張子やファイル名だけで判断する、保存場所を安易に決める、公開領域へそのまま置く、といった設計が原因になります。
どう守るか
- 受け入れる形式とサイズを制限する
- 保存場所、公開方法、実行権限を分離する
- ファイル名やパスをそのまま信じない
認可不備もWeb脆弱性の中心にある
典型脆弱性の一覧では、入力系の脆弱性に注目が集まりがちです。
しかし実務では、「ログインしている別ユーザのデータが見える」「管理者機能へ入れる」のような認可不備も重大です。1
この論点は次章で詳しく扱いますが、Webの安全性は入力処理だけでは決まりません。
起こしやすい誤り
フレームワークが守ってくれると思い込む
フレームワークは助けになりますが、使い方を誤れば防げません。
危険なAPIや設定を選べば、保護は簡単に外れます。
入力チェックだけで十分だと思う
出力エスケープ、認可チェック、権限分離、保存先設計など、複数の層で防御が必要です。
単語暗記で終わる
脆弱性名を覚えても、どの処理で起きるかを理解していなければ、コードレビューや設計時に気付きにくくなります。
ミニ確認
- SQLインジェクションが起きる典型原因は何か
- XSSで重要なのは、入力時と出力時のどちらか
- CSRF対策で考えるべきのは、利用者の何か
- ファイルアップロード不備では、形式以外に何を考えるべきか