Webアプリケーションのセキュリティ
Webアプリケーション開発で考慮する必要のある、
広く知られた脆弱性とその検証方法を例示します。
注意
Webアプリケーションの脆弱性を解説するため、本サイトには攻撃手法に関する情報が含まれています。本サイトにて解説している攻撃手法を、他者が管理または運営しているWebアプリケーションやWebサーバーに対して実行すると、刑事罰および損害賠償請求の対象となる場合があります。脆弱性の調査・検証は、必ずご自身の管理下のコンピュータシステムに対してのみ実施してください。
本サイトの記事を参考にした行為により問題が生じても、当サイトは一切責任を負いません。
おすすめサイト
チェックポイント
- OS、Webサーバ、Webアプリケーションフレームワーク
- 入出力
- ユーザー認証
- セッション管理
- メール
- Webブラウザ
OS、Webアプリケーションフレームワーク
- 設定(インストール時)
- 運用(開発時、実運用開始時)
入出力
- クロスサイトスクリプティング(CSS,XSS)
- SQLインジェクション
- OSコマンドインジェクション
ユーザー認証
総当り攻撃(brute force attack)耐性
- 同一ユーザIDに対する連続ログイン試行に失敗した場合、アカウントをロックすること。
- アカウントロックの解除は、サイト管理者へのメールや電話での連絡を必須とするのが望ましいですが、シーケンシャルな文字列で構成されているといった理由で他人のユーザIDを容易に推測可能な場合、無差別に他人のユーザIDに対してログインを試みてアカウントをロックさせるといった、サイト運用妨害行為を助長する恐れがあります。
アカウントロック後、一定時間*1ログイン試行が行われなかった場合に自動解除する方式を採用することで、悪意のあるツールによるブルートフォース攻撃でアカウント情報を奪われる危険性を軽減しつつ、ユーザビリティを考慮したサイト運用が可能となります。
ただし、オンラインバンキングシステムやeコマースサイトといった、預貯金口座情報やクレジットカード情報を含む個人情報を取り扱うサイトでは自動解除方式を採用すべきではありません。
- What’s My Pass? » The Top 500 Worst Passwords of All Time
- よく使われる危険なパスワードトップ500 - GIGAZINE

日本のサイトの話ではないのですが、よく使われるパスワードワースト500だそうです。
公開をきっかけとして、ワースト500に含まれるパスワードを優先的に試行するブルートフォース攻撃が流行するかもしれません。
気休めにしか過ぎないかもしれませんが、上記サイトで紹介されている500個の脆弱なパスワードは登録できないようにしたほうが良いでしょう。
リバースブルートフォース攻撃耐性
- パスワードを固定してユーザIDを次々と変更してのログイン試行を防止する。
ユーザID
- 推奨:ユーザIDをシーケンシャルに生成しない。
- ユーザIDが連番になっていると、別ユーザのユーザIDを容易に推測可能なので、たとえばリバースブルートフォース攻撃によりアカウントを奪われる可能性が高まります。
- 参考:英大文字、英小文字、数字、記号のうち3種類以上を混在させることを強制する。
- システムが自動発行する場合はもちろん、任意のユーザIDを登録可能な場合でもこの仕様を適用するのが望ましいです。
- 参考:メールアドレスをそのままユーザIDとして使用しない。
- このような仕様のサイトは多いですが、セキュリティ上推奨できません。
パスワード
パスワード | セキュリティゆいがどくそん
にて情報随時更新中……
- 必須:パスワードを平文で保存しない。
- 言わずもがなですが。データベースへ保存する場合は必ずハッシュ化すること。万が一、SQLインジェクション脆弱性を突かれてユーザ情報が奪われた場合、パスワードまで流出すると被害が劇的に拡大します。セキュリティに強い関心のあるユーザでなければ、同じパスワードを複数のサイトで使いまわしている可能性が高いためです。
- 必須:英大文字、英小文字、数字、記号のうち3種類以上を混在させることを強制する。
- ユーザが任意に決める場合以外に、システムが自動発行する仮パスワードにもこの仕様の適用が必要です。
- 必須:8桁以上の桁数を強制する。
- 4桁のパスワードは論外です。長さが4桁で文字種が3種類以下なら、数分以内に破られてしまいます。
- 必須:ユーザIDと同一、もしくは一部にユーザIDが含まれるパスワードを禁止する。
- ユーザIDが含まれているパスワードはパスワードの意味がありません。
- 必須:メールアドレスやメールアカウントと同一、もしくは一部を含むパスワードを禁止する。
ユーザ管理
- FORM認証
- Basic認証
- Digest認証
- HTTP Authorization

セッション管理
HTTPによる通信はステートレス
(状態を持たない)です。
「ログイン中」や「登録情報更新中」といった状態をWebアプリケーションが認識するためには別の仕組みが必要です。
最も広く使われていると思われる仕組みがセッションID*2によるセッション管理です。
セッションIDの受け渡しには以下のような方式を用います。
- HTTP Cookieによる送受信
- フォームのhiddenフィールド
- URLリライティング(URLにセッションIDを付加)
セッション管理に関連する主な攻撃手法や脆弱性
参考サイト
Cookie
Cookieの取り扱いで注意すべき点
Cookie(クッキー)の届く範囲 (あいまいモード)
domain
有効期限
- 理想は「セッション限り」=有効期限設定なしですが、ユーザビリティに配慮して有効期限を設定する場合があるかと思います。
この場合、有効期限を必要以上に長く設定しないでください。
- Cookieの削除と有効期限
secure属性
httponly属性
メール
ユーザのメールアドレス管理
スパム踏み台化防止
Webブラウザ
脆弱性・攻撃手法
下記の一覧は、@IT:Webアプリケーションに潜むセキュリティホール(1):
より引用したものに加筆しています。
診断手法
OWASP
参考
Webアプリケーション
PHP
セキュア開発用ツール