IPA式ウェブアプリケーション脆弱性チェックリスト
先日書いた業務用アプリに関連するんですけど、うちの会社ではサービスをリリースする前に脆弱性監査を通す必要があります。会社の仕組みとしてそのような監査チームがあることが凄く助かっています。
さて、会社の脆弱性監査の内容は守秘義務等で書くことが一切できないのですが、IPA(独立行政法人 情報処理推進機構)にて脆弱性対策についてのまとめ資料が公開されています。
情報処理推進機構:情報セキュリティ:脆弱性対策:安全なウェブサイトの作り方
ココで公開されている 「安全なウェブサイトの作り方 改訂第3版」 は全76ページからなる脆弱性対策マニュアルになっていて、どのような脆弱性に対してどうのように対処すべきかが記載されています。この第3版は行ってみれば、脆弱対策2009年度版みたいなもん。新しい攻撃手法がどんどんでてくるのでその都度対策が必要なのですが、このマニュアル本に記載されている内容で、現在の対処はほぼほぼ十分だと感じています。
より活用されたら世の中のシステムがもっと安全になるのになぁ〜と思って、チェックリストだけ抜き出してウェブインタフェースで採点方式のチェックリストを作ってみました。
※このチェック項目の「対応済」のチェックは、実施項目のいずれかを実施した場合にチェックします。
No | 脆弱性の種類 | 対策の性質 | チェック | 実施項目 | 解説 |
1 | SQLインジェクション | 根本的解決 | ※ 対応済 未対応 対応不要 |
SQL文の組み立てにバインド機構を使用する | 1)-1 |
バインド機構を知用できない場合は、SQL文を構成する全ての変数に対しエスケープ処理を行う | 1)-2 | ||||
根本的解決 | 対応済 未対応 対応不要 |
ウェブアプリケーションに渡されるパラメータにSQL文を直接指定しない | 2) | ||
保険的対策 | 対応済 未対応 対応不要 |
エラーメッセージをそのままブラウザに表示しない | 3) | ||
保険的対策 | 対応済 未対応 対応不要 |
データベースアカウントに適切な権限を与える | 4) | ||
2 | OSコマンドインジェクション | 根本的解決 | ※ 対応済 未対応 対応不要 |
シェルを起動できる言語機能の利用を避ける | 1) |
保険的対策 | シェルを起動できる言語機能を利用する場合は、その引数を構成する全ての変数に対してチェックを行い、あらかじめ許可された処理のみが実行されるようにする | 2) | |||
3 | パス名パラメータの未チェック/ディレクトリトラバーサル | 根本的解決 | ※ 対応済 未対応 対応不要 |
外部からのパラメータにウェブサーバ内のファイル名を直接指定できる実装を避ける | 1)-1 |
ファイルを開く際は、固定のディレクトリを指定し、かつファイル名にディレクトリ名が含まれないようにする | 1)-2 | ||||
保険的対策 | 対応済 未対応 対応不要 |
ウェブサーバ内のファイルへのアクセス権限の設定を正しく管理する | 2) | ||
保険的対策 | 対応済 未対応 対応不要 |
ファイル名のチェックを行う | 3) | ||
4 | セッション管理の不備 | 根本的解決 | 対応済 未対応 対応不要 |
セッションIDを推測が困難なものにする | 1) |
根本的解決 | 対応済 未対応 対応不要 |
セッションIDをURLパラメータに格納しないようにする | 2) | ||
根本的解決 | 対応済 未対応 対応不要 |
HTTPS通信で利用するCookieにはSecure属性を加える | 3) | ||
根本的解決 | ※ 対応済 未対応 対応不要 |
ログイン成功後に、新しくセッションを開始するようにする | 4)-1 | ||
ログイン成功後に、既存のセッションIDとは別に秘密情報を発行し、ページの遷移毎にその値を確認する | 4)-2 | ||||
保険的対策 | 対応済 未対応 対応不要 |
セッションIDを固定値にしない | 5) | ||
保険的対策 | 対応済 未対応 対応不要 |
セッションIDをCookieにセットする場合、有効期限の設定に注意する | 6) | ||
5 | クロスサイトスクリプティング(HTMLテキストの入力を許可しない場合の対策) | 根本的解決 | 対応済 未対応 対応不要 |
ウェブページに出力する全ての要素に対してエスケープ処理を施す | 1) |
根本的解決 | 対応済 未対応 対応不要 |
URLを出力するときは、「http://」や「https://」で始まるURLのみを許可するようにする | 2) | ||
根本的解決 | 対応済 未対応 対応不要 |
<script>…</script>要素の内容を動的に生成しないようにする | 3) | ||
根本的解決 | 対応済 未対応 対応不要 |
スタイルシートを外部サイトから取り込めるようにしない | 4) | ||
保険的対策 | 対応済 未対応 対応不要 |
入力値の内容チェックを行う | 5) | ||
クロスサイトスクリプティング(HTMLテキストの入力を許可する場合の対策) | 根本的解決 | 対応済 未対応 対応不要 |
入力されたHTMLテキストから構文解析木を作成し、スクリプトを含まない必要な要素のみを抽出する | 6) | |
保険的対策 | 対応済 未対応 対応不要 |
入力されたHTMLテキストから、スクリプトに該当する文字列を排除する | 7) | ||
クロスサイトスクリプティング(全てのウェブアプリケーションに共通の対策) | 根本的解決 | 対応済 未対応 対応不要 |
HTTPレスポンスヘッダのContent-Typeフィールドに文字コード(charset)の指定を行う | 8) | |
保険的対策 | 対応済 未対応 対応不要 |
Cookie情報の漏洩対策として、Traceメソッドを無効化し、発行するCookieにHttpOnly属性を加える | 9) | ||
6 | CSRF(クロスサイトリクエストフォージェリ) | 根本的解決 | ※ 対応済 未対応 対応不要 |
処理を実行するページをPOSTメソッドでアクセスするようにし、そのhiddenパラメータに秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行するようにする | 1)-1 |
処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、入力されたパスワードが正しい場合のみ処理を実行するようにする | 1)-2 | ||||
Refarerが正しいリンク元かを確認し、正しい場合のみ処理を実行するようにする | 1)-2 | ||||
保険的対策 | 対応済 未対応 対応不要 |
重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する | 2) | ||
7 | HTTPヘッダインジェクション | 根本的解決 | ※ 対応済 未対応 対応不要 |
ヘッダの出力を直接行わず、ウェブアプリケーションの実行環境や言語に用意されているヘッダ出力API用を使用する | 1)-1 |
改行コードを適切に処理するヘッダ出力用APIを利用できない場合は、改行を許可しないよう、開発者自身で適切な処理を実装する | 1)-2 | ||||
保険的対策 | 対応済 未対応 対応不要 |
外部からの入力の全てについて、改行コードを削除する | 2) | ||
8 | メールの第三者中継 | 根本的解決 | ※ 対応済 未対応 対応不要 |
外部からのパラメータをメールヘッダの内容に指定しない | 1) |
保険的対策 | 外部からのパラメータをメールヘッダに指定する場合は、危険な文字を排除する | 2) | |||
9 | アクセス制御や認可制御の欠落 | 根本的解決 | 対応済 未対応 対応不要 |
アクセス制御機能による防御措置が必要とされるウェブサイトには、パスワードなどの秘密情報の入力を必要とする認証機能を設ける | 1) |
根本的解決 | 対応済 未対応 対応不要 |
認証機能に加えて認可制御の処理を実装し、ログイン中の利用者が他人になりすましてアクセスできないようにする | 2) | ||
※このチェック項目の「対応済」のチェックは、実施項目のいずれかを実施した場合にチェックします。 | |||||
対応済・対応不要:3点、未対応:0点 で換算 | 合計点数 点(90点満点) |
どうでしょう、あなたが作っているシステムは何点がとれましたか?
もし知らない脆弱性や未対策のものがあったら、どうぞ 「安全なウェブサイトの作り方 改訂第3版」 をご覧になって対策ください。より自信を持って安全なサイトと言える等になるかと思います。w
コメントやシェアをお願いします!