web-dev-qa-db-ja.com

Javascript httpからhttpsへのリダイレクト-脆弱性/安全性

私がウェブサイトを持っていた場合 http://site.com にリダイレクト https://site.com javascriptを介して（HTTP/1.1 403 Forbidden）、私も脆弱になる可能性のある攻撃ベクトルは何ですか？

なぜこれは良い習慣ではないのですか？ （そして好ましい方法はサーバー側から301を行うことです）

  1. 検索ボットには301が推奨されますが、SEOは問題ありません。
  2. ブラウザでスクリプトを無効にすると、行き詰まります

他に何か？

一つには、私によれば、少なくともMITMを介したセッション固定は不可能です。なぜなら、生の応答が私に与えるものはすべて以下のとおりだからです。クッキーは一切ありません。

<html>
<head><title>hussh...</title></head>
<script language="JavaScript">
function redrToHttps()
{
 var httpURL= window.location.hostname + window.location.pathname + window.location.search;
 var httpsURL= "https://" + httpURL;
 window.location = httpsURL;
}
 redrToHttps();
</script>
<body>

301パーマネントが完璧な選択肢である一方で、インターネット上の多くのチュートリアルがjavascriptを介してそれを行うことを勧める理由がわかりません。私の知る限り、403ヘッダーのJavaScriptを介したこのリダイレクト形式の攻撃ベクトルを見つけることができませんでした。

何か不足していますか？今後直面する可能性のある攻撃の方法はありますか？なぜこれが推奨されない方法なのですか？

編集：

なぜ私がこの質問を投稿したのか言及するのを忘れていたのかもしれません。私はすでにHSTSを使用するためのフラグを立てましたが、問題のWebサイトにはありませんでした。私の懸念は、このアプリケーションを開発した人々がgoogleの最初のリンク（開発当時）をたどり、JavaScriptを介してこのhttpからhttpsへのリダイレクトを行っていたことです。正直なところ、Javascriptを介してアプリケーションのすべてのページでhttpからhttpsへのリダイレクトを見たのはこれが初めてです。私はあなたにどれほど悪いことを言っている必要はありません、そして最初からさえ、javascript httpsリダイレクトが聞こえるのはばかげています。しかし、私は生の応答を調べました、それを行う最良の方法ではありませんが、403（大丈夫です、あなたは禁止されています）で問題ありませんでした。

このサイトはhttp経由で情報を提供することはありません。常にJavaScriptを使用して リダイレクトを行う 新しいリクエストを行います。残念な。わかった。これがどれほど影響を受けやすいかについてのあなたの答え/考えかもしれませんが、これがセキュリティの面でこのような悪い考えである理由の販売を手伝っていただけませんか。

Stackexchangeネットワークの質問で、javascriptを介したhttpからhttpsへのリダイレクトのセキュリティへの影響について具体的に説明していないため、これは重複の可能性がないと思います。ベストプラクティスを分けて、このアプローチがどれほど安全ではないか（そしてなぜそうであるか）についてのあなたの考えに感謝します。

別のページに移動するようにブラウザーに指示するカスタムクライアント側スクリプト、および http://Paypal.com のようにブラウザーが301に応答する場合、根本的な違いがあると思います。彼らはこのケースで実証されたエクスプロイトを知っていますか？

ありがとうございました。

編集2：誰かが403に気づきましたか？ IIS 6では、require HTTPSを有効にしていて、HTTP経由でサイトにアクセスしようとしていて、SSLを適切に構成していなかった場合、403の鈍いエラーページが表示されます。昔のクイックフィックスソリューションは、サーバーで403をトラップし、質問で述べたようなJavaScriptコードを含むカスタムエラーページを返すことです。そのJavaScriptは、新しいブラウザリクエストであるページのHTTPSバージョンをリクエストします。 、いかなる種類のリダイレクトでもありません。これは実際には新しいhttpsリクエストと同等です。これは悪い、非常に悪い、不適切な実装です。しかし問題は、httpでリソースをリクエストすると、403が返されます= Java httpsをURLに追加して、新しいhttpsリクエストを発行するのに役立つスクリプトです。301/ 301によるHTTPSではありません。質問のタイトルはWordリダイレクトを示している可能性がありますが、2番目ここで、誤称についての考え。物事をここに視点で説明することは、投稿です http://raoulpop.com/2007/08/07/automatic-redi rect-from-http-to-https / 私が言っていることを説明します。確かに非常に古い投稿。これは重複する質問ですか？

tlsjavascriptman-in-the-middleurl-redirectionsession-fixation
2
gmaran23

ブラウザでJavaScriptを使用してこれを行うのは安全でなく、非効率的です。

すでに述べたように、ユーザーエージェントがJavaScriptを実行しない場合、ユーザーは403 Forbiddenページに座っているだけです。ユーザーに403応答を返す場合は、なぜ301を返して応答を使用しないのですか？これはせいぜい悪いユーザーエクスペリエンスであり、https URLの代わりにリダイレクトされるべきhttp URLに頻繁にアクセスすることになります。

セキュリティの観点からは、ユーザーをMiTMからの攻撃にさらすことになります。ユーザーがプロトコルを指定せずにsite.comに入力すると、ブラウザはデフォルトでHTTPになり、 http://site.com にリクエストを送信します。リダイレクトがJavaScriptで行われる場合、ブラウザーは記憶しません。サーバーが https://site.com への301永続リダイレクトで応答する場合、ブラウザはこの応答をキャッシュします。ユーザーが次にsite.comに入力したときに、ブラウザーは以前のように http://site.com ではなく https://site.com にアクセスします。これは、さまざまな形式の SSLストリッピング攻撃 を緩和するのに役立ちますが、完全なソリューションではありません。それでも、少し安全です。

また、ドメインにHSTSポリシーを発行することもできます。 HSTSの詳細については、ブログの " HSTS-The Missing Link In Transport Layer Security "というタイトルで詳しく説明しました。簡単に言えば、HSTSを使用すると、リダイレクトを必要とせずにhttpsを常に使用するようブラウザに指示できます。非準拠のユーザーエージェントのリダイレクトを維持する必要がありますが、これは正しい方向へのもう1つのステップです。

1
Scott Helme