8

私はこれを理解するのに本当に苦労しています。私を救うためにウェブをクロールするのに約4時間費やしました。

シナリオを想像してみてください。

  1. Webページでの特定のアクション（主にボタンのクリック）をキャプチャするChrome拡張機能をすでに作成しました。そのアクションは、いくつかのユーザー情報とボタン情報（すべてページ自体に存在する）をキャプチャして表示する関数をトリガーします

  2. 今、私はプラグインがこれをリモートサーバー上のデータベース設定に更新できるようにしたいと思っています。

私はPHPに精通しているので（したがってMySQLが良い選択です）、更新が拡張機能自体からのみ行われるようにするための解決策を探しています。

このための最良のオプションは、http：//remoteserver.tld/update-db.php？id = XXXX＆action = YYYYY＆foo =bar ...などのようなGET/POSTリクエストを実行することだと思います。ユーザーはプラグインの外部でこのURLにPOST変数を開く/渡しますか？

データは引き続き更新され、整合性が失われます。

次善の策は、リクエストにキーを含めることでしたが、拡張機能はJSで記述されているため、ほとんどの人がキーを盗聴できます。

リモートサーバー上のデータベースを更新し、アクションが認証されていることを確認するための最良の方法を教えてください。

乾杯！

4

1 に答える 1

2

ここでの問題は基本的に認証の1つであり、誰もが他の誰かのデータストアを更新できないようにする必要があります。

これに対する最も明白な修正は、列挙するのが難しく（ハッシュが良い例です）、拡張機能の単一のインスタンスにのみ割り当てられる（したがって、すべてのユーザーが独自の認証ハッシュを生成する）追加のパラメーターを送信することです。

このハッシュを有効にするには、推測できないことが重要です。ip-adressessやユーザーエージェント文字列などの静的なものだけに基づいてハッシュを作成しないでください。

これらの静的文字列を含めて、衝突の可能性を低くすることができます：[pseudo] sha1（ip_address + user_agent + random_integer）。

したがって、基本的にこれは次のようになります。拡張機能が初めて実行される場合は、現在のインスタンスのハッシュを生成し、サーバーに最初のリクエストを行って、この新しいインスタンスを「登録」します。これ以降のすべてのリクエストには、これが含まれます。ハッシュはそのインスタンスに対して認証されます。

また、SSL暗号化接続を使用して、スニッフィングを防止します。

人々が気付くように、あちこちでXORを実行するなど、隠すことによるセキュリティでこれを解決しないでください。

ああ、ところで、問題がデータの整合性自体にある場合は、それを修正することはできません。送信されるデータは常にユーザーが提供します。これは、マシンが実行するすべてのことがそのユーザーの制御下にあるためです（想定）。

于 2012-10-17T19:37:02.390 に答える