Zenn
👮

【徳丸本で学ぶ!】HTTPプロトコルとセッション管理の基本とセキュリティ対策

2024/10/17に公開
Web
Security
エンジニア
it
徳丸本
tech

🚀初めに

徳丸 浩 さんの 「 体系的に学ぶ 安全なWebアプリケーションの作り方 第2版［固定版］　脆弱性が生まれる原理と対策の実践 」通称 徳丸本を勉強しています
https://www.amazon.co.jp/dp/B07DVY4H3M?tag=hatena-22&linkCode=ogi&th=1&psc=1

今回は学習ブログの第二回目になります

🔍内容

HTTPプロトコル

  • 学ぶ理由: 多くのウェブアプリケーションの脆弱性はHTTPプロトコルに由来するため、その構造を理解することがセキュリティ対策の第一歩となるから

HTTP通信の構造

リクエスト情報

GET http://localhost:8080/tokulearn/xss/view HTTP/1.1
host: localhost:8080
...省略
  • 内容
    • GET http://localhost:8080/tokulearn/xss/view HTTP/1.1
    • リクエストの種類(GET) リクエスト先ドメイン名(https...) 通信プロトコル (HTTP/1.1)
    • HTTP/1.1は通信プロトコルのバージョン、200は成功を意味するステータスコード。

レスポンス情報

HTTP/1.1 200
X-Content-Type-Options: nosniff
X-XSS-Protection: 0
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: text/html;charset=UTF-8
Content-Language: ja
Date: Tue, 15 Oct 2024 21:50:05 GMT
content-length: 573
  • 内容
    • HTTP/1.1 200
      • これは通信プロトコルとレスポンスコードを示す。HTTP/1.1は通信プロトコルのバージョン、200は成功を意味するステータスコード。
    • Content-Type
      • MIMEタイプを表しており、返されるリソースの種類を示す。例えば、この場合は text/html なので、HTML文書が返されていることを意味している。詳しいMIMEタイプの情報はこちら。
    • content-length
      • レスポンスのボディ部分のサイズ（バイト数）が記載されている。この例では、573バイトのデータが返されていることになる。

GETとPOSTを使い分けよ

HTTP1.1を定義している RFC7231
(実際読んだけど日本語訳は何書いてあるかわかりませんでした)

  • GET/POSTメソッドについて以下のガイドラインが記載されている

    • GETメソッドはリソースの取得/参照に利用すること
    • GETメソッドは副作用(更新や削除や登録)がないことが期待される
    • 秘密情報を送信する際はPOSTメソッドを使うこと

  • GETメソッドを利用するユースケース

    • POSTメソッドのユースケースに該当しないとき

  • POSTメソッドを利用するユースケース

    • データ更新/削除/登録がしたい
    • 秘密情報を送信したい
    • 量が多いデータを送信したい

Refererの脆弱性

リクエストには Refeler タグを含む場合がある
Refelerタグはページを遷移した際の遷移元ページのURLを含んでいる

以下のように PageAからPageBへの遷移をした場合、refererには pageAのURIが入る

  • 脆弱性
    • セッションIDを含んでいる可能性がある
      • セッションIDを盗まれなりすまされる可能性あり
    • 秘密情報を含んでいる
      • 漏洩する可能性あり

hideenの脆弱性

  • hiddenパラメータ自体の書き換えは本人でしかできない
    • 脆弱性というほどではなさそう
  • 第3者には堅牢である

webのステートレス

  • セッションやCookieなどで値を保持しないもの
    • バックエンドのキャッシュやDBで値を保持し、認証のたびにバックエンドで認証済みかを確認するなど

セッション管理

webのステートフル

  • セッションやCookieなど値の状態を保持しているものがステートフル
    • セッション情報にToken値があり、認証はCookieにあるセッションIDから、セッションに格納されてあるTokenを使用し認証を行うなど

クッキーとセッションの使われ方

  • XSSの標的になることが多い
  • 認証で生成したToken値など秘密情報を格納するのには適していない
  • Token等はセッションで保持し、CookieではセッションIDを保持する
    • Cookieを盗まれるとセッションIDも漏洩し、セッションにある情報が漏洩するため注意
  • Cookieには格納するデータにサイズ制限があるため、長い文字列等のデータはセッションに格納することが好ましい

クッキーモンスターバグ

Cookieのサイズを制限していない場合に発生しやすい
Cookieデータに過剰なデータを送信し、正常なセッションID等の管理ができないようにさせる

📝まとめ

今回紹介したHTTPプロトコルやセッション管理に関する知識は、Webアプリケーションのセキュリティを強化するために不可欠。
特に、GETとPOSTの正しい使い分けや、RefererやCookieの扱いには注意が必要。
脆弱性を理解し、適切な対策を取ることで、攻撃者からのリスクを軽減できる。また、クッキーのサイズ管理やステートレスな設計も、システムの安全性とパフォーマンスを向上させるための重要なポイント。

💨学習スケジュール

  • 【徳丸本で学ぶ!】バグと脆弱性の違いについて XSS(クロスサイトスクリプティング)を使って確認する
  • 🟢(now)【徳丸本で学ぶ!】HTTPプロトコルとセッション管理の基本とセキュリティ対策
  • 【徳丸本 セキュリティ】XSS
  • 【徳丸本 セキュリティ】SQLインジェクション
  • 【徳丸本 セキュリティ】CSRF
  • 【徳丸本 セキュリティ】WebAPI実装の脆弱性
  • 【徳丸本 セキュリティ】DOMBasedXSS
  • 【徳丸本 セキュリティ】セッション管理の不備
  • 【徳丸本 セキュリティ】インジェクション
  • 【徳丸本 セキュリティ】ディレクトリ・トラバーサル
  • 【徳丸本 セキュリティ】ログイン機能
  • 【徳丸本 セキュリティ】自動ログイン
  • 【徳丸本 セキュリティ】アカウント管理
  • 【徳丸本 セキュリティ】認可とログ出力

Discussion