Пользователь может войти без указания пароля на localhost

Question

У меня есть сайт Asp.net, построенный на C # с проверкой подлинности с помощью форм.Мы используем Active Directory для аутентификации пользователей, и все работает отлично.Но сегодня мы поняли, что войти в любую учетную запись можно, просто введя имя пользователя и нажав «Войти», не вводя пароль!Это происходит только в среде разработки, работающей на localhost (слава богу!), Но мне это не нравится ...

Я никогда не видел такого поведения раньше, и очень хотел бы, чтобы кто-то объяснил, какэто может случиться.Это функция разработчика, созданная Microsoft?Или кто-то в моем офисе сделал черный ход, не сказав остальным?Я буду исследовать этот последний вариант далее, но до тех пор - кто-нибудь сталкивался с этим раньше?

Большое спасибо заранее!

РЕДАКТИРОВАТЬ: Это где аутентификация возвращает истинудля каждого имени пользователя, которое я выбрасываю - с пустым паролемДругие пароли возвращают значение false.

using (var context = new PrincipalContext(ContextType.Domain))
{
   result = context.ValidateCredentials(username, password);
}

PrincipalContext по умолчанию - System.DirectoryServices.AccountManagement

Answer 1

После еще одного исследования я обнаружил это в MSDN, которое гласит:

Метод ValidateCredentials привязывается к серверу, указанному в конструкторе.Если параметры имени пользователя и пароля равны нулю, проверяются учетные данные, указанные в конструкторе.Если учетные данные не были указаны в конструкторе, а параметры имени пользователя и пароля равны нулю, этот метод проверяет учетные данные по умолчанию для текущего участника.

и вместе с этой информацией вдокументация конструктора из PrincipalContext:

public PrincipalContext (System.DirectoryServices.AccountManagement.ContextType contextType, имя строки):
contextType: Значение перечисления System.DirectoryServices.AccountManagement.ContextType, указывающее тип хранилища для основного контекста.
name: Имя домена или сервера для System.DirectoryServices.AccountManagement.ContextType.Domainтипы контекста, имя компьютера для типов контекста System.DirectoryServices.AccountManagement.ContextType.Machine или имя сервера и порта, на которых размещен экземпляр System.DirectoryServices.AccountManagement.ContextType.ApplicationDirectory. Если имя типа NULL для типа контекста System.DirectoryServices.AccountManagement.ContextType.Domain, этот контекст является контроллером домена для субъекта пользователя, под которым выполняется поток. Если имя NULL длятип контекста System.DirectoryServices.AccountManagement.ContextType.Machine, это имя локального компьютера.Этот параметр не может быть пустым для типов контекста System.DirectoryServices.AccountManagement.ContextType.ApplicationDirectory.

Это приводит меня к выводу, что, поскольку я не использую свойство name в конструкторе PrincipalContext, контроллер домена будет работать под моим собственным принципалом на моем компьютере разработчика.Это может означать, что он использует привилегии моих пользователей, которые, конечно, намного выше, чем учетные записи компьютеров, на которых работают производственные серверы.Это, в свою очередь, может сделать все звонки на Validate с null, так как пароль будет автоматически подтвержден из-за более высокого уровня привилегий.

По крайней мере, это моя теория ... Комментарии и мысли приветствуются, яскоро закрою этот вопрос.

Answer 2

Почему бы вам не попробовать

1. обрабатывать исключение параметра NULL.

2. сначала проверьте, имеют ли оба учетные данные значения.

   using (var context = new PrincipalContext(ContextType.Domain))
   {
       if (string.IsNullOrEmpty(UserName) && string.IsNullOrEmpty(Password))
       {
          throw new ArgumentNullException();
          result = null;  // Or redirect to Login Page
       }
       else
       {
           result = context.ValidateCredentials(username, password);
       }
   }

Answer 3

Почему бы вам не добавить нулевую проверку пароля перед вызовом ValidateCredentials?Кстати, аутентификация на стороне клиента также может помочь.

Answer 4

Похоже, проблема в коде.Чтобы пользователь был авторизован в AD, пароль должен совпадать.Маркеры безопасности генерируются из AD, и это невозможно сделать без правильного пароля или подмены (для чего также требуется пароль).

Использует ли код SELECT user FROM users WHERE password LIKE '%password%'?Я видел это сделано раньше!(