Подтвердить что ты не робот

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

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

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

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

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

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

4b9b3361

Ответ 1

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

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

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

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

Ответ 5

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

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

Ответ 6

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

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

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

Ответ 8

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