15

私が開発を支援している製品は、基本的に次のように機能します。

  • <script>Web パブリッシャーは、当社のサーバーからのを含むサイトに新しいページを作成します。
  • 訪問者がその新しいページに到達すると、ページのテキスト コンテンツが収集され、POST リクエスト (クロスドメイン、 の内部を<script>使用) を介してサーバーに送信されます。<form><iframe>
  • サーバーはテキスト コンテンツを処理し、Web 上の関連コンテンツへのリンクを一覧表示する HTML フラグメントを含む応答を ( JSONP経由で) 返します。この応答は、同じ URL からテキスト コンテンツを含む別の POST 要求を受信するまでキャッシュされ、後続の訪問者に提供されます。その時点で、「新しい」応答が再生成されます。これらの POST は、キャッシュされた TTL が期限切れになったときにのみ発生します。その時点で、サーバーはそれを通知<script>し、ページ上でテキスト コンテンツを収集して再度 POST するように促します。

問題は、このシステムが本質的に安全ではないように見えることです。理論的には、誰でもページのコンテンツをサーバーに送信する HTTP POST リクエスト (リファラー ヘッダーを含むため、それを確認することはできません) を偽装することができます。これには、そのページの関連コンテンツ リンクを生成するために使用する任意のテキスト コンテンツを含めることができます。

これを安全にする上での主な問題は、JavaScript が公開されていることです。秘密鍵ではないため、秘密鍵やその他の暗号化された識別子やパターンを使用することはできません。

理想的には、特定の Web ページに対応する POST 要求が本物であることを何らかの形で検証するメソッドが必要です。JavaScript にコンテンツを送信させる目的は、ログイン システムの背後にある可能性があるためです。

何か案は？問題を十分に説明できたことを願っています。ご提案いただきありがとうございます。

4

10 に答える 10

7

これには喫煙銃はありません。ただし、大きな銃が存在しない場合、大きな迷惑が発生する可能性があります. ハッカーは挑戦を好みますが、簡単な標的を好みます。彼らがあきらめるほど迷惑になります。

Google などは、広告の言葉を使ってこれを効果的に行っています。API トークンを作成し、それを送信してもらいます。スクリプトを使用するサイトの「検証」プロセスを用意します。このプロセスでは、このスクリプトの登録者が、スクリプトを使用する前にサイトのプロファイリングを許可する必要があります。次に、問題のサーバーに関するすべての情報を収集し、サーバー プロファイルが記録されているものと一致しない場合は、要求できます。

ブラウザとクライアントについて知っていることをすべて入手し、そのプロファイルを作成します。ブラウザのなりすましである可能性がある場合は、リクエストをドロップしてください。プロファイルが繰り返されても Cookie がなくなった場合は、入力を無視します。短期間にトークンから複数のリクエストを受け取った場合 (つまり、ハッキングの試みに固有の急速なページの更新)、そのリクエストを無視してください。

次に、さらに一歩進んで、実際のドメインに ping を実行し、そのドメインが存在し、承認されたドメインであることを確認します。ページがログインの背後にある場合でも、ドメインは引き続き応答します。これ自体はハッカーを阻止しませんが、サーバー側で実行されるため、隠されています。

また、ページのコンテンツのプロファイリングを検討することもできます。キッチン用品専門のサイトが成人向けの出会い系コンテンツを送り返し始めたら、危険信号を上げてください。

最後に、悪いリクエストとしてプロファイリングした悪いリクエストが届いた場合は、適切であることがわかっているデータ (ページの 24 時間前のバージョンなど) に基づいて、そのページの適切なリクエストとなるものから JSONP を送信します。 . ハッカーがそこにいることを知っていることをハッカーに言わないでください。すべてが順調であるかのように振る舞う。それを理解するにはかなり時間がかかります！

これらのアイデアはどれも、あなたの質問のニーズを正確に満たすものではありません。

于 2011-10-27T22:40:20.747 に答える
4

これはどう？-<script/>サード パーティのサイトに含まれるタグには動的src属性があります。したがって、静的な Javascript リソースをロードする代わりに、サーバーに来て、Web サイトの識別子として一意のキーを生成し、JS 応答でそれを返します。ユーザーセッションまたはデータベースに同じキーを保存します。この JS コードによって作成および送信されたフォームは、このキー パラメータも送信します。バックエンドは、db/session のキーと一致するキーを持たない POST リクエストを拒否します。

于 2011-11-09T08:05:33.523 に答える
1

まず最初に、ここで他の人が提案しているようにドメイン（およびおそらく「サーバープロファイル」）を検証し、明らかに非常に厳密にPOSTのコンテンツを検証します（とにかくすでに行っていることを願っています）。

スクリプトファイルのURLがサーバーによって動的に生成されるものを指すようにする場合は、POSTとともに送信される時間依存のセッションキーを含めることもできます。これはだれも完全に失敗させることはありませんが、セッションを十分に早く期限切れにすることができれば、悪用するのははるかに困難になります（そして、私がアプリケーションを正しく理解していれば、セッションはユーザーにとって十分長く続く必要がありますページを読み込んだ後に何かを入力します）。

