log

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

  • ログイン後にあるURLに飛ぶやつ→リダイレクト処理
    • ログインとかしなくてもリダイレクトって呼ぶと思うんだけど、これは特にセキュリティに関係あるからまとめて呼んでる？特別な名前がついてるわけではない？
  • オープンリダイレクタ脆弱性
    • パラメータで指定したURLに飛べて、任意のURLに飛べるので、ユーザが知らないうちにわるいところに飛ばされる可能性がある：フィッシング
    • 信頼しているサービスがこれの被害にあっていた場合、ユーザ「俺ここめっちゃ信頼してるからクレカ情報入力しちゃうぜ！」→情報漏えいみたいなことが起こってしまう　「釣り」ですね
    • リダイレクト先を固定もしくは先を許可されたドメインに制限すると🙆
    • 文書よりこの図見たほうがわかりやすいかも
    • フィッシング対策協議会　Council of Anti-Phishing Japan | STOP！フィッシング詐欺 | フィッシング詐欺って何？
    • リダイレクト先のURLを外部から指定できる AND ドメインチェックがないなら脆弱性が生まれる。でも、オープンリダイレクタが全部脆弱性ってわけじゃないよ
      • もともと外部ドメインへ遷移する仕様
      • 利用者にとって外部ドメインに遷移することが自明
    • これがそろってるときは脆弱性じゃない。web広告とかもそうだよね
      • 対策：リダイレクト先のURLを固定にする
        • 仕様を見直して、固定URLに遷移するようにする。URLパラメータから渡されたtrap.example.comに遷移するんじゃなくて、「パスワードが間違ってたらこのページに絶対遷移する！】みたいな感じかなあ
      • 対策：リダイレクト先を直接指定せず番号指定する
        • リダイレクト先を可変というか自由？にしないといけないときは、そのまま指定するんじゃなくて番号指定する。URL <-> 番号の対応は外部から見えないところで管理する。任意ドメインのURL指定は出来なくなるから、まあオッケー？
      • 対策：リダイレクト先のドメインをチェック
    • リダイレクトするとき、クッションページを挟んだりすると人間にもやさしいかも。携帯電話向けだったら、セッションIDの漏洩防止のために使ったりするよ
  • HTTPヘッダ・インジェクション
    • 外部からのパラメータを元にHTTPレスポンスヘッダを出力する際に発生する脆弱性　範囲広すぎ？？
    • 改行でヘッダかボディかわかれるので、それだけで任意のレスポンスヘッダの追加/レスポンスボディの偽造が出来るよ
      • 改行に特別な意味があるのにそのまま出力するからダメ
    • 任意の🍪の生成/任意のURLへのリダイレクト/表示内容の改変/任意のJS実行によるXSSと同じ被害が起こりうる。ありすぎでしょ。
    • ！！！HTTPヘッダの出力部分を手作りするな！！！ライブラリやAPIを使え！！！改行コード含まれてたらエラーとして中止しろ！！！
    • これに載ってる攻撃例こわすぎ。改行挟んでLocationを書くと、2回書くことになって、それだと後者のほう（攻撃の方）が優先される。
    • パラメータに改行いれることで好きなHTTPレスポンスヘッダを入れて好き勝手出来るのをHTTPヘッダ・インジェクション脆弱性という。
    • ↑このHTTPリクエスト好き勝手いじれるときに🍪もいじれる。セッションIDの固定化攻撃との組み合わせるとヤバイ＞＜
    • 偽画面表示出来て、CSS工夫することで元の画面隠してフィッシングとか、🍪盗むとか、XSSと共通の影響があるんだけど、攻撃方法がいまいちわからない
    • 対策：外部からのパラメータをHTTPレスポンスヘッダとして出力しない！！！
    • どうしても無理なときは、リダイレクト, 🍪を専用APIにさせる/改行文字チェックの両方をやる。
    • 専用APIとかライブラリにちゃんと入ってるので、できるだけそっちを利用する！
      • ただこれだけだと完全な対策にはなれないため（悲しいね）、改行文字チェック（URL中のはエラーして、🍪はパーセントエンコードするなど）をする
      • 使うライブラリが、ちゃんとパーセントエンコードした🍪を作るかチェックしようね
  • 🍪の脆弱性は、別目的で使っている/出力方法に問題があるに大別できる
  • 本来はセッションIDを保存するべきで、データを🍪に保存しない！！
  • 不適切な利用
    • 🍪、自分で書き換えられるので、困るものを保存しない。たとえばゲームのデータとかを残してたらつよくてニューゲームがし放題？
    • ただ、困らないものでも保存しないほうがよい。🍪とセッション変数で変わるのは情報寿命の制御/異なるサーバとの情報共有だけ。これ以外はセッション変数が便利だから、普通はそっち使う。
    • ナイショの情報を表示するときにセッションだともっかい入力求めさせられる。タイムアウトすると表示すらされなくなる。
    • ただ、セッションやサーバをまたがって情報を保存したいときは🍪使う。「ログイン状態を保存」とか。ただ、これで保存されているのはデータじゃなくてトークンであって、認証状態はサーバ側で管理してる。
    • 「ログイン状態を保存」って結局保存してるやん！！と思って読んでたらトークンで保存してるから大丈夫やでｗって言われた
  • 🍪のセキュア属性不備
    • Secure あったよね、アプリケーションがいくらHTTPS通信してても、これがついてないと平文で送信される可能性があり危険🌽
    • Secure つけるのが一番いいんだけど、HTTPとHTTPSが混ざってると動かなくなる可能性があるから、トークンをセキュア属性付き🍪として発行→ページごとに確認とか！
    • 🍪にセキュア属性つけないと、HTTPにリクエストしたときのレスポンスに入ってる🍪値を盗聴される可能性がある：これどうやって盗聴するのかよくわからなかった　わかった！！！
    • HTTPSのサイトにアクセスしてログインしておく：このときSecure属性オフ
    • 罠ページにユーザを誘導させる。そんで、Cookie持ってくるために、ここでは、width = height = 0 で img src = 攻撃先することで、imgしてるから、ブラウザにそこにアクセスさせることになるので、クッキーを送信させることができる
    • HTTPリクエストを見ると、HTTPSでセットされたはずのCookieが平文で送信されている！！！←ここを盗聴できる
  • セキュア属性なんでつけないの？
    • まず知らない←死
    • つけるとアプリケーションが壊れる
    • こういうとき f:id:lullasy:20170103205134j:plain
    • こういうときは、トークンを保持する🍪にSecureつけるとセッション共有できるしセッションハイジャック防止出来てラッキー
    • ラッキーじゃなくてブースター
    • トークンで安全性が確保出来る理由：トークンがサーバとブラウザの双方向で確実に暗号化されること、HTTPSのページを見るにはトークンが必要だから
  • HTTPSを使ってもCookieの改変は防げないことを実験で試してみた | 徳丸浩の日記 全然関係ないんだけど、このページめっちゃ参考になって面白かった。

HTTPS へ置き換えてアクセスすることを試みるように伝達することが可能になります。