セキュリティについて勉強
体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践
- 作者: 徳丸浩
- 出版社/メーカー: ソフトバンククリエイティブ
- 発売日: 2011/03/03
- メディア: 大型本
- 購入: 119人 クリック: 4,283回
- この商品を含むブログ (136件) を見る
勉強中。メモ。
GETとPOSTの使い分け
■GETの弱点
・ブラウザやサーバが処理できるURLの長さには上限がある
・URLに指定されたパラメータがアクセスログに残る
・URLに指定されたパラメータがReferer経由で外部に漏れる
↓
■POSTにするパターン
・送信するデータ量が多い場合
・データ更新など副作用を伴う場合
・秘密情報を送信する場合
hiddenパラメータ
■hiddenパラメータの弱点
hiddenパラメータをユーザが改変し攻撃できる
■hiddenパラメータのメリット
利用者側から書き換えできるが、情報漏えいや第三者からの書き換えに堅牢
認証と認可
認証:利用者が確かに本人だと確認すること
認可:認証済みの利用者に対して権限を与えること
■Basic認証
1度認証すれば認証状態が保持されているように見えるが
実際、リクエスト毎にIDとPWが送出されている
■クッキーとセッション管理
サーバ側で認証状態を覚えておくことをセッション管理
[クッキー]
---------------
・保持できる値の個数や文字列長に制限
・クッキーの値は利用者本人には参照・変更できるので
秘密情報の格納には向かない
・デフォルトではクッキーをセットしたサーバのみに送られる
セッションIDの固定化攻撃に利用されるので、異なるドメインへの
クッキー設定は出来ない
・Domain属性を指定しない状態がもっともクッキーの
送信範囲が狭い
※Domainは通常設定しないもの
・クッキーモンスター問題
古いブラウザだと「.co.jp」ドメインのクッキーが作られてしまう
セッションIDの固定化攻撃を受けやすくなる
・クッキーのhttponly属性
javascriptからアクセス出来ないクッキーを設定するもの
[セッションIDに求められる要件]
--------------------------------
・第三者がセッションIDを推測できないこと
1.セッションIDは連番ではなく、乱数を利用する
2.
・第三者からセッションIDを強制されないこと
セッションIDの固定化→セッションIDの固定化
・第三者にセッションIDが漏洩しないこと
1.ネットワーク的にセッションIDが盗聴される
2.クロスサイトスクリプティングなどアプリケーションの脆弱性により漏洩する
3.PHPやブラウザなどプラットフォームの脆弱性により漏洩する
4.セッションIDをURLに保持している場合はRefererヘッダから漏洩する
能動的攻撃と受動的攻撃
・能動的攻撃
攻撃者がwebサーバに対して直接攻撃すること
・受動的攻撃
罠サイトに利用者を誘導する
正規サイトを悪用する
1.FTPなどのパスワードを不正入手
2.webサーバの脆弱性をついた攻撃
3.SQLインジェクション攻撃により
コンテンツを書き換える
4.SNSなど利用者が投稿できるサイト機能のクロスサイトスクリプティング
脆弱性を悪用