これを入力した後、私はそれが基本的にavleshが有効期限を追加してすでに提案したものであることに気付きました。

于 2011-11-17T17:30:59.133 に答える
1

ドメインごとにキーを人々に与えます。

[キー文字列 + リクエスト パラメータ] の値のハッシュをリクエストに含めます。(ハッシュ値はサーバー上で計算する必要があります)

リクエストが送信されたら、パラメーターとキーを知っていれば、有効性を確認できます。

于 2010-04-02T18:53:02.353 に答える
1

あなたが説明したシステムの主な弱点は、ページのコンテンツが「与えられている」ことです。自分でページのコンテンツを取得してみませんか?

  1. Web 発行者は、サーバーからのスクリプトを含む新しいページをサイトに作成します。
  2. 訪問者がその新しいページに到達すると、そのスクリプトは取得リクエストをサーバーに送信します。
  3. サーバーがページのコンテンツを取得します (おそらく、リファラー ヘッダーを使用してリクエストのソースを特定します)。
  4. サーバーはテキスト コンテンツを処理し、Web 上の関連コンテンツへのリンクを一覧表示する HTML フラグメントを含む応答を (JSONP 経由で) 返します。この応答はキャッシュされ、サーバー側のキャッシュ/プロキシから後続の訪問者に提供されます
  5. キャッシュされたバージョンの TTL が期限切れになると、プロキシはリクエストをアプリに転送し、サイクル全体がステップ 3 から再び開始されます。

これにより、悪意のあるコンテンツがサーバーに「フィード」されるのを防ぎ、リクエストとドメインまたはページを結び付ける何らかの形式の API キーを提供できるようになります (つまり、API キー 123 は mydomain.com のリファラーに対してのみ機能します。それ以外は明らかになりすましです)。 . ページ コンテンツはキャッシュ TTL の有効期限が切れるたびに 1 回しか処理されないため、キャッシング/プロキシにより、アプリはあらゆる形式の DOS タイプの攻撃からもある程度保護されます (そして、TTL を拡張することで、増加する負荷を処理できるようになります。追加の処理能力をもたらすことができます)。これで、クライアント側のスクリプトは非常に小さくシンプルになりました。コンテンツをスクレイピングして投稿する必要はありません。ajax リクエストを送信し、いくつかのパラメーター ( api キー / ページ ) を設定するだけです。

于 2010-04-05T23:04:48.933 に答える
0

サイトをスクレイプすることができます。スクリプトを含むコード200の応答を受け取った場合は、そのスクレイプを使用してください。そうでない場合は、「クライアントプロキシ」からの情報に解決できる可能性があります。そうすれば、問題はスクレイプできないサイトにあります。

このような場合のセキュリティを強化するために、複数のユーザーがページを送信し、最小数の応答に存在しない情報を除外することができます。これには、ユーザー固有のコンテンツを除外するという追加の利点もあります。また、プロキシ作業を依頼するユーザーを登録し、仕事を依頼したユーザーからのページのみを受信することを確認してください。また、非常にアクティブなユーザーが仕事をする可能性が高くならないようにすることもできます。これにより、仕事を「釣り上げる」ことが難しくなります。

于 2010-04-06T00:14:32.457 に答える
0

各クライアントの IPアドレスに固有のキーをハッシュし、ポスト ヘッダーの IP を使用して各ポストのサーバーでその値を比較することができます。これの利点は、誰かが自分の IP をスプーフィングした場合でも、応答は攻撃者の IP ではなくスプーフィングされた IP に送信されることです。あなたはすでにこれを知っているかもしれませんが、ハッシュにソルトを追加することもお勧めします。

スプーフィングされた IP では、適切な TCP ハンドシェイクが行われないため、攻撃者によるスプーフィングされた投稿は完了しません。

私が気付いていない他のセキュリティ上の懸念があるかもしれませんが、それはオプションかもしれないと思います

于 2010-04-03T23:00:13.770 に答える
0

Web パブリッシャーは、サーバーにプロキシ ページを配置することもできますか?

次に、プロキシ経由でスクリプトをロードします。次に、2 つのサーバー間の接続を制御したり、暗号化を追加したりできる可能性がいくつかあります。

ログインシステムとは？SSO ソリューションを使用してスクリプトを分離しておくのはどうですか?

于 2010-04-05T17:39:04.263 に答える
0

サイトにデータをプッシュするサーバー側のコードをサイトに追加できる場合は、MAC を使用して、少なくともログインしていないユーザーが何かを送信するのを防ぐことができます。

誰もがページを使用できる場合、Web ページをスクレイピングせずにデータを確認する防水方法は考えられません。リファラー チェックなどを使用して、任意のコンテンツの送信をいくらか難しくすることはできますが、100% 不可能というわけではありません。

于 2010-04-01T16:45:03.880 に答える
-1

どうですか：

サイト A はノンス (基本的にはランダムな文字列) を作成し、それをサイト B に送信してセッションに入れます。次に、サイト A がサイトから POST 要求を行うと、要求と共にナンスが送信され、サイト B のセッションのナンスと一致する場合にのみ要求が受け入れられます。

于 2010-04-02T18:25:30.170 に答える