ビットスクワッティングからウェブサイトをどのように保護できますか？
私は bitsquatting （人気のあるドメインとは少し異なるドメイン名の登録を指す）に関する記事を読んだばかりで、攻撃者が自分のドメインをロードする方法を心配しています私のウェブサイト上の資産。
たとえば、https://www.example.org/にある私のWebサイトがhttps://www.example.org/script.jsにあるスクリプトファイルをロードする場合、攻撃者はdxample.orgを登録し、悪意のあるJSファイルをホストする可能性があります。私のウェブサイトのユーザー。
それに対する標準的な防御手法はありますか？
それに対する標準的な防御技術はありますか？
他の回答で概説されているように、ドメイン名をクエリする際のビットエラーは、Webアプリケーションにとって現実的な脅威ではない可能性があります。しかし、そうであると仮定すると、サブリソースの整合性（SRI）が役立ちます。
SRIでは、次のように、ロードしているリソースのハッシュをintegrity属性で指定しています。
<script src="http://www.example.org/script.js"
integrity="sha256-DEC+zvj7g7TQNHduXs2G7b0IyOcJCTTBhRRzjoGi4Y4="
crossorigin="anonymous">
</script>
今後は、ビットエラーが原因でスクリプトが別のドメインからフェッチされた（またはMITMによって変更された）かどうかは関係ありません。コンテンツのハッシュが一致しない場合、ブラウザはスクリプトの実行を拒否するためです。整合性の値。そのため、ビットエラーなどで攻撃者が制御するdxample.orgにURLを解決させた場合、正常に挿入できるスクリプトは、ハッシュに一致するスクリプト（つまり、ロードしようとしたスクリプト）だけです。 ）。
SRIの主な使用例は、信頼できない可能性のあるCDNからスクリプトとスタイルシートをフェッチすることですが、要求されたリソースが変更されていないことを確認する必要があるすべてのシナリオで機能します。
現在のところ、SRIはscriptおよびlinkに制限されていますが、他のタグのサポートは後で提供される可能性があります。
注：この仕様の将来の改定の可能性が高い可能なすべてのサブリソース、すなわち、
a、audio、embed、iframe、img、link、object、script、source、track、およびvideo要素のための整合性のサポートを含めることです。
あなたの懸念は根拠がない可能性が非常に高いです。
まず、これらのメモリの誤動作がどれほど起こりにくいかを理解する必要があります。上記の記事を書いた人は、7か月の間にインターネット上で最も訪問されたドメインのいくつかの32のクローンへのリクエストを記録しました。これら52,317件のヒットは、数十億件数十億件のリクエストでした。 Facebookの規模でWebサイトを運営しているのでなければ、ビットスクワッティングドメインに1人の不運な犠牲者を招く場合でも、攻撃者は非常に幸運である必要があります。
次に、メモリエラーがいくつかの誤動作を引き起こすことに注意する必要があります。著者は書いている：
これらのリクエスト[...]は、いくつかのビットエラーの兆候を示しています。
被害者のシステムが非常に壊れているため、severalビットエラーなしでHTTPリクエストを送信することさえできない場合、そこからダウンロードするマルウェアはエラーなしでは実行されない可能性があります。それはその状態で起動することさえできた奇跡です。
また、「Webアプリケーションキャッシュ、DNSリゾルバー、およびプロキシサーバー」でビットエラーが見つかり、複数のユーザーに影響を与えた場合（一部のユーザーは、実行可能な状態でマルウェアを十分に入手できないほど運が悪い）： 、HTTP応答は、クライアントが要求したサーバーとは異なるサーバーから送信されます。したがって、HTTPSのみを使用する場合（私はそうだと思います。そうしないと、はるかに深刻な攻撃が心配になるでしょう）、その署名はチェックアウトされず、ブラウザーはそのリソースをダウンロードしません。
また、ルートにRAM=が壊れているシステムがある場合、HTTPSは接続が成功する可能性を大幅に低下させます。TLS暗号化メッセージの単一のビットフリップにより、チェックアウトからハッシュするので、受信者はそれを拒否します。
tl; dr：心配する必要がなくなり、HTTPSのみを設定します。
記事の信頼性には疑問があります。 DEFCONで議論され、ホワイトペーパーとして公開されていますが、実験結果について深刻な懸念があります。
@mootmootのコメントによると、著者はビットのランダムな変動から確定的プログラミングエラーを特定できませんでした。
私の懸念の声明は
ロギング期間中[9月2010年5月、2011年5月、ndr] 12,949個の一意のIPアドレスからの合計52,317ビットクォート要求がありました
いいえ、作者は自分のスクワットドメインへの接続を証明しただけで、追加情報を提供できなかった可能性があります
- そのトラフィックが元のCDNネットワークの何パーセントを表しているか（これは理論的に検証可能ですが、これらの数値はありません）
- ソース参照ドメインの発生
2番目は、確定的なプログラミングの失敗をランダムなビットの変動から分離するのに役立つため、非常に重要です。
次の例を考えてみます。リファラーgbcdn.netを使用してhttps://facebook.com（facebook squat）へのエントリを見つけた場合、ビットスクワットを見つけた可能性があります。
逆に、あまり知られていないwebisteから複数のエントリを見つけて、それらを調べて見つけることができる場合壊れたlikeボタンを使用の場合、問題はおそらくプログラマがコードを正しくコピー/貼り付けしていないか、またはプログラマのIDEで少しだけフリップが発生しました。知るか...
免責事項：私はEmaze Networks S.p.Aの従業員です。
この種の攻撃を防ぐ1つの方法は、攻撃者が同様のドメイン名を登録できないようにすることです。
これを達成するために、メインドメイン名と一緒に多くのビットクォート/タイプミスクォートドメインを登録できますが、これはすべてのビットクォート/タイプミスクォートのケースでは不可能です。なぜなら、それらは数十億になる可能性があるためです（ユニコードなども考慮してください）。
別の方法としては、登録されているドメインを定期的に監視し、疑わしいドメインを見つけた場合はその動作を確認し、悪意のあるサイトのように思われる場合はレジストラに報告して、その所有権を渡すよう依頼することができます。あなたにドメイン。
さまざまなソースからのレジストラー情報を集約し、さまざまな種類のクエリを実行してビットスクワッティング/タイポスクワッティング/プニーコードスクワッティングドメインを検出することで、これを行う Precog と呼ばれる小さなサービスがあります。ブランドを登録して、いくつかのキーワードと不審なドメインが登録されている場合はご連絡いたします。
私たちのツールは明らかに第2レベルのドメインを考慮に入れていますが、多くの第3（またはそれ以上）レベルのドメインの登録を検出することもできるため、誰かが行っていることを検出できるかもしれませんapp1e.account.comを使用してApple資格情報を盗み取ろうとします。
追加する必要があります。この種の攻撃の最大の使用例は、誰かがドメインを誤って入力したためにリクエストを受信できる「幸運」ではなく、ドメインをフィッシングドメインとして使用することだと思います。したがって、人々はサイトàpple.comを登録し、Appleの電子メールのように見える大量の電子メールを送信し、何人かの人々に自分の資格情報/クレジットカード情報を自分のページに挿入させようとします。
すべての回答の中で、 コンテンツセキュリティポリシー への言及を見ていないことに驚いています。
基本的に、許可されたコンテンツソースをホワイトリストに登録するためのワンストップソリューションです。単純な修正は、現在のドメイン（www.example.com）からのJavaScriptのみを許可し、その他すべてをブロックすることです。
アルミニウスの答えは素晴らしい。強力な コンテンツセキュリティポリシー をビットスクワッティングに対する別の防御線として使用することもできます。
CSPは、Webサイトが通信できるURIの細かいホワイトリストを作成できるHTTPヘッダーです。たとえば、JavaScriptにexample.org/js/file1.jsからのアクセスのみ、example.com/imgsからの画像、example.netからのフォントのみを許可することをブラウザに指示できます。
ビットスクワット攻撃が成功するためには、HTTPヘッダーとリクエストでビットを反転させる必要があります。攻撃者が1ビットしかフリップできない場合、どのビットをフリップしたかに関係なく、Webサイトは多くのエラーをスローします。