読者です 読者をやめる 読者になる 読者になる

知行合一

とか言ってみる

【HTTP】HTTPについて(弱点と認証のところ)

Web HTTP

参考にした本
www.amazon.co.jp

◼︎HTTPの弱点

  • セッションステートレス
  • 相手を確かめない
  • 平文である
  • 改竄防止がない

もう少し詳しく言うと、

Webサーバ側から見れば、誰が要求しているかわからない。
クライアント側から見れば、要求したサーバになりすまされて、別のサーバが応答してもわからない。
要求または応答を盗聴されると、メッセージはすべて平文なので中身を見られてしまう。
要求または応答のHTTPメッセージの中身を書き換えられてもわからない。

という感じ。

対処法は、「認証をする」、「暗号化する」がある。

HTTPでは認証が行われない。
サーバがユーザを確かめることをユーザ認証。
ユーザがサーバを確かめることをサーバ認証。
HTTPメッセージが改竄されていないかどうかを確かめることをメッセージ認証。

◼︎ユーザ認証

WWWはもともと誰でも使えるものという前提であり、面倒なやり取りなしで情報を共有できるのがいいところ。
今は利用方法が増え、サーバにログインすることでサーバのリソースが利用可能になる。
これはHTTPでも同じでHTTPの場合は匿名ログインを行っている。
これにより誰がログインしても匿名ユーザがログインしたことになり、サーバのリソースが利用可能になる。

認証方法は代表的なので基本認証とダイジェスト認証があるが、これはHTTPが持っている認証方法。これ以外にも認証方法は存在し、例えばフォームにユーザ名とパスワードを入れてもらいPOSTで送り、受け取ったサーバが認証処理をしてクライアントに情報を返すような動的ページを使った認証がある。フォームとチェックするプログラムが必要になるということ。HTTPはHTTPが使えるWebサーバソフトなら最初から利用できる(「401 Unauthorizded」とかはそう)。

◼︎基本認証

サーバは認証が必要な場合、WWW-Authenticateヘッダをつけて応答する。
401 Unauthorized
WWW-Authenticate:BASIC realm="www.komu.jp"
※認証方法(BASIC)と保護範囲(realm)を明記している。

それに対して、クライアントはAuthorizationヘッダにユーザIDとパスワードをBASE64で符号化したものをつけた新たな要求を送る。
GET / HTTP / 1.1
Authorization:BASEIC bmasd67afds6OK

okなら200 OKを返す。

◼︎ダイジェスト認証

基本認証はパスワードが平文で送信されるという問題がある。
BASE64は誰でも元に戻せてしまうコードなので簡単にパスワードがバレてしまう。
その対策としてダイジェスト認証がある。
ダイジェスト認証を理解するには一方向ハッシュ関数とメッセージダイジェストを理解しないといけない。

一方向ハッシュ関数・・・任意の文字列から「決まった長さの文字列」を作り出す関数。代表的なのはMD5
メッセージダイジェスト・・・「決まった長さの文字列」のこと。

メッセージダイジェストにハッシュ関数を行っても元のデータには戻らない。
また、元のデータを推測することもできない。
1ビットでも違うならメッセージダイジェストは全く違う値になる。

ダイジェスト認証でも流れは基本認証と同じで、401 Unautorized、それに対してユーザIDとパスワードを入れて返す。使うメッセージヘッダも同じ。つまり、
サーバからの応答にWWW-Authenticate、
UAからの要求にAuthorization
を使う。

ただし、入れる値が異なり、
WWW-Authenticateにはチャレンジコード
Authorizationにはレスポンスコード(サーバから送られてきたチャレンジコードとパスワードから、ハッシュ関数で生成したメッセージダイジェスト)
を入れる。
長いのでこの辺の話はここまでで、ダイジェスト認証は盗聴は防げるが、リプレイ攻撃(パスワードが入ったデータを盗聴してそのまま送りつける攻撃)やMITM(中間者攻撃。クライアントとサーバの間に入り込み、データを取得する)には対処できないから実際あまり使われていない。

結局、基本認証やダイジェスト認証ではセキュリティ的には高くはないということでした。