Web開発

Webの初期段階では、ブラウザはシンプルなドキュメントビューアに過ぎませんでした。ページをリクエストすると、サーバーがそれをレンダリングし、接続が閉じられていました。この「リクエスト・レスポンス」のサイクルが HTTP (Hypertext Transfer Protocol) の核心です。 しかし、Webアプリケーションがリアルタイムチャット、ライブの株価表示、共同編集、マルチプレイヤーゲームなどのリッチでインタラクティブな体験へと進化するにつれて、従来のHTTPモデルの限界が浮き彫りになりました。 リアルタイムの更新情報を取得するために、開発者は当初、以下のような回避策に頼っていました。 ショートポーリング (Short Polling): ブラウザが数秒おきにHTTPリクエストを繰り返し送信し、新しいデータがあるかサーバーに問い合わせます。これは大量のヘッダーオーバーヘッドを生み出し、サーバーリソースを浪費します。 ロングポーリング (Long Polling / Comet): ブラウザがリクエストを送信し、サーバーは新しいデータが利用可能になるまで接続を保持します。データが送信されると接続が閉じられ、ブラウザは即座に新しいリクエストを開きます。これは管理が複雑で、接続確立時のオーバーヘッドも依然として発生します。 **WebSocket（ウェブソケット）**は、単一のTCP接続上で永続的、双方向、かつ全二重（フルデュプレックス）の通信を行うための標準化されたプロトコルを導入することで、これらの制限を解決しました。 WebSocketとは何か？ WebSocket（RFC 6455で定義）はHTTPと並行して動作します。HTTPがクライアントからしかリクエストを開始できないステートレスなプロトコルであるのに対し、WebSocket接続は一度確立されると無期限に開いたままになり、クライアントとサーバーの両方がいつでも最小限の遅延でデータを送信し合うことができます。 WebSocketの根本的なルールは以下の通りです。 一度接続が確立されると、どちらの側からでも、新しい接続リクエストを開始することなく、いつでもメッセージを送信できます。 ステップバイステップ・ウォークスルー：接続のライフサイクル WebSocket接続は、ハンドシェイク、データ転送、切断という3つの明確なフェーズを経ます。 1. HTTPハンドシェイク（プロトコルのアップグレード） ファイアウォールやルーターは、ポート80（HTTP）および443（HTTPS）の標準的なウェブトラフィックを許可するように設定されているため、WebSocketは標準のHTTP/1.1リクエストとして開始されます。これはアップグレードハンドシェイクと呼ばれます。 クライアントからのリクエスト クライアントは、プロトコルの切り替えを要求する特定のヘッダーを含むHTTP GETリクエストを送信します。 GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 Origin: https://example.com Upgrade: websocket と Connection: Upgrade: プロトコルの切り替えを希望していることをサーバーに伝えます。 Sec-WebSocket-Key: Base64でエンコードされたランダムな16バイトの値。サーバーがハンドシェイクを受信し、WebSocketプロトコルを理解していることを証明するために使用されます。 Sec-WebSocket-Version: WebSocketプロトコルのバージョンを指定します（通常は13）。 Origin: サーバーが接続を許可するかどうかを判断するために使用されます（不正なサイトからのクロスサイト接続を防ぐセキュリティチェック）。 サーバーからのレスポンス サーバーがWebSocketをサポートしている場合、リクエストを検証し、HTTPステータスコード 101 Switching Protocols（プロトコル切り替え）で応答します。

