web-dev-qa-db-ja.com

広告パートナーに渡す前にセッションIDをハッシュすることは意味がありますか？

私の会社はウェブショップを運営しています。購入後の割引券（他のオンラインショップでもご利用いただけます）や、他店のお客様への当店用クーポン券の提供も行っております。この目的のために、パートナーは、私たちに、お客様に関するいくつかのデータとそれぞれの注文について、支払い完了ページで送信するように依頼しています。彼らは、いくつかのJavaScript変数を設定し、サーバーからのJavaScriptを含めることでこれを実現したいと考えています。これにより、支払い完了ページに広告バナーも表示されます。

広告バナーを含むと、ある程度のリスクが伴います であることはすでに学びました。弊社は既にこのパートナーに対してこのリスクを受け入れることを決定しているようです。

今、私はある特定の点について心配しています。パートナーが送信するように要求するデータには、パートナーの状態を「二重リクエストを認識する」ために、お客様のセッションIDも含まれます。実際のセッションIDをパートナーに送信しないでください。この情報を使用すると、パートナーがサイトでお客様のIDを偽ることができるためです。したがって、代わりにセッションIDのハッシュを送信します。これにより、パートナーは顧客の身元を偽ることができなくても、二重のリクエストを認識できるはずです。

これは理にかなっていますか？それとも、サーバーのJavaScriptを含めるという事実により、パートナーはセッションIDを知ることで可能な害よりも多くの害を及ぼす方法をすでに持っているのでしょうか。セッションIDをHttpOnly Cookieに保存します（サーバーと顧客間の接続用）。

セッションIDをハッシュすることが理にかなっている場合、どのハッシュ関数が良い選択でしょうか？

web-applicationattacksjavascriptsession-management
17
user26315

はい、あなたの言っていることが理にかなっています。

Cookieを HttpOnly cookie として設定することで、パートナーのJavaScriptがユーザーのセッションIDにアクセスするリスクを軽減できます。パートナーが顧客の一意の識別子を取得することを要求しているので、安全にハッシュされたバージョンのセッションIDを送信しても問題はありません。

ここで重要な点は、あなたはハッシュ化されたバージョンのセッションIDを識別子として使用しないため、パートナーがそれを使用して顧客になりすますことができないことです。しかし、同時に、ハッシュ化されたバージョンは、パートナーが顧客を認識するのに十分なほどユニークです。

ハッシュに何を使用するかについては、出力の長さがセッションID以上である限り、どのハッシュアルゴリズムを使用してもかまいません。この場合は、もちろん、固定ソルト（ペッパー）を使用する必要があります。 ）常に同じセッションIDで同じハッシュを生成するため。

10
Adi

広告主に提供する別の「セッショントークン」を簡単に生成し、その広告トークンを標準のセッションストアに配置できます。 .Netでは、次のような単純なものを使用します。

_void Session_Start(object sender, EventArgs e) 
{
   // assign a random GUID for the ad partner
   Session["AdToken"] = Guid.NewGuid().ToString();
}
_

後で、<%=(string)Session["AdToken"]%>（ASPXページの場合）を使用して値を取得できます。

1
IDisposable