3

私はセットアップを持っています

  1. ユーザーが私のサイトにログオンする場合としない場合があります。
  2. ユーザーがサードパーティのサービスにフォームを送信し、
  3. サードパーティのサービスがその役割を果たし、サイトで「webhook」を呼び出して、すべての$_POSTデータを転送します。

したがって、説明するために：

    +---------------------+         +---------------------------+
    | mysite.com/form.php |-------->| thirdparty.com/submit.php |
    +---------------------+         +---------------------------+
                                                  |
                                                  v
                                    +---------------------------+
                                    |   mysite.com/webhook.php  |
                                    +---------------------------+

フォームの送信時にユーザーがログオンしていた場合、Webhook でこの事実をどのように伝えて認証できますか?

たとえば、非表示フィールドを単純に設定できます。

<input type="hidden" name="loggedOn" value="true" />

しかし、誰でもそれを偽装できます。ユーザーのパスワードハッシュを通過するかもしれないと思ったのですが、

<input type="hidden" name="passwordHash" value="$2a$08$Lg5XF1Tt.X5TGyfb43vBBeEFZm4GTXQhKQ6SY6emkcnhAGT8KfxFS" />

Webhook を効果的に「ログイン」させますが、ユーザーのパスワード ハッシュがクライアント側に公開されるため、これは正しくありません。

セッションメカニズムを使用してこれを行うには、より良い方法があるに違いないと思いますが、セッションは初めてです。おそらく、適切な語彙が不足していますか？誰かが私を正しい方向に導いてくれますか? ありがとう！

編集：

さらに調査した結果、正しい方法は、非表示のフォーム フィールドsidをセッション ID に設定session_id()して Webhook に渡すことであると考えています。Webhook は、セッション ID を使用してセッションを続行しsession_id($_POST['sid']); session_start();ます。私の質問は、これが標準的な（そして安全な）解決策であるかどうかです。

4

3 に答える 3

3

いずれにせよ、ユーザーの SessionID はユーザーに知られており、いずれにせよ中間者のアプローチによって傍受される可能性があります。したがって、セキュリティが「ハッキング」される可能性がある (そして SSL にアクセスできない) ことが懸念される場合は、IP 追跡、エージェント追跡などを実装します。すべての詳細は、なりすましや偽造の可能性があり、ミスセッションを変更する可能性さえあります（モバイルのIPを除いて、めったにありませんが）追加のレイヤーです.

したがって、基本的な解決策は、session_id を作成し、フォームの一部として渡し、それをあなた/Steve の提案どおりに使用することです。

IP ヘッダーまたはエージェント ヘッダーは失われるため、使用できません。そのため、使用できるものを確認する必要があります。

複雑さの昇順ですが、セキュリティは次のとおりです。

  1. thirdparty.com は、投稿以外のデータをあなたに渡しますか? ヘッダーを確認してください。発信元の IP、発信元のリファラーまたはエージェントを渡すことがあります。これらを最も単純な防御線として使用できます。元のデータ (セッションに保存できるデータ) と一致する必要があります。

  2. サイトでフォームを作成するときに、別の一意の ID を作成し、セッションに保存します。非表示のフィールドでもそれをフォームに渡します。「 thirdparty.com 」からフォーム データを取得すると、一意の ID がセッションのものと一致することを確認できます。次に、セッションから uniqueID を削除します。つまり、一度しか使用できません。(これは、彼の回答で pd40 が参照している NONCE です。)

  3. JavaScript を使用できる場合は、送信時にトラップし、詳細もサーバーに送信します。サーバーには、セッションの詳細が既に含まれています。「 thirdparty.com 」が戻ってきたら、セッションを呼び出して詳細が一致することを確認します。(セッションにすべての詳細を保存したくない場合は、MD5 を使用できます。MD5 は返されたときに一致する必要があります)。また、これにタイムスタンプを付けることもできます。60 秒以内に返信がない場合は、何かが少し遅くなりました [必要に応じてタイムスタンプを調整しますが、余裕を持ってください]。

  4. ただし、私の好み (および私たちが使用するもの) は、独自のサーバーでフォーム データを受信し、Curl を使用して thirdparty.com への POST 要求を生成することです。Webhook は実際には必要ありません。自分で処理を続行する前に応答を確認するだけです。ユーザーは、サードパーティが関与していることに気付かず、対話は自分とサーバーの間で行われます。

また、本当に心配な場合は、「無効」と思われる通話を記録してください。ユーザーが問題を解決する前に、ハッキングを数回試みていることがわかります。そのため、ユーザーがハッカーであると特定したことを絶対に明らかにしないでください (誤検出の可能性がない限り、注意してください)。ログに記録します。 . たとえば、1 つの IP から 5 つの無効なリクエストを受け取った場合、その IP からの後続のすべてのリクエストは、たとえ良好であっても危険であると見なすことができます。監視できるようにログを保持します。

最終的な注意: SSL を実装できる場合は、常に SSL が最適です。

うまくいけば、実装できるオプションのアイデアが得られます。

于 2012-09-06T01:36:55.073 に答える
2

セッションIDを使用すると、誰が要求を行ったかを追跡し、セキュリティ保護を提供するのに役立ちます。

また、サードパーティへの各リクエストに次のものを含めることを検討することもできます。

  • リプレイを検出するナンス
  • 古いリクエストを検出するためのタイムスタンプ
  • リクエストごとに送信されるデジタルまたは改ざんされる可能性のある値に署名/ハッシュし、 Webhookでこれらの値を確認します
于 2012-09-04T01:21:17.757 に答える
0

ユーザー セッションがデータベースに保存されている場合、これはより簡単になります。確かに、誰でもそのフォームを渡す (なりすます) ことができますが、「webhook」をトリガーするときにセッション テーブルで有効なセッション キーを確認した場合は、問題ありません。

于 2012-09-04T00:44:02.367 に答える