サイバーセキュリティの世界において、**ハッシュ（Hashing）**は最も基本的でありながら、しばしば誤解されている概念の一つです。それはあなたのパスワードを守り、ダウンロードしたファイルの正当性を検証し、ブロックチェーンを動かす目に見えない盾です。 しかし、ハッシュとは一体何なのでしょうか？なぜ「復号」できないのでしょうか？そして最も重要なのは、不可逆であるならば、ウェブサイトはどうやってあなたが正しいパスワードを入力したと判断できるのでしょうか？ 1. ハッシュ関数とは？ 暗号学的ハッシュ関数とは、任意のサイズの入力（メッセージ）を受け取り、それを固定サイズの文字列（ダイジェスト）に変換する数学的なアルゴリズムです。この文字列は通常、ランダムな英数字の羅列のように見えます。 ハッシュ化の黄金律： 決定的（Deterministic）： 同じ入力からは常に全く同じハッシュが生成される。 高速な計算： 実用的な速度で計算できる必要がある。 固定の出力サイズ： 単一の単語でも、図書館全体の蔵書データでも、出力される長さは常に一定（例：SHA-256なら256ビット）。 雪崩効果（Avalanche Effect）： 入力が一文字変わるだけでも、全く異なるハッシュ値が生成される。 2. なぜハッシュは不可逆なのか？ **暗号化（Encryption）**が「鍵」を使って暗号化と復号ができる「双方向」の仕組みであるのに対し、ハッシュ化は「一方通行」です。一度ハッシュ化された値から元のデータを導き出すことはできません。 「絵の具の混合」の例え 青い絵の具と黄色い絵の具を混ぜると緑になります。青と黄から緑を作るのは簡単ですが、その緑色の絵の具から元の青と黄色を完璧に分離して元のバケツに戻すことは物理的に不可能です。 数学的な理由：情報の欠落 ハッシュアルゴリズムは、意図的に情報を捨てるように設計されています。例えば、「数字の合計の下一桁を取る」という単純なハッシュルールを考えてみましょう。 入力 15 -> 1+5 = 6 入力 24 -> 2+4 = 6 結果の 6 だけを見ても、元の入力が15だったのか、24だったのか、あるいは33だったのかを知る術はありません。SHA-256のような実際のアルゴリズムでは複雑さは桁違いですが、原理は同じです。情報は凝縮され、一部が捨てられているのです。 3. 不可逆なのに、どうやってパスワードを照合するのか？ これが最も多い質問です。「ウェブサイトがパスワードをハッシュとして保存し、それを元に戻せないなら、どうやってログインの正誤を判断しているの？」 答えはシンプルです。パスワードそのものではなく、ハッシュ値を比較しているのです。 照合のワークフロー： 新規登録： アカウント作成時、サーバーはパスワード（例：MySecret123）を受け取り、それをハッシュ化して、ハッシュ値のみをデータベースに保存します。 ログイン試行： ユーザーがログイン時にパスワードを再入力します。 計算： サーバーは入力されたパスワードを受け取り、同じハッシュアルゴリズムでハッシュ化します。 比較： サーバーは「新しく計算したハッシュ」と「保存されているハッシュ」を比較します。 計算したハッシュ == 保存されたハッシュ なら、パスワードは正しいと判断されます。 一致しなければ、パスワードは間違いです。 サーバーはあなたの本当のパスワードを一度も「知る」ことはありません。 入力されたデータが、期待される数学的な「指紋」と一致するかどうかだけを確認しているのです。

現代のWeb環境において、セキュリティは単なる機能ではなく、基盤そのものです。アプリケーションの相互接続が進む中、異なるオリジンやサーバー間でのリクエストがどのように処理されるかのニュアンスを理解することは、あらゆる開発者にとって極めて重要です。 今日は、すべてのWeb開発者が習得すべき3つの重要な概念、SSRF、CSRF、そしてCORSについて深く掘り下げていきます。これらは一見複雑な略語に見えますが、Webアプリケーションセキュリティの最前線を象徴するものです。 1. SSRF (サーバー側リクエスト偽造) SSRFは、攻撃者がサーバー側のアプリケーションを操作して、攻撃者が指定した任意のドメインに対してHTTPリクエストを強制的に送信させる脆弱性です。 仕組み 入力としてURLを受け取り（例：プロフィール画像の取得やリンクのプレビューなど）、サーバーからそのURLに対してリクエストを行うWebアプリケーションを想像してください。アプリケーションがこのURLを適切に検証しない場合、攻撃者は内部IPアドレスやループバックアドレス（127.0.0.1）を指定する可能性があります。 サーバーがプロキシとして動作し、パブリックインターネットに公開されていない内部サービスから次のような機密データを取得してしまう恐れがあります： クラウドメタデータ： AWS/GCP上の 169.254.169.254 にアクセスしてIAM認証情報を取得する。 内部管理パネル： JenkinsやKubernetesダッシュボードなどの内部ツールへのアクセス。 ポートスキャン： 内部ネットワーク上で動作している他のサービスの探索。 防策 ホワイトリスト： 信頼できるドメインの定義済みリストへのリクエストのみを許可する。 入力の検証： URLが許可されたプロトコル（例：https:// のみ）を使用しており、内部IP範囲を指していないことを確認する。 ネットワークの分離： Webサーバーが内部リソースにアクセスできる範囲を制限する。 2. CSRF (クロスサイトリクエスト偽造) CSRFは、被害者が現在ログインしている別のWebサイト上で、被害者のブラウザを操作して意図しないアクションを実行させる攻撃です。 仕組み この攻撃は、ブラウザがドメインへのすべてのリクエストに対して、セッションCookieなどの認証情報を自動的に含めるという性質を悪用します。 ユーザーが bank.com にログインする。 ユーザーが別のタブで悪意のあるサイト evil.com にアクセスする。 evil.com には、bank.com/transfer?amount=1000&to=attacker に対して POST リクエストを送信する隠しフォームが含まれている。 ブラウザは、ユーザーの bank.com セッションCookieと共にリクエストを送信する。 bank.com は有効なセッションであると判断し、送金処理を実行する。 防策 アンチCSRFトークン： 状態を変更するすべてのリクエストに、一意で推測不可能な秘密のトークンを含める。サーバーは処理前にこのトークンを検証する。 SameSite Cookie： Cookieの SameSite 属性を Strict または Lax に設定し、クロスサイトリクエストで送信されないようにする。 カスタムヘッダー： AJAXリクエストの場合、標準のHTMLフォームでは設定できないカスタムヘッダー（例：X-Requested-With）を必須とする。 3. CORS (オリジン間リソース共有) SSRFやCSRFとは異なり、CORS自体は脆弱性ではなく、セキュリティメカニズムです。これはサーバーがブラウザに対して、「この特定の外部オリジンが私のリソースにアクセスすることを許可します」と伝えるための手段です。

