Безопасность активного содержимого
Проверка вводимых пользователем данных
Наиболее часто встречающимся недостатком сценариев, используемых для генерирования динамического содержимого, является обработка вводимых пользователем данных (например, данных формы) без их проверки. При вводе некорректных данных хакерам, их отправившим, открывается возможность для выполнения ряда атак. Любой сайт, осуществляющий прием данных от пользователя, подвержен атакам, если получаемые данные не проверяются перед их обработкой.
В языке HTML для отличия текста от тегов разметки используются некоторые символы. Например, символ "меньше чем" ("<") означает начало тега HTML. Когда веб-браузер считывает символ "<", он осуществляет поиск корректного тега HTML, располагающегося после этого символа. Если на странице HTML требуется отобразить сам символ "<", разработчику нужно заменить "<" на <.
Теги могут либо управлять форматом содержимого страницы, либо представлять программу для выполнения (например, тег <SCRIPT> представляет код различных языков сценариев). Хакер может вставить в поле формы вредоносный код вместо ожидаемого содержимого. Например, вместо указания адреса электронной почты в гостевой книге веб-сайта ввести следующий код:
<A HREF=http://www.плохой_сервер.com/scripts/вредоносный.asp>Щелкните здесь – специальное предложение</A>.
Если код не будет проверен, то сценарий возвратит эти данные каждому пользователю, просматривающему комментарии посетителей в гостевой книге, и отобразит гиперссылку: "Щелкните здесь – специальное предложение". Пользователь, щелкнувший на этой ссылке, перенаправится на сайт www.плохой_сервер.com. Все будет выглядеть так, будто вредоносный код поступил с вашего сайта. При отправке и отображении вредоносного сценария (так называемая "подстановка сценариев") хакер потенциально может захватить управление сайтом.
Непроверенные введенные данные могут вызывать, например, нарушение целостности данных, установку и считывание элементов cookie и перехват вводимых пользователем данных. Принимая во внимание огромное количество пробелов в безопасности, создаваемых непроверенными данными на общем веб-сервере, удивительно, что на большинстве сайтов до сих пор отсутствует проверка данных перед их обработкой. Если ваши сценарии принимают данные от пользователей интернета, обеспечьте их проверку, кодирование и фильтрацию символов со специальным значением, чтобы они не воспринимались как код HTML.
Фильтрация вводимых данных
Вводимыми данными называются данные, передаваемые сценариям для обработки; они обычно поступают из веб-формы, из базы данных или из другого источника. Фильтрация ввода работает посредством удаления специальных символов из вводимой информации, которые позволяют генерировать сценарий в потоке данных HTML. Ниже приведены специальные символы:
< > " ' % ; ) ( & + -
Конкретная ситуация может потребовать фильтрацию дополнительных символов, помимо указанных.
Проверка клиентской части
IIS передает данные, отправленные веб-формой, сценариям для обработки, и первой возможностью проверки и фильтрации этих данных является веб-браузер пользователя. Эта проверка называется проверкой клиентской части. Она реализуется с помощью сценариев JavaScript, так как они могут выполняться и в Internet Explorer, и в Netscape. Эта проверка подтверждает, что данные, обрабатываемые сценарием, действительно введены в полях формы. В примере функция JavaScript проверяет ввод номера телефона в поле формы с именем Telephone:
function ValidateFormData(form) {
var theNumber = form.Telephone.Value;
var valid = true
var GoodChars = "0123456789()-+ "
var i = 0
if (theNumber =="") {
// Возврат значения "ложь" при отсутствии номера телефона
valid = false
}
for (i =0; I <= theNumber.length -1; i++) {
if (GoodChars.indexOf(theNumber.charAt(i)) == -1) {
alert(theNumber.charAt(i) + "является некорректным символом.")
form.Telephone.focus();
valid = false
}
}
return valid
}Данные, введенные в поле формы Telephone, проверяются перед отправкой на сервер посредством вызова функции ValidateFormData в методе onSubmit формы следующим образом:
<FORM ACTION="scripts/process.asp" METHOD="POST" onSubmit="return ValidateFormData(this);">
Следующий фильтр, написанный на JavaScript, является примером того, как следует удалять специальные символы:
function RemoveBadChars(strTemp) {
strTemp = strTemp.replace(/\<|\>|\"|\'|\%|\;|\(|\)|\&|\+|\-/g,"");
return strTemp;
}Еще одним способом контроля вводимых данных является указание предельного размера данных в полях ввода; это ограничение устанавливается добавлением атрибута MAXLENGTH в теги ввода текста. Например, если поле предназначено для ввода восьмизначного числа, следует ограничить вводимые пользователем данные:
<input type="text" name="ordernumber" MAXLENGTH="8">
Такая блокировка усложняет хакеру задачу по вводу вредоносного кода. Тег <applet></applet> или <script></script> сам по себе занимает 17 символов.
Проверка клиентской части вводимых данных предотвращает их ненужную обработку, если пользователь допустил ошибку. Однако эта проверка не является столь же функциональной, как проверка серверной части. При использовании сценариев для получения вводимых данных <TEXT> из формы HTML их тип неизвестен, и некоторые символы, в обычной ситуации отбрасываемые фильтром, могут оказаться приемлемыми.
Если сценарий предназначен для обработки информации из базы данных, нельзя по умолчанию предполагать, что эти данные являются корректными. При контроле ввода информации в базу данных следует использовать проверку корректности в точке ввода данных. Эта проверка является составляющей частью качественно реализованной базы данных.
Элементы управления проверкой ASP.NET. Так как проверка вводимых пользователем данных очень важна с точки зрения безопасности, ASP.NET (последняя версия ASP от Microsoft для платформы .NET) обеспечивает серверные элементы управления, проверяющие вводимые пользователем данные и отображающие сообщения об ошибках при обнаружении некорректных данных. Элементы управления обычно выполняют проверку в коде сервера либо, при работе с веб-браузером, поддерживающим DHTML, – и на клиенте.
В примере фрагмент кода веб-приложения ASP.NET обеспечивает ввод пользователем правильного адреса электронной почты; проверка выполняется элементом управления RegularExpressionValidator. При отправке данных формы содержимое поля адреса электронной почты проверяется на соответствие регулярному выражению, и если соответствие не подтверждается, пользователь получает сообщение об ошибке.
E-mail Address: <BR> <input id=txtEmail type=text size=35 MAXLENGTH=35 runat=server/> <asp:RegularExpressionValidator ID=valEmailAddress ControlToValidate=txtEmail ValidationExpression=".*@.*\..*" ErrorMessage="Введен неправильный адрес электронной почты." Display=None EnableClientScript=true Runat=server/>
При передаче адреса электронной почты неправильного формата отображается содержимое ErrorMessage. ASP.NET предоставляет целый набор подобных элементов управления, связанных с безопасностью. В случае переноса сайта на ASP.NET разработчики должны уметь применять эти дополнительные меры безопасности в коде, с которым они работают.
Проверка серверной части
Сценарий должен проверять и очищать данные перед их обработкой, что обеспечит удаление всех некорректных данных и правильное выполнение кода. Очень важно реализовать проверку серверной части, так как некоторые данные передаются внутри самого URL, который не проверяется на клиентской части. Для проверки данных используются и более мощные алгоритмы. Язык сценариев VBScript версии 5.0 и выше работает с регулярными выражениями с целью фильтрации и очистки входящих данных. Посредством создания шаблонов, соответствующих конкретным строкам, осуществляется поиск и замена введенных пользователем данных для проверки их на наличие черт вредоносного характера. Синтаксис шаблона VBScript заимствован из языка Perl.
Следующий пример кода выполняет удаление всех символов, не лежащих в диапазонах 0 – 9, a – z, A – Z и не являющихся пробелом, из строки strTainted:
<% Set reg = New RegExp Reg.Pattern = "\W+" strTainted = reg.Replace(strTainted, "") %>
Совет. Для получения более подробной информации о написании общих регулярных выражений с помощью VBScript посетите страницу http://msdn.microsoft.com/workshop/languages/clinic/scripting051099.asp. Общая информация о сценариях Windows находится по адресу http://msdn.microsoft.com/scripting/.
При запросе сценарием информации из базы данных, скорее всего, осуществляется сохранение процедуры. Общий объем данных, переданных сохраненным процедурам, не должен превышать установленный максимум. Все отправляемые запросы нужно проверить на превышение максимально допустимого размера.
Данные, передаваемые базе данных, должны проходить фильтрацию. Злоумышленник в запросах SQL может отправить групповые символы ("%" и "_"), разрешенные в выражениях SQL, и получить все записи из таблицы SQL. Осуществляйте фильтрацию этих символов в любых вводимых пользователем запросах к базе данных.