@kyanny's blog

My thoughts, my life. Views/opinions are my own.

3. Webセキュリティの基礎

読書 体系的に学ぶ 安全なWebアプリケーションの作り方 wasbook

HTTP の基礎については、復習のつもりで読んだ。いちおうちゃんと理解できてたと思う。

パーセントエンコーディングは、対象の文字列をバイト単位で「%xx」という形式で表します。xx はバイトの16進数表記です。「徳」という文字をUTF-8符号化すると、 E5 BE B3 というバイト列になるため、パーセントエンコーディング後は、 %E5%BE%B3 となります。

  • application/x-www-form-urlencoded との違い

パーセントエンコーディングの規約では、スペースは %20 となりますが、「application/x-www-form-urlencoded」の場合はスペースを特別扱いして「+」に符号化することになっています。パーセントエンコーディングは URL (URI) の規約で、 application/x-www-form-urlencoded は HTML の規約ですので、わずかながら差異があります。

  • hidden パラメータのメリット
    • 情報漏洩や第三者からの書き換えに対しては堅牢
      • ここの理解がちょっと怪しい。先に「セッションIDの固定化」のページを読んでなんとなく理解した気になっているけどあまり自信がない。セッションIDの固定化攻撃の例と同じ攻撃をされた場合、 hidden パラメータのみで値の受け渡しをしていれば、攻撃者が同じセッションIDを指定してページを閲覧した場合でも hidden パラメータで指定されていた値を盗み見ることはできない、だから堅牢である、ということであってるのかな。でもセッションIDの固定化攻撃をされて成功しちゃった時点でもっと危険な状態だから hidden パラメータの堅牢性をうたっても意味ないじゃん、と感じてしまう・・・。
  • HTTP 認証
    • 一度Basic 認証に成功すると、以降はブラウザが自動的に Authorization ヘッダを付与する
    • 見かけ上は1回だけ認証ダイアログが表示されるので認証状態が保持されているように見える
    • が、実際にはリクエスト毎にIDとパスワードが送出されており、認証状態はどこにも保存されていない
    • Basic 認証もステートレス（ステートレスな HTTP のうえにあるものなので）
    • ステートレスなのでログアウトという概念もない
  • クッキーとセッション管理
    • セッションIDに求められる要件
      1. 第三者がセッションIDを推測できないこと
      2. 第三者からセッションIDを強制されないこと
      3. 第三者にセッションIDが漏洩しないこと
    • セッション管理機構は自作しない！（セッションID生成に関する脆弱性のもと）
    • 認証後にセッションIDを変更する（セッションIDの強制に対する対策）
    • クッキーの属性
      • Domain 属性を指定しない状態がもっともクッキーの送信範囲が狭く安全な状態
      • クッキーの Domain 属性は原則として設定しない
      • クッキーモンスターと地域型ドメイン（送信範囲が極めて広いクッキーを発行できてしまう問題）
      • HttpOnly 属性（知らなかった）
      • JavaScript から読めなくなる
      • HttpOnly 属性を使用してもクロスサイトスクリプティング攻撃を完全に防ぐことはできない
      • HttpOnly 属性をつけることによる悪影響はない
  • 受動的攻撃
    • XSS, CSRF などの攻撃パターン
    • サンドボックス
    • 同一生成元ポリシー（Same Origin Policy）
      • frame, iframe 等を経由して別ホストの情報をスクリプトから利用できない制限
      • XMLHttpRequest によるネットワークアクセスを経由して別ホストの情報をスクリプトから利用できない制限
    • 同一生成元である条件
      • URL のホストが一致 (FQDN)
      • スキーム（プロトコル）が一致
      • ポート番号が一致
    • 第三者の JavaScript を許可する場合

バナー広告などの JavaScript と XSS の結果動作する JavaScript には、技術的に見れば同一の脅威があります。提供元の信頼性を十分調査した上で、保守的で慎重な判断が求められます。

    • X-FRAME-OPTIONS
    • クロスドメインでの script 読み込み

この際、サイトBに置かれた JavaScript を取得するリクエストでは、サイトBに対するクッキーが送信されます。そのため、利用者のサイトBでのログイン状態によって、サイトBに置かれた JavaScript のソースコードが変化し、その変化がサイトAに影響を与える場合があります。この性質を積極的に利用したのが JSONP (JSON with padding) という手段です。

      • ここわからなかった。 JSONP って「ログイン状態によってソースコードが変化し」という性質と密接に関係あるものなのか？成り立ちとしてはそういう背景があって、でも広まるにつれて特にログインとか関係なくクロスドメイン制約を乗り越えて JavaScript から別ホストのデータを利用する手段として知られるようになり、おれはそういう風にしか JSONP を理解できていないのでピンとこないのだろうか・・・。
    • form 要素の action 属性もクロスドメインの指定が可能
    • この仕様を悪用した攻撃方法が CSRF (クロスサイトリクエストフォージェリ)