web-dev-qa-db-ja.com

ブラウザーがHSTSをサポートしていない場合、Webアプリケーションはユーザーをどのように保護できますか？

HTTP Strict Transport Security （HSTS）は OWASP a9違反 および SSLStrip のような攻撃を防止するのに非常に便利な機能であり、クライアントが安全な接続。ただし、このテクノロジーは古いバージョンのWebブラウザー（特にIE）にはありません。 2015年6月 MicrosoftfinallyがHTTP Strict Transport SecurityのサポートをIE 11 に追加しましたWindows 7、8.1、10。Microsoft Edgeもサポートしています。どちらも、Chromiumプリロードリストにあるサイトに対してHSTSプリロードを実行します。ただし、すべてのユーザーが最新のWebブラウザーを使用するわけではありません。

では、HSTSをサポートしていないブラウザでユーザーをどのように保護するのでしょうか。安全でないクライアントにコンテンツを提供しているにもかかわらず、Webアプリケーションが提供できるトランスポートセキュリティの「最高」レベルは何ですか？

（この質問を提起するためにタイラールに叫んでください。）

tlsman-in-the-middlehstsinternet-explorer
26
rook

できません。

最善の方法は、SSLをサイト全体で使用することです。すべてのHTTP接続で、ユーザーをHTTPSにすぐにリダイレクトします（HTTPS経由でフロントページにリダイレクトします。たとえば、http://www.example.com/anything.htmlはhttps://www.example.com/にリダイレクトする必要があります）。 HTTPを介してコンテンツを提供しないでください（HTTPSを介してフロントページへの即時リダイレクトを除く）。すべてのCookieにsecureフラグを設定します（明らかに）。

これは、ユーザーをHTTPにダウングレードする中間者攻撃を阻止するものではありません。 HSTSがなければ、そのような攻撃を防ぐことはできません。

それ以上のことはできません。しかたがない。それがIEとの関係です。

SSLstripを防御するときのオプション？ も参照してください。

22
D.W.

明らかに、発生する可能性のある攻撃を防ぐ方法はありませんbeforeトラフィックがサーバーに到着することすらあります。その時点で影響を与える立場にないだけです。

ただし、非SSLトラフィックが送信されないようにするためにできることの1つは、非SSLリンクを意図的に切断することです。通常、ウェブマスターはリンクを公開する前に少なくとも1回テストするため、プロトコルをhttpsに変更する必要があるという点で、それらの手がかりになります。

これを行う簡単な方法は、代わりに、安全でないリンクを介してアクセスしたことをユーザーに警告し、「ブックマークを更新する」ように指示するページを表示し、httpsリンクを提供して目的の場所に進むことです。それはかなり邪魔にならず、normalユーザーをあまり妨げませんが、とにかくこのタイプのキャンペーンのターゲットであるWebデザイナーにヒントを与えます。

おそらく、このページに404ステータスコードを付けて、実際のコンテンツとして解釈されないようにする必要があります。欠点は、検索エンジンが302リダイレクトに依存して、正しいページを指すようにインデックスを更新することです。 404を返すと、リンクをhttpsに更新するのではなく、インデックスから削除します。したがって、ボットに302を送信し、ブラウザを404の「リンクの更新」ページに送信することができます。

7
tylerl

HSTSはSSLStripに対する唯一の保護ですが、攻撃を防ぐために次の予防策を講じることができます。

  1. Webアプリケーションに 混合コンテンツの脆弱性 がないことを確認します。これは、他のドメインからJavaScript over HTTPをプルすることを防ぐことができないため、実際にはHSTSを超えています。

  2. セキュリティ問題の一般的な解決策は、[〜＃〜] education [〜＃〜]です。安全でないブラウザを使用していること、およびChromeまたはFirefoxの使用を検討する必要があること）をユーザーに目立たないメッセージで伝えます。

  3. Http cookieに "secure"フラグを設定します（ただし、とにかく全員がこれを行う必要があり、SSLStripが停止することはありません）。

  4. 各ページにJavaScriptを導入して、ページがHTTP経由でロードされたかどうかを検出し（HSTSのために不可能です）、ユーザーがWebアプリケーションを使用できないようにします。 YOU ARE UNDER ATTACKと言って大きなREDウィンドウを表示します。これは、標的のMITM攻撃で削除できますが、攻撃者が盲目的にSSLStripを使用している場合は削除できません。

6
rook

最初に頭に浮かぶのは、関連するページでSSL接続のみを受け入れ、HTTP接続を許可しないようにサーバーを設定することです。これにより、機密性の高いものを平文でユーザーに送り返すサーバーは無効になりますが、最終的には、ユーザーへの安全でない接続を作成できるアクティブなMITMを停止することはありませんが、攻撃者からサーバーへのSSL接続に変換します。 。

最終的に、それ以上のことができるかどうかはわかりませんが、クリアテキストでデータを送信してはならないことをクライアントに通知するメカニズムがないと、伝えられた内容はすべて受け入れられます。

これは別のポイントをもたらしますが、HSTSについてはよく知りませんが、HTTPSは通常クライアント証明書では使用されないため、ホストとクライアント間の直接通信を妨害できるアクティブな攻撃者はHSTSを単純に取り除くこともできます。 。ユーザーには最初は安全な接続が表示されませんが、ユーザーがHTTPSであるべきか、またはすべきでないかをユーザーが信頼できない場合は、実際には、追加できるものはそれほど多くありません。 HTTPSも削除されることを確認します。

別のアイデアとして、接続タイプをチェックして警告を表示するようなJavaScript呼び出しを行うことも考えられますが、これもアクティブな攻撃者によって取り除かれる可能性があります。 https://stackoverflow.com/questions/414809/how-do-i-determine-whether-a-page-is-secure-via-javascript

3
AJ Henderson