3

FirefoxまたはChromeで、プライベートWebページが発信接続を確立しないようにしたい。つまり、ブラウザタブでURLがhttp：// myprivatewebpage /またはhttps：// myprivatewebpage /で始まる場合は、そのブラウザタブを制限する必要があります。これにより、画像、CSS、フォント、JavaScript、XmlHttpRequest、Javaアプレット、フラッシュアニメーション、およびその他すべてのリソースをhttp：// myprivatewebpage /またはhttps ：// myprivatewebpage/からのみロードできるようになります。 myprivatewebpageにないので、その画像をロードできます。myprivatewebpageの外部にある単一のリソースでさえも100％確実なソリューションが必要です。<img src="http://www.google.com/images/logos/ps_logo.png"><script>new Image(...)低い確率でさえもアクセス可能である可能性があります。myprivatewebpage以外のWebページにリソースの読み込み制限があってはなりません。たとえば、http：//otherwebpage/はgoogle.comから画像を読み込める必要があります。

myprivatewebpageのユーザーは、あまり手間がかからない限り、Webページを非公開にするために協力してくれると思います。たとえば、ChromeまたはFirefoxの拡張機能を一度インストールすると、サポートされているブラウザに拡張機能をインストールするまでmyprivatewebpageへのアクセスが拒否されたことを示すエラーメッセージが表示されても、気分を害することはありません。

この制限が必要な理由は、 myprivatewebpageの使用に関する情報を他のウェブページのウェブマスターに公開せずに、myprivatewebpageを本当にプライベートに保つためです。http://www.google.com/images/logos/ps_logo.pngが許可されている場合、myprivatewebpageの使用はGoogleのaccess.logに記録されるため、Googleのウェブマスターはmyprivatewebpageの使用ps_logo.png方法に関する情報を入手できます。私はそれを望んでいません。（この質問では、制限が妥当であるかどうかには関心がありませんが、技術的な解決策とその長所と短所にのみ関心があります。）

制限を実装する方法についての私の考え：

  • 制限を課すのではなく、同一生成元ポリシーに依存するだけです。（これは必要な保護を提供しません。同一生成元ポリシーにより、すべての画像が通過できます。）

  • サーバー上のWebアプリケーションを変更して、myprivatewebpageの外部に何もロードしようとしないHTML、JavaScript、Javaアプレット、フラッシュアニメーションなどを生成するようにします。（これは、特にユーザー生成コンテンツの場合、複雑なWebアプリケーションのどこでも絶対に確実にするのはほとんど不可能です。）

  • サーバーでHTML出力フィルターを使用してWebページを過度にサニタイズします。つまり、すべての<script>、<embed>および<object>タグを削除し、、などのターゲットを<img src=制限し<link rel=、<form action=CSSファイル内のリンクも制限します。（これにより、すべてのHTMLタグを適切に記憶できれば、すべての不要なリソースを防ぐことができます。たとえば、忘れてはなりません<video>。ただし、これは制限が厳しすぎます。JavaScript、Javaアプレット、フラッシュアニメーションなどの動的なWebページ機能がすべて削除されます。これらのほとんどのWebがない場合アプリケーションは役に立たない。）

  • Webページをサニタイズします。つまり、HTML出力フィルターをWebサーバーに追加して、生成されたHTMLからすべての問題のあるURLを削除します。（これは、許可されていないURLを生成するトリッキーなJavaScriptが存在する可能性があるため、絶対確実ではありません。また、JavaアプレットやフラッシュアニメーションによってロードされるURLからも保護されません。）

  • URLとHTTPリファラーに基づいてリクエストをブロックするHTTPプロキシをインストールし、そのHTTPプロキシを介してすべてのブラウザトラフィック（myprivatewebpage、otherwebpage、google.comを含む）を強制します。（これにより、 myprivatewebpage以外へのトラフィックが遅くなり、XmlHttpRequest（）、Javaアプレット、またはフラッシュアニメーションがHTTPリファラーを偽造できる場合は適切に保護されない可能性があります。）

  • すべての発信接続をインターセプトし、タブのURLと接続のターゲットURLに基​​づいてそれらをブロックするFirefoxまたはChrome拡張機能を検索または記述します。https://developer.mozilla.org/en/Setting_HTTP_request_headersとhttps://addons.mozilla.org/en-US/firefox/addon/thinkahead/およびhttp://thinkahead.mozdev.org/thinkahead.jsで見つけました。それを使ってFirefox拡張機能を書くことは可能だと私は正しいですか？そのようなFirefox拡張機能はすでにありますか？

Chrome拡張機能について私が見つけたいくつかのリンク：

私が見る限り、上記のリストからFirefoxまたはChrome拡張機能のみが実行可能です。他に何か提案はありますか？そのような拡張機能の書き方や場所を教えてください。

4

1 に答える 1

1

https://addons.mozilla.org/en-US/firefox/addon/thinkahead/とhttp://thinkahead.mozdevでhttps://developer.mozilla.org/en/Setting_HTTP_request_headersとthinkahead.jsを見つけました.org/。それを使ってFirefox拡張機能を書くことは可能だと私は正しいですか？そのようなFirefox拡張機能はすでにありますか？

私は後者の拡張機能の作成者ですが、Firefoxの新しいバージョンをサポートするようにまだ更新していません。私の最初の推測は、はい、それはあなたが望むことをするだろうということです：

  1. ユーザーがプラグインなしでWebページにアクセスします。Webページには、サーバーに単純なバージョンヘッダーを送信するThinkAheadブロックが含まれていますが、プラグインがインストールされていないため、これは無視されます。
  2. サーバーはそのヘッダーを認識しないため、プラグインをインストールするページにクライアントをリダイレクトします。
  3. ユーザーがプラグインをインストールします。
  4. ユーザーがプラグインを使用してWebページにアクセスします。ページはバージョンヘッダーをサーバーに送信するため、サーバーはアクセスを許可します。
  5. ThinkAheadブロックは、そうでない すべてのページに一致しmyprivatewebpage、HTTPステータスを403Forbiddenに設定するようなことを行います。したがって：
  6. ユーザーがにあるWebページにアクセスすると、myprivatewebpage通常の動作が行われます。
  7. ユーザーがの外部のWebページmyprivatewebpageにアクセスすると、アクセスは拒否されます。

着信ヘッダーを変更する代わりに、不良リクエストを早期にキャッチしたい場合は、発信ヘッダーを変更して、リクエストが尊重されないように「If-Match」または「Accept」を台無しにすることができます。

このソリューションは非常に軽量ですが、懸念事項に対して十分な強度がない可能性があります。これは、保護する対象によって異なります。上記の場合、クライアントはブロックされたコンテンツを表示できませんが、外部の「ブロックされた」ホストは、リクエストが送信されたことに気づき、リクエストから情報を収集できる可能性があります。 URL。

于 2012-01-26T16:39:56.143 に答える