Реализация безопасности приложений - Уровень приложений и уровень БД (ASP .NET и SQL Server 08)

Question

Я собираюсь развернуть приложение ASP .NET (разработанное с использованием LINQ-to-SQL).

Я принял следующие меры предосторожности:

• Доступ к базе данных через пользователя с ограниченным доступом, однако, поскольку приложение предназначено для доступа к конфиденциальным данным, я не могу лишить этого пользователя с ограниченным доступом отэто
• Сервер базы данных не открыт внешней сети - скрывается за DMZ, а все внешние порты заблокированы
• Я провел тщательное тестирование безопасности веб-приложения;SQL-инъекции, управление правами, нелегальный доступ к данным (через пост-получение данных)
• Приложение работает по SSL

Вопросы:

1 - я используюAPI авторизации ASP .NET;любая рекомендация избегать перехвата сеанса (в случае, если кто-то каким-то образом узнает ключ сеанса).Есть ли способ изменить куки-файл аутентификации, менее подверженный угрозам?Скажи как, меняя его после каждого запроса?(Я знаю, что очень хорошо разбираюсь в этом конкретном предмете)

2 - Данные в базе данных не зашифрованы.Чтобы сделать вещи сверхбезопасными, я думаю о реализации прозрачного шифрования данных.Может кто-нибудь поделиться своим опытом или ссылкой на реализацию шифрования на уровне данных с SQL Server 2008 вместе с плюсами и минусами?

3 - Рекомендация по сохранению строки подключения в web.config.Лучше ли использовать встроенную защиту, чем зашифрованную строку подключения к базе данных?

Answer 1

1. Мне кажется, что для этой задачи достаточно стандартного API asp.net. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * - статья MS 100 * от MS P & P о безопасности проверки подлинности с помощью форм.
2. У меня нет такого опыта, но вот ссылка со статьей .
3. Не знаю: (
   Также я рекомендую проверить инструмент AntiXSS , он может показать некоторые потенциальные дыры в xss. И последнее замечание: никогда не доверяйте пользовательскому вводу .

Answer 2

1. Я не эксперт ASP.Net, но в своих проектах PHP я шифрую cookie и привязываю его к определенному IP-адресу клиента. Таким образом, сеансы не могут мигрировать на другой клиент. В конечном счете, если вы хотите быть абсолютно уверенным, не можете полагаться на куки для аутентификации, а вместо этого использовать HTTP Digest, поскольку браузеры будут прозрачно повторно аутентифицировать каждый запрос в пределах области. К сожалению, этот параметр не работает со встроенными поставщиками членства ASP.Net, поскольку предлагаемый вариант дайджеста HTTP, по меньшей мере, наполовину бессмысленен (только аутентификация в AD).
2. Какую конкретную угрозу вы пытаетесь смягчить, шифруя данные? TDE предназначен для уменьшения угрозы случайной потери носителя (т. Е. Кто-то найдет ваш старый диск со всеми данными на нем, или вы потеряете ноутбук с базой данных на нем). Это также угроза, смягчающая большинство других схем шифрования базы данных, таких как шифрование столбцов или шифрование на уровне файлов (блокировщик битов). Другие угрозы, такие как случайный компромисс доступа к базе данных (т. Е. Кто-то находит вектор SQL-инъекции для вашей базы данных), не могут быть смягчены TDE, поскольку база данных предложит расшифрованные данные любому аутентифицированному пользователю. Чтобы смягчить такие угрозы, это означает, что данные зашифрованы ключами, предоставленными пользователем (т. Е. Только пользовательский сеанс может расшифровать данные, потому что сеанс знает пароль ключа), но это исключает «прозрачный» аспект всех этих шифрований. схем. Если пользователь зашифровывает данные с помощью своего собственного ключевого пароля, он защищает данные от других пользователей (других сеансов), что делает его более надежным, но его «1008» очень трудно «получить правильно», а пользователь всегда рискует заблокировать Сам из своих данных, забыв / потеряв пароль ключа.
3. Использовать встроенную защиту и хранить строку подключения в зашифрованном виде. Поскольку шифрование строк в Web.Config тривиально и хорошо поддерживается при развертывании и эксплуатации ASP, просто сделайте это. Шифрование строки защищает от случайного взлома узла IIS / ASP от учетной записи не администратора. Учетная запись администратора или учетная запись, под которой работает ASP, всегда сможет прочитать зашифрованную строку подключения. Поскольку наиболее вероятным вектором атаки всегда будет компрометация ASP (т. Е. SQL-инъекция и друзья), злоумышленник, скорее всего, сможет прочитать строку подключения даже в зашифрованном виде, так что от этого не так много пользы, но каждый маленький кусочек имеет значение.

Answer 3

Встроенная защита - ваш самый надежный вариант.