クライアントから、ブラウザの履歴にPIIが含まれているとの不満が寄せられています(ブラウザのメニューからアクセスできる永続的な履歴のようにCtrl + H
(Chromeの場合)。たとえば、ユーザーを編集するためのURLは、「 https://www.mysite.com/users/USERNAME_HERE/edit "のようになります。そしてもちろん、それはブラウザの履歴に表示されます。
これは本当にセキュリティ上の問題ですか?他のPIIのような注文番号(小売サイトの場合)はどうですか?
それは本当にウェブサイトの性質に依存します。サイトのユーザー名が他の場所(このサイトのここなど)に既に表示されている場合は、おそらくPIIではありません。ユーザー名が他に表示されていない場合、PIIと見なされる可能性があります。
とはいえ、編集用のURLでユーザー名が公開されているのはなぜですか(特定のフレームワークのデフォルト以外)。特に、URLは一般にログに記録され、履歴に保存されるため、システムで使用されているユーザー名に関する情報をハッカーに提供する可能性があるため、ユーザー名を使用することは一般に悪い習慣と見なされています。この情報とユーザーがパスワードを再利用する傾向があるという事実を考えると、リスクは本来よりも大きくなっています。
ここ は、米国に関連するPIIのリファレンスです。ただし、PIIがどのように定義されているか、どのサイトを運用している場合でもPIIに関連する規制について調査する必要があります。また、ユーザーがサイトを使用することを許可しているのと同じことを調査することもできます。
ユーザー名として使用するもの(例:正式名、メールアドレスなど)も重要になる場合があります
また、従わなければならない追加の規制がある場合、どの業界内でどのサービスを提供しているかが問題になる場合もあります。
あなたの顧客はあなたが保持しているデータを保護することをあなたに信頼します、そしてあなたはあなたの顧客の信頼を失うのを避けるために注意を怠らないでください。
これらの法的な頭痛、曖昧さ、セキュリティ/プライバシーの懸念のほとんどを回避する方法:この特定の使用例では、トークン化を使用します。
URL(つまり、ユーザー名、キー、識別子など)に直接データを公開せず、サーバー上のセッションでトークンにマップします。このようにして、セッションの有効期限が切れたときに数値が無意味になります。
この場合:
/users/bob/edit
は/users/42/edit
になります
概念的にはそうです。開示する必要のないものはすべて、セキュリティ上のリスクとなる可能性があります。ユーザー名よりもパスワードを推測する方がはるかに簡単ですandパスワード。また、多くの攻撃は、1つまたは一連の有効なユーザー名を持つことに依存しています。
Webアプリケーションでは、URLにユーザー名を含める理由はほとんどまたはまったくありません。認証後にユーザー名を必要としないだけです。サーバーは、セッション識別子が与えられた場合、誰がログインしているかを認識しています。ユーザーは自分のユーザー名を知る必要はありません。 「セッション」、「自分」、「ユーザー」など、ログインしたユーザーへの相対参照を使用して、必要に応じてサーバーに実際のユーザー名と一致させることができます。