Используйте встроенные возможности ASP.NET для защиты от веб-атак.

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

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

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

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

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

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

Каковы ключевые факты, которые следует из этого списка

распространенных веб-атак

По моему мнению, есть как минимум три вещи:

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

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

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

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

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

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

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

Атака одним щелчком мыши предполагает размещение вредоносной HTTP-формы на известном уязвимом веб-сайте. Это называется «одним щелчком мыши», потому что часто начинается с того, что жертва случайно нажимает на заманчивую ссылку, которую находит по электронной почте или во время просмотра переполненного форума. Щелкнув ссылку, пользователь случайно запустил удаленный процесс, который в конечном итоге привел к отправке на сайт вредоносной <form>. Давайте будем честными: можете ли вы сказать мне, что никогда не нажимали на ссылку типа « Нажмите здесь, чтобы выиграть 1 000 000 долларов» из любопытства? Очевидно, с вами ничего плохого не случилось. Давайте предположим, что это так; можете ли вы сказать, что все остальные члены веб-сообщества выжили? Кто знает.

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

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

Рисунок 1. Атака в один клик

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

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

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

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

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

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

Вот код, который необходим на всех ваших страницах:

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

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

файлы 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.

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

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

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

Дизайн страниц приложений является ключом к предотвращению атак перехвата сеанса. Конечно, есть еще два момента, которые не выяснены. Первый вопрос: как предотвратить кражу файлов 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), которая происходит по умолчанию. См. рисунок 2.

Рис. 2. Факторы, которые затрудняют изменение самого состояния просмотра при включении EnableViewStateMac

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Короче говоря, используйте, но не полностью доверяйте свойству ValidateRequest и не ленитесь. Уделите время фундаментальному пониманию таких угроз безопасности, как XSS, и спланируйте стратегию защиты, основанную на одном ключевом моменте: любой ввод данных пользователем опасен.

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

Существует множество способов предотвратить атаки с использованием SQL-инъекций. Ниже описаны наиболее распространенные методы.

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

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

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

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

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

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

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

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

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

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

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

Если на странице отображается адрес электронной почты, вполне вероятно, что рано или поздно этот адрес будет захвачен автоматической веб-программой. Действительно? Конечно, это зависит от того, как отображается электронное письмо. Если вы жестко запрограммируете его, вы проиграете. Не ясно, что использование других представлений (таких как Dino-At-Microsoft-Dot-Com ) будет обмануть автоматизированные веб-программы, но это, безусловно, заставит любого, кто читает вашу страницу, хочет рассердить законную связь.

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

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

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

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

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

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