URLに機密データが含まれています-投稿に切り替える以外の代替手段はありますか？
私の会社のクライアントの1つが最近、アプリケーションセキュリティアセスメントレポートを作成し、 OWASPのWebアプリケーションセキュリティリスクのトップ10リスト に基づく違反のリストを記録しました。 OWASPの＃3リスク に基づく違反の1つは、機密データがブラウザー履歴に存在することです。これは、クエリ文字列（ "myurl.com/somepage?userid=user123"など）でも、URLセグメント自体（ "myurl.com/users/user123/edit"など）でも可能です。
アイデアは、被害者のシステムへのアクセス権を持つ攻撃者が、ブラウザの履歴を表示してURLのデータを確認するだけで機密データにアクセスできるようになるというものです。
質問：
これを解決する方法は何ですか？クエリ文字列パラメーターの場合、フォームメソッドをGETからPOST-クエリ文字列パラメーターを処理する他の方法はありますか？URLセグメントのデータの処理についてはどうですか？
グローバルな概要なしでは、質問に答えることは困難です。 Webサイトのonly問題が機密パラメータである場合、URLにパラメータが存在します：先ほど述べたように、リクエストをPOSTとして渡し、GETではない。
ただし、次の点を確認する必要があります。
- 通信が暗号化されているTLS 1.2またはTLS 1.3を使用していることを確認してください
- サーバーはのみ堅牢および非推奨の暗号化アルゴリズムを目的とする必要があります。 このウェブサイト を使用して確認するか、プライバシーが必要な場合は このプロジェクト を使用できます。
- 壊れたアクセス制御を確認します。クエリ文字列がパターン
userid=user123を使用していると言いました：攻撃者がリクエストのパラメーターを変更する不正なアカウントにアクセスできないことを確認してください - SQLインジェクションを確認します。パターン
page=parameter（userid=user123）は古いWebサイトに実装されることが多いため、脆弱性の影響を受けやすい。 POSTリクエストおよびその他の方法で注入することもできるので注意してください
また、すべてのTOP 10 OWASP推奨事項をチェックする必要がありますが、提供した情報によると、これが最初にチェックするポイントです。
結論
- これを解決する方法は何ですか？GETメソッドをPOSTに変更します
URLセグメントのデータの処理についてはどうですか？ユーザー名がURLに表示されるという考えに反対していません。アクセスが制御されていれば、脆弱性ではありません。実際、攻撃者がコンピュータを盗むと、履歴にアクセスできるため、ユーザー名にもアクセスできます。ただし、ストレージパスワードのセキュリティ基準が守られている場合は、パスワードにアクセスできません。さらに、攻撃者が暗号化されたハードドライブを備えていないコンピューターを盗んだ場合、ユーザー名の問題だけではありません...
この問題を絶対に解決する必要がある場合は、アプリケーションのユーザーのコンピューターのハードドライブを暗号化する必要があります。その結果、コンピュータが盗まれた（および電源が切れた）場合、データは利用できなくなります。