WEBセキュリティ　# HTTPとセッション管理

Last updated at 2024-07-09Posted at 2024-07-08

1. HTTP

HTTP(Hypertext Transfer Protocol)は, クライアントとサーバー間でデータを転送するためのプロトコルである.

主な特徴 :

・ステートレス：各リクエストは独立しており, 前回のリクエスト情報を保持していない.
・クリアテキスト：デフォルトでは暗号化されていないため, HTTPS(HTTP over SSL/TLS)の使用が推奨されている.

HTTP認証

HTTP認証は, WEBサーバーがクライアントの身元を証明するための手法である.
主なHTTP認証として, Basic認証, Digest認証, Bearer認証, JWT(Json Web Token)がある.
ここでは, Basic認証について説明する.

いくつかある認証の中で最も単純な認証方式
ユーザー名とパスワードをBase64エンコードして送信
暗号化されていないため, HTTPS使用が必須
セキュリティ上の懸念として, 中間者攻撃に弱い.

HTTP Basic認証フローのイメージ図.

イメージ図を言語化すると,

まず, クライアントがサーバーに対して保護されたリソースへのアクセスを要求する. 例えば, example.comというサイトリンクで, 何かしらのサイトにリクエストを送る.
サーバーは, このリソースが認証を必要とすることを示すため, 「401 Unauthorized(認証が必要なのにされていない)」　ステータスコード共に「WWW-Authenticate: Basic」ヘッダーを返す.
クライアント側で, ユーザーにユーザー名とパスワードに入力を求めるプロンプトが表示される(以下にイメージ図を示す). example.comのサイトはログインなど認証が必要なため, よく見るログインページが出現するようになっている.
ユーザーが認証情報を入力すると, クライアントはこの情報をBase64エンコードし, 「Authorization: Basic [エンコードされた認証情報]」というヘッダーを付けて、再度サーバーにリクエストを送信する.
サーバーは受け取った認証情報を検証する.
認証が成功したなら「200 OK」ステータスコードと共に, リクエストされたリソースをクライアントに返す.
認証に失敗したなら「401 Unauthorized」ステータスコードを返し, クライアントに認証の再試行を促す.

※ステップ3のイメージ図

認証と対になる用語に「認可(許可)」がある.
これらの違いとしては, 「認証」がユーザーの身元証明であるのに対して, 「認可(許可)」は認証に成功した上で, そのユーザーにデータの取得, 更新, 削除などの権限を付与することをいう.

2. セッション管理

HTTPがステートレスであるため, ユーザーの状態を維持するためにセッション管理が必要になる.

セッション管理の主な目的は以下の3つ.

ユーザーの状態の維持.
セキュアな通信の確保
ユーザー体験の向上

主な性質は以下の4つ.

セッションの作成
- ユーザーが認証された際に, サーバーは一意のセッションIDを生成する.
- このIDは通常, ランダムで予測困難な文字列である.
セッションの保存
- サーバー側：セッションデータを, メモリ, データベース, 分散キャッシュに保存.
- クライアント側：セッションIDをクッキーまたはローカルストレージに保存.
セッションの維持
- クライアントは, 各リクエストにセッションIDを含めて送信する.
- サーバーはセッションIDを用いてユーザーを識別し, 対応する適切なデータを取得する.
セッション終了
- ユーザーのログアウト.
- セッションタイムアウト.
- サーバー側でのセッション無効化.

セキュリティ上の考慮事項としては以下の5つ.

セッションIDの保護(イメージ図1)
- 十分な長さと予測困難性を持たせる（例：128ビット以上のランダム値）.
- HTTPSを使用してセッションIDの傍受を防ぐ.
- HttpOnly フラグを使用してJavaScriptからのアクセスを防ぐ.
- Secure フラグを使用してHTTPS接続でのみ送信されるようにする.

※イメージ図1

セッション固定攻撃の防止(イメージ図2)
- 認証成功後に新しいセッションIDを発行する.
- セッション固定攻撃とは
  - 1 攻撃者が即知のセッションIDを用意する
  - 2 被害者にそのセッションIDを使わせる
  - 3 被害者が認証した後, 攻撃者がそのセッションを横取りする

※イメージ図2

クロスサイトスクリプティング（XSS）対策(イメージ図3)
- 入力のサニタイズ
- コンテンツセキュリティポリシー（CSP）の実装

※イメージ図3

クロスサイトリクエストフォージェリ（CSRF）対策(イメージ図4)
- CSRFトークンの使用
- SameSite クッキー属性の設定

※イメージ図4

適切なセッションタイムアウトの設定(イメージ図5)
- アイドルタイムアウト
- 絶対的なタイムアウト

※イメージ図5

HTTPとセッション管理におけるセキュリティ上の注意点

1 常にHTTPSを使用する(イメージ図1).

HTTPSは, HTTP over SSL/TLSを意味し, データの暗号化と完全性を保証する.
詳細：

データの暗号化: 通信内容を第三者から保護する.
完全性の確保: データが改ざんされていないことを保証する.
認証: サーバーの身元を確認できる.

実装のポイント：

全てのページでHTTPSを使用する. 部分的では不十分.
HSTS(HTTP Strict Transport Security)ヘッダーを設定する.
適切な証明書を使用し, 定期的に更新する.

※イメージ図1

2 適切なパスワードポリシーを実施する

強力なパスワードポリシーは, ユーザーアカウントのセキュリティを向上させる.
詳細：

最小長の設定（例：12文字以上）.
複雑性の要求(大文字, 小文字, 数字, 特殊文字の組み合わせ).
共通パスワードやユーザー情報を含むパスワードの禁止.
定期的なパスワード変更の推奨（ただし強制は避ける）.

実装のポイント:

パスワード強度チェッカーの実装.
パスワードハッシュ化にbcryptなどの安全なアルゴリズムを使用.
二要素認証の提供.

3 ブルートフォース攻撃対策を実施する(イメージ図2)

ブルートフォー攻撃とは, 総当たりでパスワードを推測しようとする攻撃のこと.
詳細：

レート制限: 一定時間内のログイン試行回数を制限.
アカウントロック: 連続失敗後に一定時間アカウントをロック.
CAPTCHAの使用: 自動化された攻撃を防ぐ.