2012-03-01 8 views
4

私はプロジェクトにDjangoのremote user authenticationを使用しています。私が実際に使用しているのは、ミドルウェアのないdjango.contrib.auth.RemoteUserBackendで、バックエンドでユーザーが合法であることを確認した後、手動でauthenticateを呼び出すだけです。ミドルウェアのソースを読むDjangoのリモートユーザ認証とセキュリティ

、単にリクエストのヘッダからユーザ名を取得し、その後、このユーザ名を渡すバックエンドに対してユーザを認証するように思われます。リモートユーザーのバックエンドは、ユーザー名が渡されたときにユーザーを気楽にログします。ユーザーは、有効なログインが必要なすべての領域にアクセスできます。

これはただの巨大なセキュリティ上の欠陥ではないですか?これはどういう意味ですか?

私の場合、authenticateへの唯一の呼び出しは、リモートIDの検証が成功した後になるためですが、ミドルウェアが導入された理由が疑問です。あなたのウェブサーバは、訪問者がそのユーザー名に対する有効な資格情報を持っていることを確認し、それに応じてヘッダーを設定しているので、「陽気で、ユーザーがログに記録されます」ジャンゴ

答えて

6

これはセキュリティ上の欠陥であると思われる場合は、REMOTE_USERヘッダーをアプリにリクエストして何が起こるかを確認する悪用策を作成してみてください。バックCGIページがあなたがウェブページをヒットされたユーザーとしてローカルに実行されたウェブの黎明期に

REMOTE_USER日付。 REMOTE_USERは実際には、アクティブなユーザを示すUNIX環境変数の名前です。 Webサーバーのセキュリティモデルが変更されたため、このスキームは互換性のために保存されました。現在でさえIISは、Active Directoryログインを透過的に処理するためにIISをサポートしています。

すべてのユーザーが渡されたヘッダはHTTP_で始まります。それ以外の場合は、SERVER_NAMEのようなヘッダー情報を信頼することができませんでした。これは非常に混乱します。

+0

HTTPプレフィックスについて説明していただきありがとうございます。 – Andrea

1

REMOTE_USER(またはその他の)ヘッダーを正しく設定するようにWebサーバー(Apacheなど)を信頼する場合は、セキュリティ上の欠陥ではありません。

+0

まだ分かりません。これはリクエストのヘッダーです。なぜ攻撃者は要求を発行するときに手動で設定できないのですか? – Andrea

+0

Djangoは、ヘッダを正しく設定するためにWebサーバを利用しています。 Webサーバーでユーザーが手動でヘッダーを設定できる場合は、セキュリティホールがあります。 – Alasdair

+0

私は理解しますが、ポイントは何とかWebサーバーに要求からそのヘッダーを削除するよう指示する必要があることです。ヘッダーは大部分が変更されません。それらは**要求**の一部です。したがって、それらはユーザー入力です。私はこれが少なくとも通知に値するはずだと思います。 – Andrea