クライアント側からのリクエストで指紋値が偽造されていないことをどのように保証するか

Question

JSフィンガープリントは、 fingerprint2 のようなライブラリを使用してクライアント側で計算されます。

私の質問は、ajaxを介してこの値を送信すると、ユーザーはわずかな労力でこの値を偽造でき、正当なサーバーコードによって解釈される偽のPOSTリクエストを作成できるということです。

私の質問は、これが発生する可能性がある場合、ブラウザのプロパティを変更することなく、このライブラリを簡単にバイパスできることです（ブラウザのフィンガープリントが変更されます）。

私の解釈は正しいですか？その値の整合性をどのように保証できますか？

Tschallacka · Answer

あなたはできません、そして私はそれについて本当に心配しません。

ルール番号1：ユーザーのコンピューターからのすべての入力は偽造される可能性があり、100％に依存することはできません。

必要に応じて、 piwikデバイス検出器としてライブラリを使用したサーバーサイドフィンガープリントを使用してデータを照合することもできますが、理由もなく頭痛の種になります。

あなたを訪問しているユーザーの90％は、あなたが何をしているのか見当がつかず、信頼できるデータを提供します。彼らはアドブロックさえ持っていません。彼らはあなたに信頼できるデータを提供します。

訪問者の9％がアドブロッカーを持っている可能性があり、アドブロッカーはそれらのajaxリクエストをブロックする場合とブロックしない場合があります。彼らはあなたが彼らのプライバシーを尊重することを望みます、そうすることであなたは彼らを顧客として保ちます。 1％は、これらのajaxリクエストが何をするのかを知っているかもしれませんが、訪問するすべてのWebサイトのコンソールをわざわざ検査することができないため、わかりません。その1％の1％は、ブラウザコンソールを覗いて、ブラウザのフィンガープリントを理解する可能性があります。

その1％の1％が指紋コードを盗みます。 1％の1％の別の1％は、lulzのためだけにそれを偽造しようとし、それを忘れます。

つまり、気にしないでください。人々も気にしないでしょう。

しかし、本当に気にせず、自分自身に頭痛を与える必要がある場合：

ユーザーIDを追跡Cookieの形式でクライアントコンピューターのデータベースに保存します。また、セッションストレージ、ローカルストレージ、ブラウザが提供するデータベースエンジンにも保存します。（ヨーロッパのユーザーがサイトにアクセスしたときにユーザーのコンピューターにデータを保存する理由は、Cookieの使用に関する免責事項に記載する必要があることに注意してください）
そのユーザーIDを使用して、指紋をユーザーに一致させます。このIDは、キャッシュクリアメカニズム（cccleaner、ウイルススキャナー、ユーザーが空の履歴をクリックするなど）によっていつでも削除される可能性があることに注意してください。
ユーザーIDをwindow.nameオブジェクトに入れます。タブが開いている限り、使用すると永続化され、ユーザーのコンピューターでリセット/保存を試みます。
画像にE-TAGを追加すると、ユーザーのコンピューターは、次に来たときにそのetag番号を使用してその画像を要求しようとします。そのリクエストをインターセプトして（Webサーバーに処理させないで、php/jsp/asp/whateverで処理させます）、ユーザーを識別できるようにします。正しいユーザーIDでセッション変数を設定し、そのetag値の下で画像がまだ有効であることを「応答」し、Cookieを使用して正しいユーザーIDを返します
ユーザーIDに基づいてjavascriptリクエストの背後に「timestamp」値を置き、そのjavascriptファイルを含むリクエストされたページを180日程度で期限切れになるように設定します。ユーザーが戻ってきて、ユーザーが履歴をクリアしていない場合は常に、指定された「タイムスタンプ」取得パラメーターgotcha.js?time=1283737273873を使用してjavascriptリクエストを行い、サーバーサイドスクリプトを再度使用してインターセプトします。その後、ajaxを使用してページのコンテンツを更新できます。
あなたのページにグーグルマップのようなものを含めてください。 GmailまたはGoogleサービスを使用していて、Cookieの設定についてGoogleに同意した場合、GoogleはブラウザをCookieでいっぱいにダンプしますが、これはしばらく続く可能性があります。グーグルマップのクッキーは、少なくともブラウザセッションの間は同じままであり、JavaScript /サーバーサイドスクリプトで読み取ることができます。
piwikデバイス検出器を使用してサーバー側のブラウザーフィンガープリントを作成し、それを使用して、それがどのユーザーであるかについての推測を絞り込みます。
リクエストをバイトバッファ/ストリームとしてエンコードし、base64でエンコードして、base64でデコードし、確認ハッシュとフィンガープリントの2つの部分でリクエストを送信した場合でも、何が難しいかを推測します。次に、ハッシュとコンテンツを照合します。一致する場合は、なりすましの場合、誰かが多大な労力を費やしたことを確認できます。
javascriptコードの多くの役に立たない脇道でも、コードを縮小して難読化します。各行を独自の機能に配置し、それらをチェーンしてまとまりのあるものを作成します。そこで起こっていることを差し引くのは大変な努力をします。

