安全なwebアプリケーションの作り方 2-65
- 脆弱性は悪用出来るバグで、経済的にかなり損失が起こることがおおい
- リファラで持ってくる URL にセッション ID 含まれてたら漏洩する可能性がある←セッション ID ってどうやって管理するべき? URL に乗らないように隠して持つ?
- A. Webブラウザ向けならクッキー thanks:sora_h
- GET はデータを取ってくるときだけ使いたい、副作用ないようにしよう!
- hidden は 第三者からの書き換え には強いけど、本人では hidden パラメータをいじれる。これは対策する必要あるのかなあ?
- hiddenのあまりにも馬鹿げた使い方 - ockeghem(徳丸浩)の日記 必要ありました、これさすがに怖すぎると思うんだけど、こういうことをしているサイトがあるのがびっくり
ステートレス
ステートレスとは、システムが現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式。
Basic認証はステートレスなので、やりとりのたびに認証情報を全部わたす。めっちゃ不便そう、一回の情報盗まれるだけで認証取られるのやばすぎ
- Basic認証はこんな感じ↓
- 別にクッキーでも何にせよ情報は毎回渡しているけど、根本的な資格情報かセッションかどうかの違いが大きい(機械的に変わるし無効ともできるし) thanks:sora_h
クッキーでセッション管理するのが便利、そのまま残すのはアレだから整理番号(セッション ID?)で管理するとよい。通しはあぶないので、漏洩しない/強制しない/推測できない🙈🙉🙊が条件
- 強制しない:攻撃者がなりすましてやるやつ、中間者攻撃みたいなもん?セッション ID の固定化攻撃というらしい セッション管理に対する攻撃と対策 - Qiita
- Cookie属性は色々あって、Domain/Path/Expires/Secure/HttpOnly
- 能動的と受動的攻撃、直接いじるのは能動的で、いじったデータを元に色々させる?被害を与える?のが受動的?
- 同一生成元ポリシー
- X-FRAME-OPTIONS
- なにこれ?ていうかframeとかiframeってなんかのバージョンから使うのやめろって言われた気がするんだけど -クリックジャック攻撃への対策らしい?見えてないのにボタン押してて気付いたらヤバイ決済してたとかいうあれ
- iframe内からWebページが読み込まれるのを防止する X-Frame-Options HTTP レスポンスヘッダ - buzzword update
- ブラウザで対策してても回避する方法たくさんある。webアプリケーション側でしないといけない対策はこんどね