読者です 読者をやめる 読者になる 読者になる

log

安全なwebアプリケーションの作り方 2-65

  • 脆弱性は悪用出来るバグで、経済的にかなり損失が起こることがおおい
    • 信用失った結果売上落ちる
    • 小さくても法的にヤバイ
    • 黒歴史ばらまいたり個人情報ばらまくのでダメ
  • リファラで持ってくる URL にセッション ID 含まれてたら漏洩する可能性がある←セッション ID ってどうやって管理するべき? URL に乗らないように隠して持つ?
    • A. Webブラウザ向けならクッキー thanks:sora_h
  • GET はデータを取ってくるときだけ使いたい、副作用ないようにしよう!
    • hidden は 第三者からの書き換え には強いけど、本人では hidden パラメータをいじれる。これは対策する必要あるのかなあ?
    • hiddenのあまりにも馬鹿げた使い方 - ockeghem(徳丸浩)の日記 必要ありました、これさすがに怖すぎると思うんだけど、こういうことをしているサイトがあるのがびっくり
  • ステートレス

    ステートレスとは、システムが現在の状態を表すデータなどを保持せず、入力の内容によってのみ出力が決定される方式。

  • Basic認証はステートレスなので、やりとりのたびに認証情報を全部わたす。めっちゃ不便そう、一回の情報盗まれるだけで認証取られるのやばすぎ

    • Basic認証はこんな感じ↓
    • 別にクッキーでも何にせよ情報は毎回渡しているけど、根本的な資格情報かセッションかどうかの違いが大きい(機械的に変わるし無効ともできるし) thanks:sora_h f:id:lullasy:20161230223731j:plain
  • クッキーでセッション管理するのが便利、そのまま残すのはアレだから整理番号(セッション ID?)で管理するとよい。通しはあぶないので、漏洩しない/強制しない/推測できない🙈🙉🙊が条件

  • Cookie属性は色々あって、Domain/Path/Expires/Secure/HttpOnly
    • Domain:Domain = example.jp → a.example.jp / b.example.jp にも送られる。レンタルサーバとかだと漏洩するからダメ!
    • Secure:SSL 通信してるときだけCookie送る
    • HttpOnly:JS からアクセス出来なくなるので、XSS対策になる?攻撃を「難しく」することは出来る
  • 能動的と受動的攻撃、直接いじるのは能動的で、いじったデータを元に色々させる?被害を与える?のが受動的?
    • ブラウザで受動的攻撃を防ぐにはサンドボックスがよい。よくある、この機能にはアクセス出来ますよというやつ。最近の iOS とかでは標準で搭載されてたりするの、すごいのか人間が信頼出来ないのかどっちだろう。
  • 同一生成元ポリシー
    • こういう状況が起こりうる↓ f:id:lullasy:20161231003045j:plain -同一生成元ポリシーがあると、ホスト一致(Fully Qualified Domain Name)/ プロトコル一致 / ポート番号一致 でないところからデータを取れなくなる = JS アクセスが拒否される -普通だと拒否されるので、がんばって iframe の内側に JS 送り込んで情報を盗もうとする→XSS攻撃
  • X-FRAME-OPTIONS
  • ブラウザで対策してても回避する方法たくさんある。webアプリケーション側でしないといけない対策はこんどね