Уязвимости AJAX

Распространение технологии AJAX в современном Интернете влечёт за собой появление дополнительных направлений атак. Атакующий может внедрить собственный код клиентской стороны, чтобы целиком перехватить коммуникацию между клиентом и сервером. По сути, AJAX—новый прозрачный слой во взаимодействии клиента и сервера, не контроллируемый пользователем. Далее будут рассмотрены основные типы возможных атак.

Введение

AJAX — сокращение от Asynchronous Javascript And XML. Это термин, описывающий конгломерат технологий для улучшения функциональности и внешнего вида традиционных веб-сайтов. AJAX основан на JavaScript, CSS, DOM, XML и других технологиях. Основное свойство AJAX—его «асинхронная» природа, что делает возможным для браузера посылать данные серверу без перезагрузки страницы. Реализация AJAX может быть обнаружена в различных языках программирования и библиотеках, таких как PHP, ASP.NET, Ruby on Rails и других. Широкое использование JavaScript в коде веб-страниц позволяет производить прозрачный обмен данными между клиентом и сервером. Пользователь взаимодействует со стандартными элементами HTML, чьё динамическое поведение описывается на JavaScript. Одними из первых веб-приложений, использующих AJAX, были Gmail и GoogleMaps. В AJAX приложениях пользователь при взаимодействии с веб-приложением не вынужден ожидать перезагрузки страницы после отправления запроса.

Общие проблемы AJAX

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

Проблемы AJAX касаются как клиентской, так и серверной стороны, и в общем могут быть отнесены к следующим категориям:

1. Системная архитектура
2. Авторизация и аутентификация
3. Коммуникация между клиентом и сервером

Атаки

Подмена прототипа

Далее будет описана одна из техник получения контроля над AJAX-приложением. Эта атака основана на ряде свойств, внутренне присущих языкам, основанным на прототипах, таких как JavaScript. Прототипное программирование—подвид объектно-ориентированного программирования, в котором отсутствуют классы, а объекты создаются путём клонирования уже существующих объектов или совершенно с нуля. Новые методы и поля любого объекта могут быть добавлены путём простого их переопределения. Например, для объекта XMLHttpRequest может быть добавлен какой-либо метод следующим образом:

  XMLHttpRequest.theMethod = function() { 
   return "value";
  }

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

Подмена сессии

В то время как в классических веб-приложениях существует угроза того, что сессия будет украдена (путём перехвата Сookie), AJAX делает возможным ещё одну атаку, связанную с пользовательскими сессиями. Если злоумышленник получает возможность внедрить собственный JavaScript код на страницу, которую будет просматривать авторизованный пользователь, он может получить полный контроль над его сессией. Процедура состоит во внедрении следующего кода:

document.cookie="_session_id=16d5b78abb29e3a6206b60f22a03c8d9"

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

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

Межсайтовая подмена запроса (Cross-Site Request Forgery)

Если сессия пользователя в исходном приложении осталась открытой и пользователь попал на сайт злоумышленника, в который был внедрен вредоносный JavaScript-код, злоумышленник может выполнить действия от имени пользователя.

Суть атаки состоит в посылании AJAX или HTTP запроса со страницы сайта злоумышленника к веб-приложению, в котором сессия пользователя всё ещё активна. Например, может быть использован следующий код для выполнения вредноносного HTTP запроса:

<img src="http://bank.com/account/destroy">

Запрос будет выполнен с отправлением Cookie пользователя, таким образом, будет выполнен веб-приложением как валидный запрос пользователя. Злоумышленник может выполнять таким образом произвольные запросы.

Внедрение вредноносного JavaScript кода

AJAX-клиенты зачастую используют запрос данных в формате JSON. Формат является подмножеством языка JavaScript, и, таким образом, наиболее простым способом получения доступа к данным из кода является простая их интерпретация.

eval(serverResponse);

Таким образом, если злоумышленник нашёл способ перенаправить AJAX-запрос таким образом, что от сервера будет получен ответ с вредононосным кодом вместо JSON-данных, он будет исполнен по получению. Например, если в веб-приложении существуют адреса, запрос на которые передаёт нефильрованные входные данные в качестве ответа.

http://server.example.com/script?data=javascript:alert('hello world')

Данный случай является разновидностью XSS (Cross-Site Scripting) в применении к динамическим веб-приложениям.

Однако возможна и другая ситуация: в эпоху веб-2.0 зачастую приложения обращаются друг к другу с запросами напрямую без участия клиента. Таким образом, если одно из веб-приложений, участвующих в информационном обмене, контролируется или создано злоумышленником, а в атакуемом приложении не фильтруются получаемые данные, возможно передать пользователю вредоносный код через описанную здесь потенциальную уязвимость в JSON, либо же каким-то другим способом, например, через вставку фрагментов кода в специально сформированную трансляцию RSS или Atom.

Недостаточная аутентификация клиента

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

Зачастую для выполнения динамических запросов веб-сервис не требует никаких данных для аутентификация (таких, как Cookie, или парольной HTTP аутентификации), определяя клиента по IP-адресу и другим особенностям запроса. Такой подход позволяет злоумышленнику, правильно подобрав время запроса, выполнить его при благоприятных условиях от имени пользователя.

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

Защита

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

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

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

Заключение

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

Ссылки

• Ajax Security
• Anatomy of a subtle JSON vulnerability
• Ruby on Rails security guide
• Ajax (in)security
• Web 2.0 Hacking
• Ajax security: How to prevent exploits in five steps