HSTSの動作を検証してみた

セキュリティ

今回は以下の勉強会でnachosさんが発表していた「ヘッダでできるセキュリティ」の「HSTS」のデモが中々印象深かったので、そちらの解説を記事にします。

第19回ゼロから始めるセキュリティ入門 勉強会

なお、記事にするにあたり実際に発表を行ったnachosさんには記事にする許可をいただいております。

HSTSとは

まずは「HSTS」というものを知らない人も多いと思いますので、概要からです。

HTTP Strict Transport Security (エイチティーティーピー・ストリクト・トランスポート・セキュリティ、略称 HSTS)とは、WebサーバーがWebブラウザに対して、現在接続しているドメイン(サブドメインを含む場合もある)に対するアクセスにおいて、次回以降HTTPの代わりにHTTPSを使うように伝達するセキュリティ機構である。RFC 6797で規定されている。
参考:https://ja.wikipedia.org/wiki/HTTP_Strict_Transport_Security

簡単に説明すると、ブラウザに「http://example.com/」と入力してアクセスしようとしても「https://example.com/」でのアクセスに強制してしまうことが可能です。

実際にどうゆうHTTPヘッダで制御されるのか見てみましょう。

どのサイトでそのヘッダが設定されているかというと、googleです。(流石googleですね。)

以下googleにアクセスした際のHTTPレスポンスヘッダです。

HTTP/1.1 200 OK
Date: Sat, 15 Sep 2018 10:27:52 GMT
Expires: -1
Cache-Control: private, max-age=0
Content-Type: text/html; charset=UTF-8
Strict-Transport-Security: max-age=86400
Server: gws
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Set-Cookie: 1P_JAR=2018-09-15-10; expires=Mon, 15-Oct-2018 10:27:52 GMT; path=/; domain=.google.com
Alt-Svc: quic=":443"; ma=2592000; v="44,43,39,35"
Connection: close
Content-Length: 202750

赤いマーカーになっている個所が、「HSTS」を制御しているヘッダです。

「max-age」が設定されていますが、そのサイトに HTTPS だけで接続することをブラウザが記憶する時間となります。(単位は秒です。)

86400となっていますので、アクセスから1日間はHTTPSを強制されることになります。

では検証してみましょう!(結構地味です。)

HSTSの検証

以下のようにブラウザに「http://www.google.com」と入力してアクセスしてみます。

すると以下のようにHTTPSに切り替わります。

プロキシのログを見てみると以下のようになっています。

ブラウザに「http://www.google.com」と入力しましたが、HTTPでの通信は発生せずに、HTTPSの通信しか発生していません。

では比較として、HSTSのヘッダが設定されていないyahooのサイトで同じことをやってみましょう。

まずはヘッダを確認してみましょう。以下のとおりyahooのサイトでは「HSTS」は設定されていませんね。

HTTP/1.1 200 OK
Date: Sat, 15 Sep 2018 11:31:36 GMT
P3P: policyref="http://privacy.yahoo.co.jp/w3c/p3p_jp.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
Vary: Accept-Encoding
Expires: -1
Pragma: no-cache
Cache-Control: private, no-cache, no-store, must-revalidate
X-XRDS-Location: https://open.login.yahooapis.jp/openid20/www.yahoo.co.jp/xrds
Content-Type: text/html; charset=UTF-8
Age: 0
Connection: close
Via: http/1.1 edge2624.img.djm.yahoo.co.jp (ApacheTrafficServer [c sSf ])
Server: ATS
Set-Cookie: TLS=v=1.2&r=1; path=/; domain=.yahoo.co.jp; Secure
Content-Length: 291862

では先ほどのgoogleと同じように以下のように「http://www.yahoo.co.jp」と入力してアクセスしてみましょう。

すると同じようにHTTPSに切り替わります。

あれ?一見変わらないじゃん。と思うかもしれませんが、プロキシのログを見てみましょう。

一件画面上は変わりませんでしたが、ログには一度HTTPで通信した後に「HTTPS」へ301リダイレクトされていることがわかります。

この違いが大きいのです。

具体的には「SSL-Stripping 」という攻撃手法があり、こちらを抑制することができます。
※「SSL-Stripping 」の攻撃手法についてはそのうち実際に攻撃ツールが公開されているので、ツールを使用してデモをお見せする予定です。

最後に

HSTSについて、どういう動きをするかを把握できて頂けたら幸いです。

HTTPSで管理されているサイトについては、ヘッダに設定するだけで効果があるので、一度設定の検討をされてみては如何でしょうか?

経験上、Webアプリケーションの脆弱性診断をしていて、このヘッダが付与されているサイトについては高い確率でセキュアなWebアプリケーションでしたね。

ちゃんと設計段階からセキュリティを考慮されているんだろうなと思います。

また、今回記事にすることを快諾していただいた「nachos」さんの話をさせていただくと、結構昔から交流があり、今は独立して仕事をしている方です。以下は会社のホームページです。

nachosさん会社HP:https://myt-c.jp/

私よりもセキュリティに詳しく、広く交友関係も持っている方なので、セキュリティの相談等あればしていただくと何かしらの力になってくれはずです。
※私から話をすることもできるので、その際はコメント等で連絡いただければ助かります。

不明点や要望やこういったこともやって欲しいとの要望があれば、お問い合わせページやコメント、ツイッターからでも結構ですので、気軽にご連絡ください。

コメント