徳丸本ではたくさんの脆弱性について解説されていますが、覚えきれないので自分用に簡潔にまとめます。
こんな脆弱性もあったなと思い出す用です。
詳しい解説は体系的に学ぶ安全なWebアプリケーションの作り方 第2版をご覧ください。
まとめかた
・特徴
・発生箇所
・対策方法
XSS - クロスサイトスクリプティング
ユーザーのブラウザなどで不正なスクリプトが実行されてしまう脆弱性です。クッキー値の読み出しによる成りすましや偽のフォームの表示などができてしまいます。
発生箇所
- URLやフォームなどのユーザーが入力可能な部分を扱う、HTMLの属性値、要素など
対策
- HTML の文法で特別な意味を持つ特殊記号( < > & ” ’ /)を適切にエスケープ処理する
- クッキーにHttpOnly属性を付与する
- 詳細なエラーログを利用者向けに出力しない
下二つは保険的な対策なので、適切なエスケープ処理が重要です。
SQLインジェクション
不正なSQL呼び出しが行われて情報漏洩や改ざんの原因となり、非常に危険な脆弱性です。
発生箇所
- SQL呼び出しにユーザーからの入力値を用いている箇所
対策
- プレースホルダを使用してSQL文を組み立てる
CSRF - クロスサイト・リクエストフォージェリ
被害者の権限で「重要な処理」を実行されてしまう脆弱性です。重要な処理には、メールアドレスやパスワードの変更、物品の購入、サイトへの書き込みなどが挙げられます。
発生箇所
- 重要な処理が行われるページ
対策
CSRF対策は全てのページに実施するものではないので、必要となるページを選定する必要があります。
正規利用者の意図したリクエストかどうかを確認することが対策となります。
確認方法
- 実行ページの直前のページにトークンを埋め込み、セッション変数に保存したトークンと一致するか確認する
- 重要な処理の前にパスワードを再入力させる
- Refererに実行ページの直前のページのURLがセットされていることを確認する
クリックジャッキング
攻撃先ページを表示させたiframe要素をCSSで透明化させることによって、利用者に意図しない「重要な処理」を実行させる攻撃手法です。
発生箇所
- 重要な処理が行われるページ
対策方法
- レスポンスヘッダに X-Frame-Options: SAMEORIGIN を付与する
上記の対策により、異なるオリジンでiframeとして読み込まれるのを防ぐことができます。
セッションハイジャック
セッションIDを悪用して成り済ます攻撃方法です。
セッションIDを知るための手段は以下の三種類があります。
- セッションIDの推測
- セッションIDの盗み出し
- セッションIDの強制
セッションIDに関する脆弱性をそれぞれまとめていきます。
推測されやすいセッションID
セッションIDの生成方法に問題があると、簡単に推測されてしまう危険性があります。
発生箇所
- セッションIDの生成箇所
対策
- セッション管理機構を自作しない
安全なセッション管理機構を自作するのは難易度が高いため、言語やフレームワークに備えられた方法で管理するのが安全です。
URL埋め込みのセッションID
URLにセッションIDを埋め込んでいると、RefererからセッションIDが外部に流出する恐れがあります。
また、利用者がセッションID付きのURLをSNSなどに投稿する危険性もあります。
発生箇所
- URLにセッションIDを埋め込んであり、外部サイトへのリンクがある（生成できる）アプリケーション
対策
- セッションIDをURLに埋め込まず、クッキーに保存する
セッションIDの固定化
攻撃者が入手したセッションIDを被害者に強制させることができてしまう脆弱性です。
発生箇所
- ログイン処理を行う箇所
対策
- 認証後にセッションIDを変更する
- ログイン時にトークンを生成し、クッキーとセッション変数に記憶させて比較する
オープンリダイレクト
任意のドメインにリダイレクトさせることができてしまう脆弱性です。フィッシングに悪用される可能性があります。
発生箇所
- リダイレクト先のURLを外部から指定できる場所
対策
- リダイレクト先のURLを固定にする
- リダイレクト先のURLを直接指定にせず番号指定にする
- リダイレクト先のドメイン名をチェックする
リダイレクト先のドメインを固定化するか制限することで罠ページへの誘導を防ぐことができます。
HTTPヘッダ・インジェクション
任意のレスポンスヘッダを生成できてしまう脆弱性です。
発生箇所
- 外部からのパラメータを使ってレスポンスヘッダを出力している箇所
対策
- 外部からのパラメータをレスポンスヘッダとして出力しない
- リダイレクトやクッキー出力に専用APIを用いる
- パラメータの改行文字をチェックする
改行がレスポンスヘッダとしてそのまま出力されるのが脆弱性の原因なので、改行をチェックすることで脆弱性への対策となります。
クッキーのセキュア属性不備
クッキーにセキュア属性を適切に付与していない脆弱性です。HTTPS通信を利用していても、盗聴の恐れがあります。
発生箇所
- クッキーを発行している箇所
対策
- クッキーにSecure属性を付与する
- セッションの固定化対策と同じ方法でトークンを管理し、セッションハイジャックを防ぐ
メールヘッダ・インジェクション
宛先や件名などのメールヘッダを外部から指定する際に、件名や送信元、本文などを改変されてしまう脆弱性です。
発生箇所
- メール送信機能のあるページ
対策
- sendmailコマンドなどではなく、専用のAPIやライブラリを用いる
- 外部からのパラメータをメールヘッダに含ませない
- パラメータの改行をチェックする
改行によって新たなヘッダや本文が挿入されることが脆弱性の原因なので、改行をチェックすることによって対策になります。
ディレクトリ・トラバーサル
アプリケーションの意図しないファイルが改ざんされたり閲覧されてしまう脆弱性です。
発生箇所
- ファイル名を外部から指定できるページ
対策
- 外部からファイル名を指定できる仕様を避ける
- ファイル名にディレクトリ名が含まれないようにする
- ファイル名を英数字に限定する
ディレクトリ名を指定させなければ、想定したファイルにのみアクセスさせることができます。
意図しないファイル公開
外部から閲覧されてはいけないファイルの中身が漏洩してしまう脆弱性です。
ファイルが公開ディレクトリに置かれており、URLを知る手段があるとファイルの内容を誰でも見ることができてしまいます。
発生箇所
- Webサイト全体
対策
- ファイルの安全な格納場所を決める
- 非公開ディレクトリを使用する
OSコマンド・インジェクション
攻撃者によって開発者の意図しないOSコマンドが実行されてしまう脆弱性です。OSの脆弱性を突かれて、攻撃者が管理者権限を得てしまい、サーバーを悪用されてしまうなど非常に危険性の高い脆弱性です。
発生箇所
- シェルを呼び出す関数を用いている箇所
対策
- OSコマンド呼び出しを使わない実装方法を選択する
- シェル呼び出し機能のある関数を避ける
- 外部から入力された文字列をコマンドラインのパラメータに渡さない
- パラメータを安全な関数を用いてエスケープする
シェルによって複数のコマンドを実行できてしまうことが脆弱性の原因なので、シェルを経由しない関数を用いることによって対策になります。
やむを得ずシェル経由でOSコマンドを呼び出す必要があるときは、適切にエスケープ処理を行う必要がありますが、自作するのは難易度が高いため専用の関数を用います。
アップロードファイルによるサーバー側スクリプト実行
攻撃者がアップロードしたスクリプトがサーバーで実行されてしまう脆弱性です。OSコマンド・インジェクションと同様に非常に危険です。
発生箇所
- ファイルのアップロード機能のあるページ
対策
- ファイルを公開ディレクトに保存せず、スクリプト経由でダウンロードできるようにする
- スクリプトとして実行可能な拡張子を利用者に指定させない
ファイルダウンロードによるXSS
PDFファイルなどに仕込まれたHTMLやJavaScriptがスクリプトが実行されてしまう脆弱性です。
発生箇所
- ファイルのアップロード・ダウンロード機能
対策
-
アップロード時
- ファイルの拡張子をチェックする
-
ダウンロード時
- Content-Typeを正しく設定する
- レスポンスヘッダ X-Content-Type-Options: nosniff を設定する
ファイルダウンロードによるXSSはContent-Typeの間違った指定が原因です。IEはContent-Typeの解釈が曖昧ですが、X-Content-Type-Options: nosniff を設定することでContent-Typeヘッダのみから解釈するように強制できます。
PDFのFormCalcによるコンテンツハイジャック
PDFに埋め込まれたFormCalcスプリクトを用いて、成りすましを行う攻撃方法です。
発生箇所
- 利用者がアップロードしたPDFファイルをダウンロードできる機能
対策
- PDFファイルはブラウザで開かずダウンロードを強制する
- X-Download-Options: noopen を設定してファイルを開かせない
- ファイルダウンロードをPOSTリクエストに限定する
ファイルインクルード
スクリプトのソースの一部を別ファイルから読み込む機能で、アプリケーションの意図しないファイルを指定できてしまう脆弱性です。Webサーバー内のファイルの漏洩や改ざんの危険性があります。
発生箇所
- インクルードするファイルを外部から指定できる箇所
対策
- 外部からファイル名を指定させない
- ファイル名を英数字に限定する
evalインジェクション
ソースコードを解釈実行するevalに相当する関数に外部からのスプリクトを指定できてしまう脆弱性です。OSコマンド・インジェクションと同様の危険性があります。
発生箇所
- evalに相当する関数や機能で外部からのパラメータを受け取っている箇所
対策
- evalを使わない
- evalに外部からのパラメータを指定しない
- evalに与えるパラメータを英数字に限定する
evalを用いずに同様の機能を実装できる場合が多いため、evalを使わない選択をするべきです。
安全でないデシリアライゼーション
不適切なデシリアライゼーションによって、意図しないコードが実行されてしまう脆弱性です。
デシリアライズとは、シリアライズによってバイト列に変換されたデータをもとの状態に戻すことです。
発生箇所
- 外部からのパラメータをデシリアライズしている箇所
対策
- JSONを使う
XXE - XML外部実体参照
XMLにある外部実体参照という外部ファイルの内容を取り込むことのできる機能を用いて、サーバー内のファイルなどを不正に読み取られてしまう脆弱性です。
発生箇所
- XMLを外部から受け取っているページ
対策
- XMLの代わりにJSONを用いる
- 外部実体参照を禁止する
JSONをかわりに用いれば言語にかかわらずXXEの対策ができます。
競合状態の脆弱性
共有資源に対する排他制御が不十分だと、別人の個人情報が表示されるなどの問題が起こることがあります。
発生箇所
- 共有資源を利用している箇所
対策
- 可能であれば共有資源を使用しない
- 共有資源に対して排他制御を行う
排他処理によって長い待ち時間が発生する可能性があるので、なるべく共有資源は使用せず、やむおえない時はできるだけ時間を短くする必要があります。
キャッシュからの情報漏洩
キャッシュが原因で個人情報が漏洩するリスクがあります。
発生箇所
- キャッシュを利用している秘密情報を表示している箇所
対策
- 認証が必要な情報やユーザー毎に表示内容が異なる個人情報をキャッシュしない
キャッシュサーバーやレスポンスヘッダの設定を適切に行う必要があります。
JSONエスケープの不備
APIにおいてJSON生成時のエスケープ処理に問題があると、意図しないJavaScriptが混入する危険性があります。
発生箇所
- JSONやJSONPを出力するAPI
対策
- 信頼できるライブラリを用いてJSONを生成する
- evalなどではなく、安全なAPIを用いてJSONを解釈する
適切なエスケープ処理を施してJSONを生成する必要があります。
JSON直接閲覧によるXSS
JSONを返すAPIがブラウザで直接閲覧されることによって攻撃可能になる場合があります。
発生箇所
- JSONを生成するAPI
対策
- MINEタイプを正しく設定する(application/json)
- レスポンスヘッダ X-Content-Type-Options: nosniff を設定する
MINEタイプがtext/htmlとなってしまっている場合、JavaScriptが実行されてしまいます。正しくapplication/jsonに設定することによって対策できます。
JSONPのコールバック関数名によるXSS
JSONPのコールバック関数の名前を外部から指定できる場合に生じる脆弱性です。
発生箇所
- JSONPを生成しているAPI
対策
- コールバック関数名を検証する
- MINEタイプを正しく設定する
コールバック関数名に、英数字とアンダースコアのみを使用できるようにすることによってscript要素が紛れ込むのを防ぎます。また、MINEタイプにtext/javascriptを指定すればscript要素は解釈されません。
JSONハイジャック
JSONは通常script要素で受け取ることはできませんが、何らかの方法受け取ることができないかが研究されており、その方法がJSONハイジャックです。
発生箇所
- JSONを出力するAPIで秘密情報を提供しているもの
対策
- X-Content-Type-Options: nosniffを付与する
- X-Requested-With: XMLHttpRequtを確認する
X-Content-Type-Options: nosniffを付与してMINEタイプを厳格にチェックすることによって、script要素でのJSON読み込みを拒否できます。
JSONPの不適切な利用
JSONPは使い方を間違えると簡単に脆弱性に直結してしまいます。
発生箇所
- JSONPを使用している箇所
対策
- JSONPをやめてCORS + JSONに移行する
DOM Based XSS
JavaScriptによる処理の不備が原因のXSSです。
発生箇所
- JavaScriptによりDOMに関わるメソッドを呼び出している箇所
対策
- DOM操作の際にHTMLタグが有効になってしまう機能を使わない
- eval、setTimeoutなどの引数に文字列形式で外部から値を渡さない
- JQueryの$()の引数を動的生成しない
- 適切にエスケープ処理をする
HTMLタグが有効になる関数は、テキスト挿入などで代用することによって対策になります。