非SSL環境下でのBASIC認証が危険な理由をWiresharkで実際にパケット解析をして実感してみる
皆さんもうご存知の通り、BASIC認証で入力するユーザー名とパスワードはBase64というエンコード方式で送信されますが、非SSL環境下だと暗号化される事が無いので基本的に平文での送信が行われます。
非SSL環境下でのBASIC認証が危険だと言われる1番の理由は、ユーザー名とパスワードが平文で確認できちゃうという特性がある為です。パケット解析しちゃえば誰でも分かってしまうわけですね。
とは言っても
- どういう感じで確認できるの？
- 何のアプリケーションを使うの？
- HTTPリクエストの流れを見てみたい
そんなお声もあると思います。
ということで今回はBASIC認証を非SSL環境下で実装する事が如何に危険なのか、実際にパケット解析ソフトWiresharkを使って実感してみたいと思います。
今回はあくまでパケット解析から見えてくる非SSL環境下でのBASIC認証の中身にフォーカスしてみたので技術的に危険な理由を詳しく述べる事はせず、パケット解析で見えるものに焦点を当てていこうと思います。
WiresharkでBasic認証の流れを見てみる
使用するWiresharkのバージョンは3.0.2macOS版です。今回は以下のディレクトリ構成をlocal上に作り試してみます。
.|-- basic |-- .htaccess |-- .htpasswd `-- index.php認証のユーザー名とパスワードは適当に以下のようにしました。
- user: puihfu4gl
- pass: hgd7g3FGdij
Wiresharkはバージョン3.x系からlocalhostでもキャプチャ出来るLoopbackがキャプチャから選ぶことが出来るようになった様ですので、今回はそちらを使っていきます。
実際にキャプチャを開始して、Basic認証が実装されたページへアクセス → 認証情報入力 → ページが表示されたまでの流れが以下です。
画像のinfoと書かれたカラムを見ると分かりますが、ざっくり動きの流れとしては以下になります。
- 【リクエスト】/basic/をリクエスト（GET）
- 【レスポンス】Authorization Requiredなので401を返す
- 【リクエスト】Authorizationヘッダーにユーザー名とパスワードをセットしリクエスト（GET）
- 【レスポンス】200を返す
3番目でユーザー名とパスワードが合わなければ401レスポンスが返ってくるので再度入力画面に戻り入力を求められるといった具合になります。
BASIC認証が非常に簡素な認証なのが流れからも見て分かりますよね。
では3番目のユーザー名とパスワードを入力する場面のリクエスト詳細を覗いてみます。冒頭で書きましたユーザー名とパスワードが平文に送信されるという点ですが、Authorizationという部分を見ると右側にBase64でエンコードされた文字列が見えます。
更にその下Credentialsを見るとWireshark側で親切にもBase64をデコードされた文字列を見ることが出来ます。最初に設定したユーザー名とパスワードで間違いありませんね。
Authorization: Basic cHVpaGZ1NGdsOmhnZDdnM0ZHZGlq\r\nCredentials: puihfu4gl:hgd7g3FGdijちなみにターミナルでもBase64のデコードは以下の様にすることで可能です。実際に試してみるとこちらも同じ文字列が確認出来ました。
# `\r\n`は改行なので省いて指定$ echo 'cHVpaGZ1NGdsOmhnZDdnM0ZHZGlq' | base64 -Dpuihfu4gl:hgd7g3FGdij見事に平文で送信されているのが確認できましたね。非SSL環境下でのBASIC認証実装が危険な理由が体験出来ました。
パケット解析ソフトさえあればこういった感じで通信のバイパスから解析が出来てしまうので、第三者にBasic認証情報が漏れる事も容易に考えられます。基本的に非SSL環境下では用いない・用いられない物として認識しておきたいものです。
ちなみにこのBasic認証とは別に似た認証方法としてDigest認証がありますが、こちらはMD5でハッシュ化するのでより安全に認証が行えます。Digest認証へ切り替えるのもありでしょう。
ユーザー名とパスワードを平文で確認するだけならブラウザのDevツールなどでもHTTPリクエストを見ると確認することが出来ます。是非試してみて下さい。
