社内研修「HTTPから学ぶTCP/IP基礎」(5)

前回から引き続き、HTTPヘッダについて説明をします。
今回はBasic認証時に使用するAuthorizationと、Webブラウザに情報を保存する際に必要なCookieについて説明をします。

Authorization

HTTPでは認証の仕組みが用意されています。インターネットのサービスではあまり見かけませんが、認証が必要なページを開こうとすると、下記のようなダイアログが出ます。見たことがある方も多いのではないでしょうか。

認証の方法は2つあり、Basic認証とDigest認証があります。

Basic認証

Webサーバ、Webブラウザの双方で古くから実装されており、よく知られているのがBasic認証です。日本語にしただけですが、基本認証とも呼ばれます。
ダイアログで入力したユーザ名とパスワードは、Base64でエンコードをされて、Authorizationヘッダに設定されます。下記はユーザ名「ois」パスワード「yokohama」の場合のAuthorizationヘッダです。
Authorization: Basic b2lzOnlva29oYW1h
ois:yokohamaをBase64エンコードした値がb2lzOnlva29oYW1hです。
ユーザ名、パスワードは暗号化されているのではなくBase64という方式でデータを置き換えているだけなので、通信経路上で簡単にユーザ名、パスワードが分かってしまいます。

Digest認証

Basic認証は通信経路上で簡単にパスワードが分かってしまうという欠点がありましたが、Digest認証ではその欠点を補い、パスワードではなくダイジェスト（ハッシュ値）を送ります。
下記例のresponseがダイジェストです。それ以外はダイジェストを生成するのに必要な情報です。
Authorization: Digest username=”ois”, realm=”Authorization”,
   nonce=”RMH1usDrAwA=6dc290ea3304de42a7347e0a94089ff5912ce0de”,
   uri=”/index.html”, algorithm=MD5,
   qop=auth, nc=00000001,  cnonce=”e79e26e0d17c978d”,
   response=”0d73182c1602ce8749feeb4b89389019″
Webブラウザでは入力されたパスワードや、URL、サーバから受け取ったランダムなコードなどを元にハッシュ値を生成します。ハッシュ値とともに、ダイジェストを生成するのに必要な情報を送り、サーバでは、受け取ったデータと、サーバ内で保持しているパスワードから同様にハッシュ値を生成し、Webブラウザから送られたものと一致すれば認証OKとします。
Basic認証と違って盗聴されたとしてもパスワードは分かりません。ですが、盗聴されて同じヘッダでリクエストを送られると、Webサーバで認証されてしまいます。
Basic認証、Digest認証に限らず、認証を必要とする場合はHTTPではなくHTTPSにするべきでしょう。

Cookie

Cookieの概要はITエンジニアでなくともご存じの方が多いと思います。また、Webアプリケーションエンジニアは一番なじみの多いヘッダフィールドではないでしょうか。
Wikipediaでは

HTTP cookie（エイチティーティーピークッキー、単にクッキーとも表記される）は、RFC 6265などで定義されたHTTPにおけるウェブサーバとウェブブラウザ間で状態を管理するプロトコル、またそこで用いられるウェブブラウザに保存された情報のことを指す。ユーザ識別やセッション管理を実現する目的などに利用される。

と、書かれています。
HTML5が出てくる前は、ローカルPCのハードディスク上に保存することができる唯一の方法でした。
例えば認証が必要なWebサイトにログインした際のセッション情報など、動的なWebサイトで使われるイメージが強いですが、
アクセス解析で使われており、多くの静的なWebページへのリクエスト時に送られています。
リクエストヘッダの内容は以下のようになっており、保存されているCookieのkeyとvalueがイコールで結ばれて対になって送られます。
Cookie: aaa=228008660; bbb=aadfa9efjaida

第5回は以上です。
長かったですが、今回でHTTPリクエストで使用するメッセージヘッダについての説明は終わりです。他にもまだリクエストで使用できるヘッダはありますので、興味のある方は調べてみてはいかがでしょうか。
次回はHTTPリクエストの本体部について説明をしていきます。