JSON Web Token（JWT）は、パーティ間で情報をJSONオブジェクトとして安全に送信するための業界標準となっています。セッション管理において、開発者はしばしば重要なアーキテクチャ上の決定を迫られます。それは、実装を**ステートレス（Stateless）**にするか、**ステートフル（Stateful）**にするかです。 どちらのアプローチにもメリットがあり、適切な選択はアプリケーションの規模、セキュリティ要件、およびインフラストラクチャに完全に依存します。 1. ステートレスJWT実装 純粋なステートレス実装では、すべてのセッションデータ（ユーザーID、ロール、有効期限）がJWT自体に直接保存されます。サーバーはデータベースやキャッシュにセッション情報を保存する必要はありません。 仕組み： ユーザーがログインします。 サーバーはユーザーの詳細を含むJWTを生成し、秘密鍵で署名します。 サーバーはクライアントにJWTを送信します。 それ以降のすべてのリクエストで、クライアントはJWTを送信します。 サーバーは署名を検証し、データベースを確認することなく、その中のデータを信頼します。 メリット： スケーラビリティ： サーバーがセッションデータを検索する必要がないため、複数のサーバーにわたる水平スケーリングが容易になります。 パフォーマンス： リクエストごとのデータベースやキャッシュのレイテンシを削減します。 非中央集権化： 異なるサービスが独立してトークンを検証できるマイクロサービスアーキテクチャに最適です。 デメリット： 無効化の問題： トークンが発行されると、有効期限が切れるまで有効です。状態（ステート）を導入せずに、特定のトークンを有効期限前に無効化すること（例：ユーザーがログアウトした、または禁止された場合）は困難です。 トークンサイズ： JWTに大量のデータを保存するとヘッダーが大きくなり、すべてのHTTPリクエストのオーバーヘッドが増加します。 2. ステートフルJWT実装 ステートフル実装は、JWTのポータビリティと従来のセッションの制御性を組み合わせたものです。このモデルでは、JWTには通常、一意のセッションIDが含まれており、サーバーはデータストア（RedisやSQLデータベースなど）でアクティブなセッションの記録を維持します。 仕組み： ユーザーがログインします。 サーバーはデータベースにセッションレコードを作成し、セッションIDを含むJWTを生成します。 サーバーはクライアントにJWTを送信します。 すべてのリクエストで、クライアントはJWTを送信します。 サーバーは署名を検証し、さらにデータベースやキャッシュを確認してセッションがまだ有効でアクティブであることを確認します。 メリット： 即時無効化： データベースからセッションを削除することで、即座にセッションを無効化できます。 より優れた制御： 「すべてのデバイスからログアウトする」や、アクティブユーザー数の監視などの機能を簡単に実装できます。 セキュリティ： トークンが盗まれた場合、即座にブラックリストに登録できます。 デメリット： スケーラビリティの低下： すべてのリクエストでデータベースやキャッシュのルックアップが必要となり、ボトルネックになる可能性があります。 インフラのオーバーヘッド： 高可用性のセッションストアを維持する必要があります。 3. どちらを選ぶべきか？ 特徴 ステートレスJWT ステートフルJWT スケーラビリティ 高い 中程度 無効化 困難 即時 複雑さ 低い 高い パフォーマンス 高速 低速 ステートレスJWTを使用する場合： 水平スケーリングが最優先事項であり、短いトークン寿命（リフレッシュトークンを使用）が許容される高トラフィックのAPIを構築している場合。