Top > Web Application

#norelated
TITLE:Webアプリケーションのセキュリティ

----
CENTER:&color(Blue){&size(18){''Webアプリケーションのセキュリティ''};};&new(Web Application,nolink);~
~
CENTER:&size(14){''Webアプリケーション開発で考慮する必要のある、&br;広く知られた脆弱性とその検証方法を例示します。''};
----

*''注意'' [#t2c13120]
>>''Webアプリケーションの脆弱性を解説するため、本サイトには攻撃手法に関する情報が含まれています。本サイトにて解説している攻撃手法を、他者が管理または運営しているWebアプリケーションやWebサーバーに対して実行すると、刑事罰および損害賠償請求の対象となる場合があります。脆弱性の調査・検証は、必ずご自身の管理下のコンピュータシステムに対してのみ実施してください。''~
''本サイトの記事を参考にした行為により問題が生じても、当サイトは一切責任を負いません。''
----
#htmlinsert(amazon.itemlink)
----
//**目次 [#m5f41138]
//#contents
*おすすめサイト [#m97effe6]
-[[初心者Webアプリケーション開発者がチェックすべき情報源2014 - ハニーポッターの部屋>http://d.hatena.ne.jp/connect24h/20140712]]
-[[初心者Webアプリケーション開発者がチェックすべき情報源2013>http://d.hatena.ne.jp/connect24h/20130705]]
*チェックポイント [#le26f5c2]
-OS、Webサーバ、Webアプリケーションフレームワーク
-入出力
-ユーザー認証
-セッション管理
-メール
-Webブラウザ
**OS、Webアプリケーションフレームワーク [#m661e23b]
-設定(インストール時)
-運用(開発時、実運用開始時)

**入出力 [#ac4d5065]
-クロスサイトスクリプティング(CSS,XSS)
-SQLインジェクション
-OSコマンドインジェクション

**ユーザー認証 [#y9a54acb]
***総当り攻撃(brute force attack)耐性 [#hd2400ae]
-同一ユーザIDに対する連続ログイン試行に失敗した場合、アカウントをロックすること。
--アカウントロックの解除は、サイト管理者へのメールや電話での連絡を必須とするのが望ましいですが、シーケンシャルな文字列で構成されているといった理由で他人のユーザIDを容易に推測可能な場合、無差別に他人のユーザIDに対してログインを試みてアカウントをロックさせるといった、サイト運用妨害行為を助長する恐れがあります。~
アカウントロック後、一定時間((5~15分程度))ログイン試行が行われなかった場合に自動解除する方式を採用することで、悪意のあるツールによるブルートフォース攻撃でアカウント情報を奪われる危険性を軽減しつつ、ユーザビリティを考慮したサイト運用が可能となります。~
''&color(red){ただし、オンラインバンキングシステムやeコマースサイトといった、預貯金口座情報やクレジットカード情報を含む個人情報を取り扱うサイトでは自動解除方式を採用すべきではありません。};''
-[[What’s My Pass? » The Top 500 Worst Passwords of All Time>http://www.whatsmypass.com/?p=415]]
--[[よく使われる危険なパスワードトップ500 - GIGAZINE>http://gigazine.net/index.php?/news/comments/20090105_bad_password/]]~
日本のサイトの話ではないのですが、よく使われるパスワードワースト500だそうです。~
公開をきっかけとして、ワースト500に含まれるパスワードを優先的に試行するブルートフォース攻撃が流行するかもしれません。~
気休めにしか過ぎないかもしれませんが、上記サイトで紹介されている500個の脆弱なパスワードは登録できないようにしたほうが良いでしょう。
***リバースブルートフォース攻撃耐性 [#fbeba687]
-パスワードを固定してユーザIDを次々と変更してのログイン試行を防止する。
***ユーザID [#b7ead11b]
-&color(blue){''推奨:ユーザIDをシーケンシャルに生成しない。''};
--ユーザIDが連番になっていると、別ユーザのユーザIDを容易に推測可能なので、たとえばリバースブルートフォース攻撃によりアカウントを奪われる可能性が高まります。
-&color(green){''参考:英大文字、英小文字、数字、記号のうち3種類以上を混在させることを強制する。''};
--システムが自動発行する場合はもちろん、任意のユーザIDを登録可能な場合でもこの仕様を適用するのが望ましいです。
-&color(green){''参考:メールアドレスをそのままユーザIDとして使用しない。''};
--このような仕様のサイトは多いですが、セキュリティ上推奨できません。
***パスワード [#g5fb42ce]

''[[パスワード | セキュリティゆいがどくそん>http://security.c-inf.com/blog/requirements-for-security/password/]]にて情報随時更新中……''
-[[第1回 もう覚えるのやめませんか? 安心なパスワード管理の方法について聞いてみた(1/3) | 日立ソリューションズの情報セキュリティブログ>http://securityblog.jp/tsuji_guards/page01.html]]
-[[セキュリティのトビラ (13) だれでも今すぐにできるパスワード管理術 | マイナビニュース>http://news.mynavi.jp/column/secdoor/013/]]
-[[セキュリティ・ダークナイト(17):See new world――振り返るとセキュリティ・ダークナイトはいるよ(前編) (1/3) - @IT>http://www.atmarkit.co.jp/ait/articles/1403/28/news014.html]]
--[[ソフトバンク・テクノロジー株式会社>http://www.softbanktech.co.jp/corp/]]の辻伸弘氏による連載です。

-[[いまさら聞けないパスワードの取り扱い方>http://www.slideshare.net/ockeghem/ss-25447896]]
--[[OWASP Japan 7th Chapter Meeting>https://www.owasp.org/index.php/Japan#2013.2F8.2F21_OWASP_Meeting_-_7th_Local_Chapter_Meeting]]における[[HASHコンサルティング株式会社>https://www.hash-c.co.jp/]]の徳丸浩氏によるプレゼンテーション資料です。

-[[パスワードの定期的変更について徳丸さんに聞いてみた(1) | 徳丸浩の日記>http://blog.tokumaru.org/2013/08/1.html]]
--大規模な個人情報漏洩事件のたびに話題になる「パスワードの定期変更」について記事です。

-[[あなたのパスワード、バレてます>http://wired.jp/2013/07/13/hacked-vol8/]]
--自身が管理している様々なアカウントがハックされた方による、パスワードについての考察記事です。


-&color(red){''必須:パスワードを平文で保存しない。''};
--言わずもがなですが。データベースへ保存する場合は必ずハッシュ化すること。万が一、SQLインジェクション脆弱性を突かれてユーザ情報が奪われた場合、パスワードまで流出すると被害が劇的に拡大します。セキュリティに強い関心のあるユーザでなければ、同じパスワードを複数のサイトで使いまわしている可能性が高いためです。
-&color(red){''必須:英大文字、英小文字、数字、記号のうち3種類以上を混在させることを強制する。''};
--ユーザが任意に決める場合以外に、システムが自動発行する仮パスワードにもこの仕様の適用が必要です。
-&color(red){''必須:8桁以上の桁数を強制する。''};
--4桁のパスワードは論外です。長さが4桁で文字種が3種類以下なら、数分以内に破られてしまいます。
-&color(red){''必須:ユーザIDと同一、もしくは一部にユーザIDが含まれるパスワードを禁止する。''};
--ユーザIDが含まれているパスワードはパスワードの意味がありません。
-&color(red){''必須:メールアドレスやメールアカウントと同一、もしくは一部を含むパスワードを禁止する。''};
--ここでのメールアカウントとは、メールアドレスがsample@example.comの場合、”@”より前の部分のsampleのことです。
//-&color(blue){''推奨:パスワードに有効期限を設定する。''};
//--同一パスワードを長期間使用させないために必要です。
//-&color(blue){''推奨:旧パスワードへの変更禁止期間を設定する。''};
//--パスワードの変更を強制しても、旧パスワードへの変更禁止期間を設けていないと、仮のパスワードに変更した直後に旧パスワードに戻され、結局同一パスワードを長期間使用することと同じになるためです。
//-&color(blue){''推奨:パスワードの変更履歴を管理する。''};
//--少なくとも3世代分は記録します。記録に残っているパスワードへの変更を禁止します。

//-パスワード変更画面
//--一般に、パスワード変更画面においては、現在使用しているパスワードの入力が必要となっています。~
//パスワード変更画面はログインしなければ表示できないように制御されているはずですが、仮にクロスサイトリクエストフォージェリ脆弱性が存在する場合、アカウントロック機能が実装されていないとクライアント側のスクリプトによるブルートフォース攻撃を受ける可能性があります。

//[[パスワードの強度およびパスワードのセキュリティ - マイクロソフト セキュリティ>https://www.microsoft.com/japan/protect/yourself/password/create.mspx]]
***ユーザ管理 [#abb37223]
-一般ユーザ、管理者権限制御
+FORM認証
+Basic認証
+Digest認証
+[[HTTP Authorization>http://www.studyinghttp.net/auth]]

#br

**セッション管理 &new(nodate){2009-02-04 00:53:00};[#fdf435df]
>HTTPによる通信は[[ステートレス>http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000849.html]](状態を持たない)です。~
「ログイン中」や「登録情報更新中」といった状態をWebアプリケーションが認識するためには別の仕組みが必要です。~
最も広く使われていると思われる仕組みがセッションID((せっしょんあいでぃー:セッションを管理するために使用する識別子))によるセッション管理です。~
セッションIDの受け渡しには以下のような方式を用います。
+HTTP Cookieによる送受信
+フォームのhiddenフィールド
+URLリライティング(URLにセッションIDを付加)

-
//>上記のセッションIDの受け渡し方法にはそれぞれ長所・短所があります。
//+HTTP Cookieによる送受信
//--メリット
//---比較的手軽にセッションIDの管理が可能。
//---SSL((Secure Socket Layer))とCookieへの"secure"オプション付加によるセッションIDの暗号化が可能。~
//→標準化されているので実装への負担が比較的軽い。
//--デメリット
//---Cookie非対応のWebブラウザが存在するので、必ずCookieでセッション管理出来るとは限らない。
//+フォームのhiddenフィールド
//+URLリライティング(URLにセッションIDを付加)

***セッション管理に関連する主な攻撃手法や脆弱性 [#d39b6527]
-[[セッション乗っ取り>Session Hijacking/Replay]] (Session Hijacking/Replay)
-[[セッション固定化>Session Fixation]] (Session Fixation)
-クロスサイトリクエストフォージェリ(&new(Cross Site Request Forgeries);)
***参考サイト [#ka52d292]
-[[これだけは知っておきたいセッション変数の基礎 - @IT>http://www.atmarkit.co.jp/fsecurity/rensai/httpbasic08/httpbasic01.html]]
-[[6. Webアプリケーションのセキュア化における留意点→6.4.1 セッション管理>http://www.ipa.go.jp/security/awareness/administrator/secure-web/chap6/6_session-1.html]]
-[[PHPで安全なセッション管理を実現する方法 - いしなお! (2006-08-25)>http://tdiary.ishinao.net/20060825.html#p02]]

#br
**Cookie [#y83d9f01]
Cookieの取り扱いで注意すべき点
[[Cookie(クッキー)の届く範囲 (あいまいモード)>http://www.imymode.com/exp/cookie.html]]

***domain [#q7158239]
-[[CookieのDomain属性は *指定しない* が一番安全 | 徳丸浩の日記>http://blog.tokumaru.org/2011/10/cookiedomain.html]]

***有効期限 [#je0f0b9a]
-理想は「セッション限り」=有効期限設定なしですが、ユーザビリティに配慮して有効期限を設定する場合があるかと思います。~
この場合、有効期限を必要以上に長く設定しないでください。
-Cookieの削除と有効期限
--[[PHPのsetcookie関数で空文字列を設定しようとするとクッキーが削除される | 徳丸浩の日記>http://blog.tokumaru.org/2013/10/phpsetcookie.html]]

***secure属性 [#m9d1b360]

***httponly属性 [#j587fa23]
-[[httponlyは普及するのか - T.Teradaの日記>http://d.hatena.ne.jp/teracc/20061226/1167161564]]
-[[Cookie - httponly 覚え書き - まじめにゆいがどくそん>http://nilfigo.hatenablog.com/entry/20081117/1226918278]]
#br
**メール [#q84e66fa]
***ユーザのメールアドレス管理 [#f22b9ed1]
***スパム踏み台化防止 [#fce86478]

#br

**Webブラウザ &new(nodate){2009-02-07 03:37:00};[#od9d0f8c]
-[[Web Application Security depending on Browser>http://utf-8.jp/public/20081011/h6.html?file=data.txt]]
--ブラウザの仕様や動作に起因する脆弱性についての解説です。

#br
*脆弱性・攻撃手法 [#lbe8c9b4]
下記の一覧は、[[@IT:Webアプリケーションに潜むセキュリティホール(1):>http://www.atmarkit.co.jp/fsecurity/rensai/webhole01/webhole01.html]]より引用したものに加筆しています。
-&new(Brute Force Attack);
--ブルートフォース攻撃
-&new(Buffer Overflow);
--バッファオーバーフロー
-&new(Cross Site Scripting);
--クロスサイトスクリプティング
-&new(Cross Site Request Forgeries);
--クロスサイトリクエストフォージェリ
-&new(Directory Listing);
--ディレクトリリスティング
-&new(Parameter Manipulation);
--パラメータ改ざん~
ウェブアプリケーションに送信する値を改ざんする攻撃です。
//-&new(Backdoor & Debug Options);
//--バックドアとデバッグオプション
//-&new(Forceful Browsing);
//--強制的ブラウズ
-&new(Session Hijacking/Replay);
--正規ユーザが取得したセッションIDを攻撃者が入手して使用する攻撃です。
-&new(Session Fixation);
--攻撃者が取得・想定した任意のセッションIDを、正規ユーザに使用させる攻撃です。
-&new(Path Traversal);
--パスの乗り越え&br;[[Directory Travarsal>http://www.kab-studio.biz/Programing/JavaA2Z/Word/00000567.html]](ディレクトリ・トラバーサル)とも。
-&new(SQL Injection); (Blind SQL Injection)
--SQLの挿入
-&new(OS Command Injection);
--OSコマンドの挿入
-&new(Client Side Comment);
--クライアント側コメント
//-&new(Error Codes);
//--エラーコード
-&new(HTTP Response Splitting);
--HTTP レスポンス分割
-&new(Cross Site Tracing);
--クロスサイトトレーシング
-&new(Cookie Monster);
--クッキーモンスター

#br
*診断手法 [#k1e1d4f7]
**OWASP [#f4425b1e]
-[[Category:OWASP Testing Project - OWASP>http://www.owasp.org/index.php/OWASP_Testing_Project]]~
[[OWASP Testing Guide v3 Table of Contents - OWASP>http://www.owasp.org/index.php/OWASP_Testing_Guide_v3_Table_of_Contents]]
--2008年12月20日現在の最新版は''OWASP Testing Guide V 3.0''です。

#br

*参考 [#qa9cc35b]
**Webアプリケーション [#n7c21355]
-[[セキュリティガイドライン>http://www.e-3lab.com/security_guideline/index.html]]
-[[@IT:Webアプリケーションに潜むセキュリティホール(1)>http://www.atmarkit.co.jp/fsecurity/rensai/webhole01/webhole01.html]]
-[[Webサーバへの攻撃を見抜く - @IT>http://www.atmarkit.co.jp/fsecurity/rensai/handling01/handling02.html]]
#br

***PHP [#c6f036c1]
-[[PHP と Web アプリケーションのセキュリティについてのメモ>http://www.asahi-net.or.jp/~wv7y-kmr/memo/php_security.html]]
#br

**セキュア開発用ツール [#z5b45545]
-[[セキュアネットワーク通信コンポーネント集[Secure iNetSuite]>http://www.grapecity.com/japan/demo/secure/default.htm]]

リロード   凍結解除 差分 コピー 名前変更   ホーム 一覧 検索 最終更新 バックアップ リンク元   ヘルプ   最終更新のRSS