例1
ロシア最大の支払い方法のアグリゲーターのサイトは、オンラインゲームのリーダーを務めています。 注文の支払い後、クライアントをフォームのURLにリダイレクトします
aggregator-domain/ok.php?payment_id=123456
aggregator-domain/ok.php?payment_id=123456
、フォームのアドレス（読みやすくするためにデコードされた）でオンラインゲームWebサイトに順番にリダイレクトします
online-game-domain/shop/?...amount=32.86...¤cy=RUB...&user=user_email@gmail.com...&item_name=1 ...
payment_id
パラメーターの値を
payment_id
と、オンラインゲームのユーザーのログイン、行った購入、金額を確認できます。
例2
フォームに個人データを入力した後にオンラインローンを発行するために積極的に宣伝されているサイトの1つで、生成されたアプリケーションの結果は、フォームのリンクによって発行されました
domain/confirmation?clientId=12345
domain/confirmation?clientId=12345
、ここで、GETリクエストで、とりわけ、氏名、住所、納税者番号を返しました。
これらのデータは、銀行の現金窓口での支払いの請求書を作成するためにクライアントに転送する必要がありました。 ただし、
clientId
パラメーター
clientId
を並べ替えると、他のクライアントの個人データを受け取りました。
例3
国内最大級の銀行のオンラインバンキング。 定期的な支払いを行うとき、彼はフォームのアドレスへの増分識別子とPOSTリクエストによって割り当てられました
domain/calendar_event.php
パラメータ
id=12345
domain/calendar_event.php
は、ユーザー名、カード番号、支払い金額、目的、規則性など、作成された定期支払いに関する詳細情報を返しました。 繰り返しになりますが、idパラメーターが多少変更されると、他のクライアントの個人情報にアクセスできるようになりました。
例番号4。
サイト用のかなり人気のあるチャット。 アカウントには、設定、ダイアログ履歴、オペレーター管理などがありました。
セッションIDは、
sessionID=”12345|6749476c44696255216a6148516d5e33”
形式
sessionID=”12345|6749476c44696255216a6148516d5e33”
ここで、最初の部分は会社の識別子、2番目の部分はユーザーの識別子です。
その結果、最初の識別子を変更すると、完全に異質な会社の管理パネルになりました。 アカウントにアクセスできるようになったので、キャンペーンに代わってオペレーターを追加し、顧客と対話する機会がありました。
結論：
上記の例では、プログラマーのエラーにより、個人データが漏洩する可能性がありました。 これは、整数識別子を使用する利便性のための大きな価格です。
どうする トークンを使用します。 短い長さの任意の行は、情報の破壊と大量盗難からあなたを守ります。 結局のところ、プログラマーのエラーから身を守ることはできず、増分識別子を使用して構築されたコードは常に監視する必要があります。
PS
私はコメントに同意し、自分から追加します：
トークンの使用は、セキュリティの追加レベルとしてのみ適しています;完全な保護は、権利とアクセスのシステムを介してアプリケーションアーキテクチャに実装する必要があります。