Angularセキュリティの観点からルートガードはどの程度優れていますか？
企業環境では、スクリプトキディ、ハッカー、高度な脅威に対して ルートガード はどの程度安全ですか？
私が正しく理解していれば、ルートガードはすべて.jsファイルで攻撃者に利用可能であり、すべてのデータはクライアント側にあるため、ユーザーはルート保護を簡単にハッキングしてフローロジックを操作できる可能性があります。
- ルートガードを簡単に迂回して、保護されたルートにアクセスできますか？
- セキュリティの観点から、ルートガードはどの程度優れていますか？
- それらが悪い場合、なぜそれらは存在するのですか？
- ロジックをフロントエンドAPIからバックエンドAPIに変更する方が良いソリューションではありませんか？
- 彼らはどのようなセキュリティの役割/目的を果たしますか？
PSこれはAngular 8に関連し、AngularJSには関連しません。
クライアント側の制限は、攻撃者によって回避される可能性があります。プライベートデータを保護するためにクライアント側の制限に依存することはできません。これらの事実はすべてのシステムに当てはまり、Angular 8を使用しているという事実は何も変更しません。
実際にこれが意味することは、ログインしているユーザーがアクセスしてはならないデータをサーバーが返してはならないということです。すべてのデータを返すことを考えていて、Angularガードがユーザーの許可に基づいてデータを表示するかどうかを決定することを考えている場合、それは間違いとして間違ったアプローチです。この種のアプローチは、ほぼすべてのスキルレベルの攻撃者。ブラウザで開発者ツールを開いてネットワークリクエストを表示するだけで、誰でもすべてのデータを表示できるからです。
むしろ、ガードの使用は単にニースUXのためのものです。警備員がいない場合、フロントエンドがユーザーにアクセスを想定していないページへの移動を許可するとどうなりますか？おそらく、ユーザーはなんらかの「アクセス拒否」エラーを受け取り、非常に混乱するでしょう。ただし、Angularガードがサーバーと同じ特権セットを適用する場合、ユーザーはアクセスするはずのないページにアクセスすることができず、したがってエラーメッセージで混乱します。メニューでは同じルールを適用する必要があることに注意してください。Angularガードを使用すると、ユーザーが機密ページにアクセスできなくなりますが、そのページへのリンクがまだありますとにかく、ユーザーが安全なページに移動しようとしてガードがそれらを停止すると、ユーザーは同様に混乱します。
もちろん、これは正当なユーザーにのみ適用されます。任意のスキルレベルの攻撃者は、制限されたサーバーエンドポイントを直接ヒットする方法を見つける可能性があるため、当然、サーバーも権限を確認し、適切な「アクセス拒否」メッセージを返す必要があります。
tl/dr：サーバーサイドガードはデータ保護に関するものです。クライアント側のガードとは、よりスムーズなユーザーエクスペリエンスを提供することです。
Angularでは：
ルーティングガードはセキュリティを提供しません、ただし、これはアプリケーションのフルスタックの構築方法に依存しますが、API /アプリケーションが未認証の認証済みデータをロードできないように注意する必要がありますユーザー。たとえば、ルートをガードする場合は、それをmy-accountこの場合、認証されたユーザーのみがこのルートにアクセスできると言います（これは、トークンを使用してユーザーのリクエストを認証するとします）。これは、認証されたユーザーだけがこのルートにアクセスできることを意味しますが、リクエストが許可されない場合認証が必要な場合でも、これは依然として大きな脆弱性です（アカウントの詳細など、ユーザーの機密データがある場合）。
ただし、最も重要なことはルートを保護することではありませんが、適切な権限を持つユーザーのみがアクセスを許可されているデータにアクセスできるようにすることです。これは、攻撃者がコードをリバースエンジニアリングしてこのルートにアクセスしても、認証されていないとデータにアクセスできないためです。
これはおそらく言うまでもありませんが、ルートの機密値をハードコードしないでください！それらをガードしたとしても、中程度の知識を持つ攻撃者がアクセスできるためです。
閉じる際、重要なのは、認証されたユーザーのみが、許可されたデータにアクセスできるようにすることですルートは、前述のユーザーエクスペリエンス用であり、セキュリティではありません。
お役に立てれば。