2008-09-25 4 views
20

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

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

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

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

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

ответ

14

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

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

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

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

+0

Вдоль тех же линий, вы должны принять целостный подход к безопасности и практике «безопасности в глубину». Любая щель в этой броне (человек в середине ...) может привести к серьезной потере данных. – NotMe 2009-03-05 17:58:23

4

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

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

1

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

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

+0

В настоящее время, при использовании Firesheep cookie, мы используем HTTPS во всех сообщениях после аутентификации. – 2011-03-25 18:00:45

0

Asp.Net поддерживает сеансы cookieless, как this blog post shows. Вместо cookie сеанса он использует идентификатор в URL-адресе для отслеживания пользователей.

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

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

3

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

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

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

+0

Если вы используете стратегию хэширования пароля, вам все равно нужно иметь соответствующий Passwordsalt, поэтому я не думаю, что объединение имени пользователя и пароля завершит запрос самостоятельно – 2008-09-25 13:47:01

2

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

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

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

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

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

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

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

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

0

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

Смежные вопросы