ウェブのしくみ（5/5）～セッション編～
2023/06/26
ウェブのしくみ
～ セッション編 ～
セッション
HTTPは、ブラウザからのリクエストと、
それに対するサーバーの応答で１セットになっています。
そして、ブラウザ側でサーバーからの応答HTMLを見たウェブ利用者が、
その応答に対してまた反応し、同じサーバーと何セットかやりとりする…
これも、自然のなりゆきとして考えられます。
このようにしばらく何セットか続くやりとりをセッションと言います。
クッキー
しかし、リクエストを受けるウェブサーバーとしては、サーバーの応答に対しての反応なのか、新規のリクエストなのか、通常は区別がつきません。
そこでサーバー側のプログラムは、銀行の窓口で渡す番号札のようなものを応答のHTTPヘッダに付け加えておきます。これをクッキーと言います。
※ クッキーは略語ではなく、 cookie という英単語です。
※ セッションには、クッキーを使わない方法もあります。
クッキーを受け取ったブラウザは、クッキーを保存しておきます。
そして、次回以降、同じサーバーにリクエストを送る際は、リクエストの
HTTPヘッダに、自分の持っているクッキーを自動的に付けて送ります。
こうすることで、リクエストを受け取ったサーバー側のプログラムは、
セッションの履歴に合わせた処理が可能になります。
セッションのセキュリティ
クッキーはセッションを続けるのには便利ですが、
番号札のようなものなので、簡単に偽装ができてしまいます。
そこで、お金や個人情報などが関係する重要なセッションでは、
偽装防止のため、以下のようなしくみもクッキーと共に使われています。
- 通信の暗号化（HTTPS）
- IDとパスワードによる本人確認（認証）
- セッションへの有効期限の設定
HTTPS
通常のHTTPより安全にウェブの通信をするには、HTTPSを使います。
HTTPSは、TCPとの間にTLSが追加されたHTTPです。
TLSは、相手先の確認やデータの暗号化などをするプロトコルです。
TLS： Transport Layer Security
※ 古いバージョンのTLSは、SSL: Secure Sockets Layer とも言います。
サーバー証明書
HTTPSでは、TLSの応答にサーバー証明書の写しがつけられます。
特別な機関の審査を受けて発行されたサーバー証明書をサーバーに設置し、
そのサーバーが本物であることを証明します。
暗号化
さらにTLSでは、HTTPリクエストを送る前に、暗号の準備もします。
サーバー証明書(写)には、サーバー指定の暗号用のキーも入っています。
このキーはサーバー証明書と共に誰でも見られるので、公開鍵といいます。
この公開鍵を使えば、サーバーにしか解読できない暗号を作れます。
※ 公開鍵で暗号化はできますが、解読はできません。
※以下の暗号はわかりやすくした例であり、実際の暗号はもっと解読困難です。
TLSでは、ブラウザも、お返しに暗号用の乱数をサーバーに送ります。
※ 乱数は、ブラウザがその場でランダムに数字を並べて作った数値です。
この乱数は、他人にわからないよう公開鍵で暗号化して送られます。
サーバーは、このブラウザ指定の暗号用乱数を使って、秘密鍵を作ります。
ブラウザも、同様に、暗号用乱数からサーバーと共通の秘密鍵を作ります。
その後はブラウザもサーバーも秘密鍵で暗号化してHTTP通信を行います。
認証（ID／パスワードの確認）
TLSでは、サーバー証明書によってサーバーの偽装を防ぎ、サーバーと
ブラウザの間の通信も暗号化されるため、通信途中での偽装も防げます。
しかし、ブラウザ自体を偽装されるとサーバー側には偽装がわかりません。
そこで、事前にサーバー側にIDとパスワードを登録しておき、セッション
のはじめで、必ずIDとパスワードの入力を求める応答を返すようにします。
こうすることにより、正しいIDとパスワードを送ってきたブラウザのみ、
サーバー側とセッションを続けられるようにできます。（ログイン）
セッションは、利用者側から終了することもできます。（ログアウト）
有効期限
HTTPSやパスワード認証を使っていれば、確かに偽装は難しくなりますが、
絶対的に偽装を防げるわけではありません。
あの手この手を繰り返していれば・・・
こうした対策もいつかは破られてしまう可能性があります。
偽装される可能性を０にはできませんが、限りなく０に近づけるために、
こうした偽装対策は、できるだけ短い有効期限とともに使われます。
仮に、時間をかけて偽装されたとしても、すでに有効期限が切れていて、
クッキー、共通鍵、パスワード、サーバー証明書などを、新しいものに
変えてしまっていれば、その偽装も無意味にできるのです。
まとめ
重要なやりとりでは、HTTPSやパスワード認証などで、偽装を防ぎます。
HTTPSは、TCPとの間にTLSプロトコルを追加した、HTTPです。
TLSでは、サーバー証明とHTTP通信の暗号化が行われます。
HTTPは、ブラウザからのリクエストとサーバーからの応答で、１セットになっています。
同じブラウザとサーバーで、しばらく何セットか続くやりとりをセッションと言います。
サーバー側で、セッションを新規リクエストと区別するため、HTTPヘッダに入れる番号札をクッキーと言います。
どの偽装対策も、いつかは破られる可能性があるため、有効期限を短くします。
だから…
サーバー側とブラウザの両方がセッション(クッキー)に対応していないと、セッションを続けられません。
セッションの偽装を防ぐため、一定時間が過ぎると、再ログインや再入力が必要になります。
HTTPSの有無やサーバー証明書を確認せずに、大事な情報入力やウェブ取引をするのは大変危険です。
※ 確認のしかたは「https サーバー証明書 確認」で検索できます
広告サーバーのプログラムは、各ブラウザがどのページを見てきたか（行動履歴）によって、ブラウザ毎に、その利用者を狙った広告を選択して出すことができます。（行動ターゲティング広告）
ブラウザは、読み込んだHTML内にプログラムタグ<script>等を見つけると、自動的にプログラムをリクエストして、応答されてきたプログラムを準備・実行します。
プログラムタグで指定されたURLが、 HTMLのサーバーとは別のサーバーであっても、ブラウザは、指定されたURLへ自動的にリクエストし、準備・実行します。
リクエストのHTTPヘッダには、リクエストが出された元のHTML(リファラ)のURLも入れられます。
さらに、そのサーバーで発行されたクッキーを持っている場合、そのクッキーも、自動的にリクエストのHTTPヘッダに入れられます。
こうして、広告サーバーのプログラムは、ブラウザ毎のリファラの履歴をひと続きのセッションとして確認でき、広告の選択に利用しています。