それ以外は、私は本当にあなたをお勧めすることができます：気にしないでください。努力する価値はありません。回避したい人は回避します。 JavaScriptを無効にし、そのスクリプトを除外し、サイトを続行または終了する前にすべてのCookieを消去し、登録済みのフォントプラグインを変更します...追跡されたくないものを追跡しないでください。気にしないグループに焦点を当てます。

Salman Lashkarara · Answer

その値の整合性をどのように保証できますか？

非常に簡単に答えるには、整合性を保護したいときはいつでも、送信されたメッセージのダイジェストも提供する必要があります。

ここでは、アリス（フロントエンド）、ボブ（バックエンドを使用して整合性の防御について説明します。 -））、およびTrudy（悪意のあるユーザー）

仮定：

アリスはPLAIN_TEXT（ここではfingerprint）を含むパッケージをボブに送信したいと考えています。Trudyはパッケージを傍受したい悪意のある人物です。 PLAIN_TEXTを変更します。

整合性に対する脅威：

Trudyは、PLAIN_TEXTをキャプチャして、必要なものに変更できます。（実際には、完全性に対する脅威が増える可能性がありますが、話は短くしたいと思います。）

パッケージの整合性を保護するためにアリスが実行する必要のある手順は次のとおりです。

アリスはPLAIN_TEXT（text_digestと呼ばれます）のダイジェストを取得します。
アリスはダイジェストをPLAIN_TEXTに添付し、新しいpackageを取得します（package = PLAIN_TEXT + text_digest）
アリスはpackageを暗号化します
アリスは暗号化されたパッケージのダイジェストを取得します（whole_package_digest）
アリスは暗号化されたパッケージにwhole_package_digestを添付し、それをボブに送信します

Trudyが理解後にできること：

オプション1.パッケージの暗号化を破ってみてください

オプション2.encrypted packageを省略して、独自のパッケージを添付してみてください。

ボブの側：

彼はpackageを復号化し、PLAIN_TEXTを取得します。（他の誰もキーを持っていないので、彼はアリスがこのパッケージを送信したことを確認します）
彼は同じメソッドを使用してPLAIN_TEXTのダイジェストを取得し（これをobtained_digestと呼びましょう）、obtained_digestをtext_digestと比較し、それらが等しい場合はこれは、PLAIN_TEXTが操作されていないことを意味します。
最後に、受け取ったパッケージのダイジェストを取得し、それをwhole_package_digestと比較します。それらが等しい場合、それはTrudyが2番目のオプションで失敗したことを意味します。

上記のシナリオでは、整合性は機密性に大きく依存していることに注意してください。ただし、暗号化には対称方式と非対称方式の両方を使用できます。

下の画像では、言いたいことをより明確に説明しようとしました。