Top > Web Application
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が含まれているパスワードはパスワードの意味がありません。
  • 必須：メールアドレスやメールアカウントと同一、もしくは一部を含むパスワードを禁止する。
    • ここでのメールアカウントとは、メールアドレスがsample@example.comの場合、”@”より前の部分のsampleのことです。

ユーザ管理

  • 一般ユーザ、管理者権限制御
  1. FORM認証
  2. Basic認証
  3. Digest認証
  4. HTTP Authorization
 

セッション管理

HTTPによる通信はステートレス（状態を持たない）です。
「ログイン中」や「登録情報更新中」といった状態をWebアプリケーションが認識するためには別の仕組みが必要です。
最も広く使われていると思われる仕組みがセッションID*2によるセッション管理です。
セッションIDの受け渡しには以下のような方式を用います。

  1. HTTP Cookieによる送受信
  2. フォームのhiddenフィールド
  3. URLリライティング（URLにセッションIDを付加）

セッション管理に関連する主な攻撃手法や脆弱性

参考サイト

 

Cookie

Cookieの取り扱いで注意すべき点 Cookie(クッキー)の届く範囲 (あいまいモード)

domain

有効期限

secure属性

httponly属性

メール

ユーザのメールアドレス管理

スパム踏み台化防止

 

Webブラウザ

 

脆弱性・攻撃手法

下記の一覧は、＠IT：Webアプリケーションに潜むセキュリティホール（1）:より引用したものに加筆しています。

 

診断手法

OWASP

 

参考

Webアプリケーション

PHP

セキュア開発用ツール
*1 5～15分程度
*2 せっしょんあいでぃー：セッションを管理するために使用する識別子
リロード   凍結解除 差分 コピー 名前変更   ホーム 一覧 検索 最終更新 バックアップ リンク元   ヘルプ   最終更新のRSS
Last-modified: Tue, 02 Sep 2014 14:10:16 JST (1326d)