Held-Hintergrund ohne Trennlinie
Richtlinien

認証と承認

認証 (AuthN) と承認 (AuthZ) の主題は、どちらかが脆弱な脆弱性が頻繁に発生するため、非常に重要です。これらは頻繁に発生しているように見えるため、通常、脆弱性が何であるか、あるいは何が原因であるかについては、いくらか不確実性があるということです。

念のために言っておきますが、各用語には以下が含まれます。

  • 認証:ユーザーは誰ですか?
  • 認可:ユーザーは何にアクセスすべきか?

以下で個別に見ていきます。

認証 (識別と認証の失敗)

不適切な認証は、次のようなさまざまな脆弱性をカバーする可能性があります。

  • 特定のページ/エンドポイントで認証が行われていないこと
  • ブルートフォース攻撃に対する保護の欠如 (クレデンシャルスタッフィング)
  • 安全でないアカウント/パスワードの回復プロセス
  • 安全でない認証トークンの生成、検証、有効期限、送信、または保管
  • ユーザーが 2FA で認証されたことの検証が不適切または不足している (該当する場合)

リストの最初の項目(認証の欠如)は、世の中で一番よく見られる問題です。多くの場合、開発者はページやエンドポイントが必要とする認証レベルを明示的に注釈したり設定したりする必要がありますが、そのステップは見逃しがちです。

システムに障害が発生していることを確認するのは良い習慣です 終了しました、フェイルオープンではなく。そのため、認証されたユーザーセッションが必要だという情報を各エンドポイントに注釈するのではなく、デフォルトでは以下のようにすべきです。 すべて 特にオーバーライドされていない限り、ルートには認証されたユーザーセッションが必要です。こうすることで、エラーの余地を大幅に減らすことができます。

認可 (壊れたアクセス制御)

承認に関する問題は、次のようなさまざまな形で発生することがありますが、非常に一般的です。

  • 安全でない直接オブジェクト参照 (IDOR)
  • 機能レベルのアクセス制御がない (AuthZ がない)
  • 権限昇格 (水平または垂直)

安全でないオブジェクトへの直接参照

オブジェクトには、それらを参照するためのキーとして使用される一意の識別子 (ID) がある傾向があります。ユーザーが注文やアカウントなどの閲覧リクエストを送信すると、通常、その ID が含まれます。「Insecure Direct Object Reference(安全でないダイレクトオブジェクト参照)」とは、ユーザーがその特定のオブジェクトにアクセスできるかどうか(またはユーザーがいない場合)をアプリケーションが検証できなかった場合に発生します。

機能レベルのアクセス制御がない

もう 1 つのよくある脆弱性は、(オブジェクトではなく) ページまたはエンドポイントの認証チェックがないことです。

使用するフレームワークによっては、開発者がハンドラーで認証を確認するか、エンドポイントに注釈を付けてエンドポイントを呼び出すために必要な要件を指定する必要があるのが一般的です。

残念なことに、このような余分な手順は忘れがちです。そのため、認証の脆弱性が最終的にどのように発生するのかがよくわかります。

推奨事項

デフォルトは開いた状態ではなく閉じた状態

認証と承認のどちらの場合も、デフォルトでオープンではなくクローズにするという原則が重要です。

言語/フレームワークによっては、アプリケーションへのすべてのルートのデフォルト設定に、可能な限り最高のロールまたは権限を持つ認証済みセッションが必要であることを確認することをお勧めします。これを行うと、開発者はルートの要件を上書きせざるを得なくなります。

cs

//デフォルトの動作がリクエストの認証であることを確認し、リクエストが管理者かどうか確認する
[認証]
[承認 (「管理者」)]
パブリッククラスセキュアコントローラ:コントローラ
{

}

パブリッククラスMyController: セキュアコントローラ
{

//継承された Authorize 属性を上書きして、すべてのユーザーがページにアクセスできるようにします
[承認 (「ユーザー」)]
公開ページユーザープロフィールを表示 () {
        
}

//管理者ユーザーのみがアクセスできます
公開ページ管理ページを表示 () {

}

//認証と承認属性をオーバーライドして ME を許可する
[匿名を許可]
公開ページ表示ログインページ () {
       
}

}

サービスでの認証チェックを強制

データにアクセスする場合、すべてのデータアクセスが関連するアクセスと承認のチェックを一元的に実施することを確認することが非常に重要です。これは通常、ドメインサービスを使用することで実現されます。

その他の例

以下に、安全な認証と承認と安全でない認証と承認の違いを詳しく説明する簡単な例をまとめました。

C#-安全でない

認証が見つかりません

パブリッククラス管理者コントローラー:コントローラー
{

//INSECURE: 管理ページを表示する前に、ユーザーがログインしているかどうかを確認しません
公開ページ管理ページを表示 () {

}

}

認証が見つかりません

[認証]
パブリッククラス管理者コントローラー:コントローラー
{

//INSECURE: 管理者ページの公開ページ showAdminPage () を表示する前に、ユーザーの権限を確認しません。{

}

}

C#-セキュア

[認証]
[承認 (「管理者」)]
パブリッククラス管理者コントローラー:コントローラー
{

//SECURE: ユーザーがログインしていることと、管理者ロールを持っていることを両方ともチェックします
公開ページ管理ページを表示 () {

}

}