基本的なユーザーに見える管理機能
アプリケーションのインターフェースは、どのタイプのユーザー役割でも同じです。アクセスマトリックスも維持されます。ただし、ほとんどすべての機能の名前はすべてのユーザーに表示されます。ただし、ユーザーが特定のアクションを許可されていない場合は、「無許可」と表示され、ユーザーがホームページにリダイレクトされます。
これをアプリの所有者に報告する必要があるかどうかわかりません。そうした場合、それは「ベストプラクティス」または「脆弱性」のカテゴリに分類されますか？お知らせ下さい。
それがクライアント/サーバーアプリケーションの場合は、「無許可」と言うのはクライアントだけなのか、要求がサーバーに送信されてサーバーがその応答を返すのかを確認する価値があります。サーバーのインターフェイスを保護せずにクライアントでの特定のアクションを拒否すると、開発者が仕事を完了したと考える、不十分に記述されたソフトウェアシステムがたくさんあるに違いありません。
セキュリティはIHMに依存すべきではありません。したがって、権限のないユーザーが管理アクションを要求した場合、そのアクションは拒否されるということですが、ここには脆弱性はありません。攻撃者が脆弱性を発見するのに役立つ可能性があるため、通常のユーザーには管理URLを非表示にする方がよいと主張することもできますが、難読化によってセキュリティのように聞こえます。セキュリティの部分は言う：
- 不正な形式のクエリをビジネスレイヤーで処理する前に拒否する
- 不正なユーザーアクションを拒否する
そうは言っても、平均的な（非管理者）ユーザーには使用が許可されていないオプションが表示されるため、ユーザーエクスペリエンスが非常に低下します。だから私の意見では、アプリの所有者に報告するべきですが、ユーザーエクスペリエンスのカテゴリでは、間違いなく脆弱性よりベストプラクティス
これは私がそのような場合に行うことです：
- リダイレクトがクライアント側のコントロールであるかどうかを確認します。
- そのユーザーのパラメーターを使用して、特権をより高い特権を持つユーザーの特権にエスカレートできるかどうかを確認します。たとえば、useraddがadminのみに存在する場合、通常のユーザーでログインし、セッションCookieを除くすべてを操作するプロキシでその要求を試みます。
どちらも機能しない場合は、推奨されるベストプラクティスとして報告します。将来、追加のモジュールが追加され、現在のセッション/アクセス制御がこれらのモジュールにない場合、特権の低いユーザーが新しい機能を簡単に識別して操作できる可能性があることをレポートで強調します。