Насколько безопасна базовая аутентификация форм в asp.net?

Question

Представьте, что у вас есть простой сайт с двумя страницами: login.aspx и secret.aspx. Ваш сайт защищен, используя только аутентификацию форм ASP.net и серверный контроль входа ASP.net на login.aspx. Детали следующие:

• Сайт настроен на использование SqlMembershipProvider
• Сайт запрещает всем анонимным пользователям
• Cookies отключены

Очевидно, что есть много вещей, которые следует учитывать в отношении безопасности, но меня больше интересует опыт работы с нулевым кодом из коробки, который поставляется с .net framework.

Если ради этого вопроса единственными точками атаки являются текстовые поля имени пользователя / пароля в login.aspx, может ли хакер внедрить код, который позволит им получить доступ к нашей странице secret.aspx?

Насколько безопасна работа Microsoft с нулевым кодом из коробки?

Answer 1

У вас все еще есть переменные, которые не учитываются:

• Безопасность в хранилище данных, используемом вашим провайдером членства (в данном случае, базой данных Sql Server).
• безопасность других сайтов, размещенных в том же IIS
• общая сетевая безопасность машин, участвующих в размещении сайта, или в той же сети, где размещен сайт
• физическая безопасность машин, на которых размещен сайт
• Используете ли вы соответствующие меры для шифрования трафика аутентификации? (HTTPS / SSL)

Не все эти проблемы относятся к MS, но их стоит упомянуть, потому что любой из них может легко перевесить проблему, о которой вы спрашиваете, если не позаботиться о ней. Но для целей вашего вопроса я предполагаю, что с ними проблем нет.

В этом случае я почти уверен, что аутентификация с помощью форм делает то, что должна. Я не думаю, что сейчас есть какие-либо активные эксплойты.

Answer 2

Насколько я знаю, пароль будет отправлен в виде простого текста (но в кодировке). Поэтому самое важное - использовать протокол HTTPS на экранах входа в систему.

Другие настройки кажутся мне безопасными.

Answer 3

При базовой аутентификации HTTP, которая используется для аутентификации базовых форм .NET, для просмотра страницы secret.aspx браузер должен отправить закодированную Base64 конкатенацию имени пользователя и пароля.

Если вы не используете SSL, эту информацию может прочитать любой, у кого есть доступ для сканирования сети между сервером и браузером. Они могут декодировать имя пользователя и пароль. Они могут воспроизвести имя пользователя и пароль в будущем, чтобы получить доступ к странице secret.aspx.

Тем не менее, если вы не используете SSL, кто-то может также сканировать весь сеанс кого-то другого, используя secret.aspx, так что, по сути, он также будет иметь доступ к содержимому страницы.

Answer 4

Ну, попробуйте заглянуть за кулисы:

Защита паролем

Приложения, хранящие имена пользователей, пароли и другая аутентификация информация в базе данных никогда не должна хранить пароли в незашифрованном виде, чтобы база данных будет украдена или взломана. к что конец, SqlMembershipProvider поддерживает три формата хранения («кодировки») для паролей и пароль отвечает. Провайдер Свойство PasswordFormat, которое инициализируется из пароля формата атрибут конфигурации, определяет какой формат используется:

• MembershipPasswordFormat.Clear, в котором хранятся пароли и пароль ответы в виде текста.
• MembershipPasswordFormat.Hashed (по умолчанию), в котором хранятся соленые хэши, сгенерированные из паролей и пароль отвечает. Соль случайная 128-битное значение, сгенерированное .NET RNGCryptoServiceProvider платформы учебный класс. Каждый пароль / пароль ответа пара солится с этим уникальным значением, и соль хранится в PasswordSalt таблицы aspnet_Membership поле. Результат хеширования пароль и соль хранится в Поле пароля. Точно так же результат хэширования пароля и ответа соль хранится в PasswordAnswer поле.
• MembershipPasswordFormat.Encrypted, который хранит зашифрованные пароли и пароль отвечает. SqlMembershipProvider шифрует пароли и ответы на пароли с использованием симметричное шифрование / дешифрование ключ указан в ключ дешифрования раздела конфигурации атрибут и шифрование алгоритм, указанный в раздел конфигурации атрибут расшифровки. SqlMembershipProvider бросает исключение, если его просят зашифровать пароли и ответы на пароли, и если Для параметра decryptionKey установлено значение «Автогенерация». Это предотвращает членство в базе данных содержащие зашифрованные пароли и пароль становится недействительным если переехал на другой сервер или другой применение.

Таким образом, уровень вашей безопасности (из коробки) будет зависеть от используемой стратегии формата защиты паролем:

• Если вы используете открытый текст, очевидно, проще взломать вашу систему.
• С другой стороны, при использовании Encrypted безопасность будет зависеть от физического доступа к вашей машине (или, по крайней мере, machine.config).
• Использование хешированных паролей (по умолчанию) гарантирует безопасность в зависимости от: а) известных изменений стратегии хеширования класса RNGCryptoServiceProvider и б) доступа к базе данных для компрометации случайно сгенерированной соли.

Я не знаю, возможно ли использовать какой-нибудь способ взлома радужных таблиц в стандартной системе Hash-base.

Для получения более подробной информации, перейдите по этой ссылке: http://msdn.microsoft.com/en-us/library/aa478949.aspx

Answer 5

При правильной настройке через поставщика членства у вас будет достаточный уровень безопасности. Помимо этого, доступ к этой странице может быть доступен через канонические атаки, но это связано с вашей общей безопасностью. Я выступил с докладом об использовании блоков корпоративных приложений безопасности . Возможно, вы захотите ознакомиться с ними и изучить это при реализации безопасности на своем сайте, а также просто знать об общих угрозах безопасности. Ни один сайт никогда не будет взломан на 100%, учитывая, что вы находитесь в открытой общей сети, и полная безопасность была бы отключенным сервером, заблокированным в сейфе, круглосуточно защищаемым военными (около уровня безопасности «A» уровня DoD, основанного на книге Orange). ). Но стандартная функциональность провайдеров членства (при правильной настройке) обеспечит хороший уровень безопасности.

Редактировать: Да, я согласен с другим комментарием, HTTPS, по крайней мере, на экранах входа в систему, является данностью, если вы хотите защитить имя пользователя / пароли от перехватчиков пакетов и сетевых мониторов.

Answer 6

Cookies через URL недостаточно безопасны, с ним связано много разных проблем (особенно утечка реферера, если у вас есть) и использование HTTPS.

Answer 7

Вот две хорошие статьи от Microsoft на эту тему:

Как: защитить проверку подлинности с помощью форм в ASP.NET 2.0

ИНФОРМАЦИЯ: Помощь в проверке подлинности с помощью безопасных форм с использованием протокола SSL (Secure Sockets Layer, SSL)

Answer 8

Asp.Net поддерживает сеансы без файлов cookie, поскольку в этом сообщении блога показывает . Вместо файла cookie сеанса он использует идентификатор в URL для отслеживания пользователей.

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

Похоже, что он работает более или менее из коробки, однако при перенаправлении пользователя и желании сохранить состояние сеанса необходимо включить идентификатор сеанса В блоге рассказывается, как это сделать, а также много других статей в Интернете.