Насколько безопасна проверка подлинности базовых форм в asp.net?

Question

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

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

Очевидно, что в отношении безопасности нужно учитывать множество факторов, но меня больше интересует готовый к использованию нулевой код, который поставляется с .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 поставщика, которое инициализируется из атрибута конфигурации PasswordFormat, определяет, какой формат используется:

• Membershippasswordformat.clear, в котором хранится пароли и пароль ответов в открытом виде.
• Kenshippasswordformat.hashed (по умолчанию), в котором хранится соленые хэши, сгенерированные из паролей и ответов пароля.Соль представляет собой случайное 128-разрядное значение, генерируемое классом RNGCryptoServiceProvider .NET .NET.Каждая пара ответов на пароль/пароль солена с этим уникальным значением, а соль хранится в поле Passwordsalt таблицы ASPNET_MEMBERSHIPH.Результат хэширования пароля и соль хранится в поле пароля.Аналогично, результат хеширования пароля ответа и соль хранится в PasswordAnswer поле.
• MembershipPasswordFormat.Encrypted, в котором хранятся зашифрованные пароли и Ответы на пароли.SqlMembershipProvider шифрует пароли и ответы на пароли с использованием Симметричное шифрование/дешифрование ключ, указанный в decryptionKey раздела конфигурации и шифрование алгоритм, указанный в Раздел конфигурации Атрибут расшифровки.SqlMembershipProvider выдает ошибку исключение, если его просят зашифровать пароли и ответы на пароли, а также если decryptionKey имеет значение Autogenerate.Это предотвратит создание базы данных членства содержащие зашифрованные пароли и Ответы на пароли не станут недействительными при перемещении на другой сервер или другой приложение.

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

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

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

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

Answer 5

При правильной настройке через поставщика членства у вас будет достаточный уровень безопасности.Помимо этого, доступ к этой странице может быть возможен посредством пушечных атак, но это связано с вашей общей безопасностью.Я провел презентацию по использованию Блоки корпоративных приложений безопасности.Возможно, вы захотите прочитать об этом и принять во внимание это при реализации безопасности на своем сайте, а также просто знать об распространенных угрозах безопасности.Ни один сайт никогда не будет на 100% неуязвимым для взлома, учитывая, что вы находитесь в открытой общей сети, а полная безопасность будет обеспечиваться отключенным сервером, запертым в безопасном месте, охраняемом 24/7 военными (около уровня безопасности Министерства обороны США «А», на основе Оранжевой книги). ).Но готовые функциональные возможности поставщиков членства (при правильной настройке) обеспечат хороший уровень безопасности.

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

Answer 6

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

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

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

Answer 7

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

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

ИНФОРМАЦИЯ:Помогите защитить аутентификацию форм с помощью Secure Sockets Layer (SSL)

Answer 8

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