「HTTP Strict-Transport-Security」または「man-in-the-middle」攻撃から身を守り、ブラウザに常にHTTPSを使用させる方法

細部へのこだわりは完璧を生み出し、

しかし、完璧さはもはや些細なことではありません。



ミケランジェロ・ブオナローティ





2012年以降、Webリソース管理者は新しいHTTP Strict Transport Security(HSTS)テクノロジにアクセスしました。これは、HTTPSを介して強制的にセキュアな接続をアクティブにするメカニズムです。 このセキュリティポリシーにより、HTTPを使用する代わりに、すぐに安全な接続を確立できます。 このメカニズムは、特別なHTTP Strict-Transport-Securityヘッダーを使用して、HTTP経由で来たユーザーをHTTPSサーバーに切り替えます[ 1 ]。

HSTSは、攻撃に対する次の脆弱性を解決することを目的としています。
ユーザーはアドレスバーhttp://example.com/をブックマークまたは入力し、「man-in-the-middle」攻撃の被害者になります HSTSは、ターゲットドメインのHTTP要求をHTTPSに自動的に変換します
HTTPSを介して厳密に使用されることになっているWebアプリケーションに、意図せずにHTTPリンクが含まれているか、HTTPを介してコンテンツを提供する HSTSは、ターゲットドメインのHTTP要求をHTTPSに自動的に変換します
攻撃者は、ユーザーが無効な証明書に関するメッセージに注意を払わないように、偽の証明書を使用して被害者のトラフィックを傍受しようとします HSTSは、ユーザーが証明書の問題についてさらにメッセージを表示することを許可しません。
このテクノロジーは可能な限り簡単に有効になります。ユーザーがHTTPS経由でサイトにアクセスしたときに、Strict-Transport-Security HTTPヘッダーをユーザーに返す必要があります:
 厳密なトランスポートセキュリティ:max-age = expireTime [;  includeSubdomains] 


expireTime

このサイトはHTTPS経由でのみアクセスする必要があることをブラウザが記憶する必要がある秒単位の時間。 includeSubdomains(オプション)

このオプションパラメータを指定すると、ルールはすべてのサブドメインにも適用されます。



それは何を与える

WebサイトがHTTP経由の接続を受け入れ、HTTPSにリダイレクトする場合、ユーザーは、たとえばアドレスバーにhttp://example.com/を入力するか、さらに簡単に、 example.com。 これは、元の暗号化されたページの代わりにHTTPリダイレクトがユーザーを攻撃者のサイトに直接送信する中間者攻撃の可能性を開きます。

HTTP Strict Transport Securityメカニズムにより、WebサイトはブラウザーにHTTPを使用しないように通知し、代わりにすべてのHTTP要求をHTTPSに自動的に変換できます。

たとえば、公共の場所にあるオープンWi-Fiアクセスポイントに接続し、お気に入りの銀行のRBを開いて残高を確認し、数回の支払いを行います。 残念ながら、使用しているアクセスポイントは、実際にはHTTPリクエストを傍受し、元の銀行サイトではなくクローンページにリダイレクトする攻撃者のラップトップです。 あなたのデータは直接彼の手に渡ります。

HSTSはこの問題を解決します。 「Strict Transport Security」を使用してHTTPS経由で銀行のWebサイトに少なくとも1回正常に接続すると、ブラウザーはすべてのリクエストに対してHTTSの使用を自動的に開始します。 これにより、上記のタイプの中間者攻撃の可能性が防止されます。



ブラウザの仕組み

HTTPS経由で初めてサイトにアクセスしてStrict Transport Security見出しを返すと、ブラウザは指定された情報を記憶し、HTTP経由でサイトにアクセスしようとするすべての試みは自動的にHTTPSに変換されます。

「Strict-Transport-Security」ヘッダーで指定されたタイムアウトが期限切れになると、HTTP経由でサイトをダウンロードする次の試行が通常モードで発生し、HTTPSへの自動リダイレクトは実行されません。

Strict-Transport-Securityヘッダーが受信されるたびに、ブラウザはタイムアウトを更新します。 サイトにはこの情報を更新し、タイムアウトの期限切れを防ぐ機能があります(何らかの理由でタイムアウトを減らすため)。

ところで、攻撃者はHTTP接続を傍受してヘッダーを置き換えることができるため、HTTP接続の場合、Strict-Transport-Securityヘッダーはブラウザーによって無視されます。 ブラウザは、サイトがHTTPS互換であることを理解し、サイトが証明書エラーなしでHTTPS経由でアクセスされる場合、Strict-Transport-Securityヘッダーを適切に処理します。


ブラウザのサポート



実装の詳細

Strict-Transport-Securityヘッダーは、HTTPSを介してのみ送信する必要があります。 クライアントは、HTTPS応答ではなく、無効で誤って構成された証明書を使用してHTTPS経由で送信されたHSTSヘッダーを処理しないでください。 次の設定はSSLコンテキスト内にある必要があり、コード例はHTTPS応答のコンテキストのみを対象としています。

max-ageディレクティブは数秒で表示されることに注意してください。 以下の例では31536000秒(12か月) Webサーバー管理者がHTTPS経由でのみサイトを使用する予定の期間に応じて変更されました。 31536000(12か月)や63072000(24か月)のように、「max-age」の値を非常に大きく設定することをお勧めします。 [ 3 ]



Apacheの実装
  #モジュールのロード(例としてRHEL / CentOSを使用)
 LoadModule headers_moduleモジュール/ mod_headers.so
 <VirtualHost 10.0.0.1-00-0043>
    #HTTP Strict Transport Securityを使用して、クライアントに安全な接続のみを強制的に使用させる
   ヘッダーは常にStrict-Transport-Security "max-age = 31536000; includeSubDomains"を設定します
 </ VirtualHost> 


Nginxの実装
  add_header Strict-Transport-Security "max-age = 31536000; includeSubDomains"; 


定義済みのHSTSサイト

新たにインストールされたブラウザと照合された設定を持つユーザーが脆弱であるギャップがあります。 このため、ChromeとFirefoxは「事前定義済み」のHSTSリソースのリストを保持しています。 次のドメインは、すぐにHSTSを使用するように構成されています。 サイトの完全なリストは、 http//src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json [ 4 ]で入手できます。



独立した研究の場合:

  1. en.wikipedia.org:HSTS
  2. developer.mozilla.org:HTTP Strict Transport Security
  3. en.wikipedia.org:HTTP Strict Transport Security
  4. dev.chromium.org:HTTP Strict Transport Security
  5. www.owasp.org:トップ10 2010-A9-Insufficient Transport Layer Protection
  6. security.stackexchange.com:このブラウザーがHSTSをサポートしていない場合、WebアプリケーションはIEユーザーをどのように保護できますか?
  7. habrahabr.ru:https上のすべて、安全で安価
  8. habrahabr.ru:安全なWebリソースに向けて。 パート1-サーバーソフトウェア



All Articles