Введение
Давненько мы ничего не публиковали про SAP, и сегодня мы рассмотрим уязвимость, которая затрагивает любое SAP решение от старинного R/3 до новомодной HANA. Имя этой уязвимости – межсайтовый скриптинг (XSS). Статья эта, вопреки нашему обычному повествованию про поиск и эксплуатацию уязвимости, будет по большей части посвящена защите от данной уязвимости.
Межсайтовый скриптинг — одна из самых распространенных уязвимостей вообще, и в продуктах SAP в частности. Так, за 12 лет в SAP было обнаружено 628 XSS-уязвимостей, что составляет 22% от всех уязвимостей в SAP. Только исследователи ERPScan нашли 52 XSS-уязвимости в SAP, и то потому, что больше времени уходило на написание Advisory и бюрократические моменты, чем на непосредственный поиск уязвимостей. Более подробная информация по всем уязвимостям может быть изучена в нашем исследовании "Analysis of 3000 vulnerabilities in SAP", а мы переходим к основной части.
Десять самых распространенных уязвимостей в продуктах SAP
?
Описание атаки
Опасность межсайтового скриптинга состоит в том, что данная уязвимость позволяет атакующему выполнить произвольный JavaScript-код в рамках пользовательской сессии. Этот код может помочь заполучить доступ к куки, токенам сессии и другой критически важной информации, которая хранится браузером. Атакующий может получить доступ к пользовательской сессии и заполучить важную бизнес-информацию, а в самом худшем случае – получить полный контроль над системой. С помощью XSS также можно незаконно подменить данные, отображающиеся на сайте, и провести фишинг-атаку и тд и тп. Думаю, про XSS вы и так знаете предостаточно, но без вводной не обойтись.
XSS обычно возможны в следующих случаях:
- Сервер не экранирует специальные символы, вводимые пользователем — '"& <>;
- Сервер позволяет отправлять в качестве значения опасные параметры, что в свою очередь позволяет выполнить JavaScript-код из других источников.
Традиционно выделяют следующие типы межсайтового скриптинга:
Хранимый межсайтовый скриптинг
В данном типе вредоносный код должен храниться на сервере. Например, атакующий может внедрить код путем изменения имени объекта на сервере (например, имя файла в системе документооборота). Если атака прошла успешно, то когда легитимный пользователь запросит информацию о списке файлов, его браузер запустит вредоносный код, загруженный злоумышленником.
Когда-то очень давно мы провели подобную атаку во время одной из работ по анализу защищенности SAP. В этой организации SAP SRM использовалась для проведения торгов, поэтому каждый поставщик мог разместить свою документацию с информацией об услугах и расценках. Система была уязвима к хранимому межсайтовому скриптингу, поэтому нам удалось внедрить JavaScript-код в поле имени файла. Когда сотрудник компании из отдела закупок открывал папку со списком файлов, чтобы увидеть недавно загруженные документы, вредоносный код автоматически запускался, и атакующий получал доступ к аккаунту сотрудника. Используя этот аккаунт, он мог получить доступ к тендерной документации конкурентов и заполучить информацию об их услугах и расценках, что позволяло выиграть торги, скорректировав свои цены. Уязвимость была закрыта SAP (SAP Security Note 1284360).
Еще одним примером хранимого межсайтового скриптинга в SAP является нашумевшая XSS уязвимость в системе SAP Afaria с крайне интересным способом эксплуатации. Такая уязвимость, как хранимый межсайтовый скриптинг, крайне опасна и легка в эксплуатации, но встречается сильно реже, чем отраженный межсайтовый скриптинг, о котором ниже.
Отраженный межсайтовый скриптинг
Этот тип уязвимости более распространен. В данном случае вредоносный код не хранится на сервере, а выполняется пользователем в тот момент, когда он открывает ссылку примерно следующего вида:
example.com/search.php?q=
Чтобы проэскплуатировать уязвимость, нужно послать ссылку пользователю. Этот тип XSS менее мощный, так как требует пользовательского взаимодействия, но более популярный, чем хранимый межсайтовый скриптинг, и примеров таких уязвимостей сотни.
Как пример критически опасной атаки, можно внедрить JavaScript-код и не только украсть информацию о пользовательской сессии, хранящуюся в куки, но и проэксплуатировать компнент ActiveX, установленный на компьютере жертвы. Таким образом, можно будет получить полный доступ к его компьютеру через одну из уязвимостей в ActiveX. В результате вы получите доступ к корпоративной внутренней сети и станете на один шаг ближе к SAP-серверу со всеми корпоративными данными.
DOM-XSS
В данном случае атакующий изменяет среду DOM (Document Object Model) страницы браузера таким образом, чтобы один из скриптов на странице выполнил вредоносный JavaScript-код.
Рассмотрим этот тип более детально на примере уязвимости, закрытой SAP Security Note 1788080. Баг существует потому, что пользовательский ввод в JSP-скрипте ‘error_msg.jsp’ не фильтруется, что позволяет атакующему внедрить JavaScript code в страницу.
Пример страницы, уязвимой к межсайтовому скриптингу
Как мы видим, атакующий может использовать переменную ‘id’ для того, чтобы внедрять код (строка 15), потому что значение переменной ‘id’ будет отображаться у пользователя без изменений (строка 28).
Эксплойтом для этой уязвимости служит следующий запрос:
example1234567.com/dir/start/error_msg.jsp?id=1111">
Общие меры защиты
Чтобы избежать подобных уязвимостей, нужно всегда экранировать/фильтровать пользовательский ввод. В нашем примере с DOM XSS, переменная 'ID' должна быть повторно заложена в методе 'URLEncoder.encode ()', потому что ее значение используется в качестве параметра HTTP-запроса.
Действия, необходимые для того, чтобы закрыть уязвимость
Как итог, представим еще несколько советов, как предотвратить возможность межсайтового скриптинга на этапе разработки:
- Никогда не вводите данные из непроверенных источников (включая любой пользовательский ввод) в HTML-страницу;
- экранируйте фрагменты HTML из ненадежных источников перед тем, как вставлять их в HTML Element Content;
- экранируйте HTML-атрибуты из ненадежных источников перед тем, как вставлять их в HTML Element Content;
- экранируйте JavaScript-код из ненадежных источников перед тем, как вставлять его JavaScript Data Values;
- экранируйте JSON из ненадежных источников перед тем, как вставлять его в HTML Element Content или использовать в JSON.parse;
- экранируйте фрагменты CSS из ненадежных источников перед тем, как вставлять их в HTML Style Property Values;
- экранируйте URL’ы из ненадежных источников перед тем, как вставлять их в HTML URL Parameter Values;
- защищайте систему от DOM XSS.
Также в браузерах существует несколько механизмов, которые могут значительно снизить риск XSS-атак:
- Используйте флаг ‘HTTPOnly’ для куки – эта мера безопасности будет препятствовать получению данных о пользовательской сессии из куки-файлов через JavaScript;
- установите политику безопасности контента – эта мера безопасности запретит использование JavaScript’а внутри домена;
- защита HTTPS Cookies — Защитите куки при использовании HTTPS-протокола.
А сейчас давайте подробнее рассмотрим, как защитить различные SAP-платформы от XSS-атак со стороны разработчика, администратора и специалиста по расследованию инцидентов.
Защита SAP NetWeaver ABAP
С точки зрения разработчика
Для всех Web-приложений, где разрешен ввод параметров, следует использовать методы энкодинга, обеспеченные ICF-обработчиком. Реализация доступна как API в двух вариантах:
- Встроенная функция в ABAP ESCAPE (доступна в SAP_BASIS >= 731);
- Класс внедрения в CL_ABAP_DYN_PRG.
В SAP NetWeaver версии 7.0 enhancement package 3 и выше (SAP_BASIS >= 731) используйте встроенную в ABAP функцию ESCAPE(). Более подробная информация доступна в документации ключевых слов ABAP для функции ESCAPE().
| HTML / XML | out = escape(val = val format = cl_abap_format=>e_xss_ml) |
| JavaScript | out = escape(val = val format = cl_abap_format=>e_xss_js) |
| URL | out = escape(val = val format = cl_abap_format=>e_xss_url) |
| CSS | out = escape(val = val format = cl_abap_format=>e_xss_css) |
Для версий SAP_BASIS 702, 720 и ниже, существует реализация ABAP OO в классе CL_ABAP_DYN_PRG.
| Контекст | Метод |
| HTML / XML | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_XML_HTML(val) |
| JavaScript | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_JAVASCRIPT(val) |
| URL | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_URL(val) |
| CSS | out = CL_ABAP_DYN_PRG=>ESCAPE_XSS_CSS(val) |
Подробная информация об этих расширениях в SAP Security Note 1582870. Теперь рассмотрим особенности защиты от XSS с специфичных SAP-технологиях.
Для WebDynpro ABAP
Для WebDynpro ABAP не нужно беспокоится о защите от межсайтового скриптинга. Безопасность обеспечивается самой платформой.
Для Business Server Pages (BSP)
Для BSP следует использовать директивы страницы. Для более подробной информации обратитесь к SAP Security Note 1600317 и SAP Security Note 1638779. Преимущество этих BSP-атрибутов страницы состоит в том, что архитектура BSP гарантирует, что используется самая безопасная версия энкодинга.
Для BSP следует использовать директивы страницы: <% page language=«abap» forceEncode=«html|url|javascript|css»%>
После установки SAP Security Note 1600317 существующие директивы страниц также используют обновленный BSP-компилятор, который поддерживает HTML-энкодинг всех вводимых на странице выражений.
В следующем примере все вводимые выражения используют HTML-энкодинг. Он затрагивает только напечатанные выражения на BSP страницах и ничего не делает с параметрами тегов.
Например:
<%@page language="abap" forceEncode="html"%>
<% data: inputvalue type string.
inputvalue = request->get_form_field( 'x' ).
%>
</html>
Глобальный атрибут страницы определяет кодировку по умолчанию в пределах страницы и всех включенных фрагментов страниц. Кроме глобальных атрибутов страницы, вы можете использовать следующие символы для энкодинга событий специального ввода (переопределение глобальных настроек):
- <%html=...%>: энкодинг HTML
- <%url=...%>: энкодинг URL для параметров названий или значений URL
- <%javascript=...%>: энкодинг JavaScript
- <%css=…%> : энкодинг CSS
- <%raw=...%> (без энкодинга, то есть глобальные настройки энкодинга, которые были установлены в директиве страницы, были отключены)
Для расширений BSP
Для библиотеки BSP HTMLB установите атрибут forceEncode тега <htmlb:content> в значение ENABLED для того, чтобы переключиться на внутреннее кодирование (по умолчанию отключено). ENABLED означает, что расширение будет использовать соответствующее кодирование в зависимости от контекста, в котором используется значение:<htmlb:content forceEncode="ENABLED|BACKWARDS_COMPATIBLE">
- ENABLED: Это означает кодировать все и всегда. Этот параметр перекрывает все другие атрибуты кодирования, и их не нужно устанавливать;
- BACKWARDS_COMPATIBLE: Это значение по умолчанию. Обычные атрибуты кодирования активны, как определено выше.
Кроме того, атрибут архитектуры htmlb:content определяет возможную архитектуру, которую поддерживает страница. Валидны следующие значения: CLASSIC, DESIGN2002, DESIGN2003, DESIGN2008, а также их соединения, разграниченные знаком (+). Старая архитектура не поддерживает значения CLASSIC и DESIGN2002 (возможно, небезопасны) и вследствие этого больше не должны использоваться.
<htmlb:content forceEncode="ENABLED" design="DESIGN2003+DESIGN2008">
Если дизайн не определен, то используется design=CLASSIC. Поэтому мы рекомендуем заменить значение по умолчанию на одно из упомянутых выше.
Mixed BSP-страницы HTML и HTMLB теги
Атрибут forceEncode страницы BSP директивы page и атрибут forceEncode HTMLB тега контента не зависят друг от друга. Первый контролирует энкодинг переменных за пределами расширений, тогда как второй – энкодинг в расширении HTMLB. Таким образом, для смешанных страниц, где используется HTML в сочетании с расширением BSP, нужно установить оба параметра
Для Internet Transaction Server (ITS) и HTML Business
Для Internet Transaction Server (ITS) и HTML Business, доступны следующие функции энкодинга:
- xss_url_escape()
- xss_html_escape()
- xss_wml_escape()
- xss_css_escape()
- xss_js_escape()
HTML Business
При обращении к значениям переменных, используйте символы HTML-Бизнеса: то есть, используя обратные кавычки (`) или разделитель , энкодинг контролируется глобальными параметрами:
- ~auto_html_escaping=1: глобально активирует энкодинг,
- ~new_xss_functions=1: глобально активирует использование обновленной библиотеки XSS.
Это может быть отменено локально в шаблонах с помощью установки параметра ~html_escaping_off=1/0, который позволяет включить или отключить экранирование.
То, где и как эти параметры определены, зависит от версии SAP_BASIS:
- Для внешних ITS (версии <= 6.40), установите их в свойствах Internet Service в транзакции SE80.
- Для внутренних ITS (версии >= 6.40), установите их в свойствах GUI в транзакции SICF следующим образом:
Что касается версии 7.20, не нужно устанавливать параметр ~new_xss_functions, так как обновленная XSS-библиотека используется во всех случаях.
При данном подходе следует тщательно тестировать приложения, так как могут встречаться случаи, когда кодирование слишком общее, что может привести к ложному кодированию. В подобных случаях можно установить параметр ~html_escaping_off=”X”, чтобы деактивировать автоматическое кодирование и вызывать названные функции вручную. Для получения более подробной информации, см. SAP Security Note 1488500.
Для Business HTML (BHTML)
Функции HTMLBusiness Template Library (например, SAP_TemplateNonEditableField()) всегда кодируются должным образом и не могут быть отключены или включены. Для получения более подробной информации, см. SAP Security Note 916255.
Для ручного энкодинга
Вы также можете вручную энкодить выходные данные используя функции, названные выше. В данном случае, кодируйте все выходные параметры.
С точки зрения администратора
Администратор должен установить следующие параметры, чтобы повысить безопасность и минимизировать вероятность атак через XSS-уязвимости:
- http/security_session_timeout = 900; Включает тайм-аут сессии для того, чтобы минимизировать потенциальное окно атаки.
- icf/set_HTTPonly_flag_on_cookies = 0; Установка куки как HttpOnly повышает безопасность системы, поскольку это исключает доступ к куки в веб-браузере через клиентские скрипты, апплеты, плагины и тому подобное. Установите флаг HTTPOnly, чтобы защитить куки и Logon tickets от передачи их на вредоносный хост при помощи XSS-уязвимости.
Чтобы изменить параметр, запустите транзакцию RZ10, выберите (в поле Profile) нужный профиль (например, DEFAULT.PFL, если параметр должен быть применен для всей SAP-системы). Для того, чтобы создать, изменить или удалить параметр, в профиле выберите Extended maintenance и нажмите кнопку изменить. Когда изменения сделаны, нажмите кнопку Copy.
С точки зрения реакции на событие и расследования инцидентов
Для того, чтобы идентифицировать реальные атаки, произошедшие из-за межстайтового скриптинга, а также из-за некоторых других уязвимостей в веб-интерфейсе, рекомендуется настроить следующие параметры:
- настройте параметр icm/HTTP/logging_0
- Настройте параметр icm/security_log,
Защита для SAP NetWeaver J2EE
Теперь рассмотрим как же защитить сервер приложений SAP NetWeaver J2EE
С точки зрения разработчика
Для AS Java энкодинг доступен при помощи класса tc_sec_csi.jar. Это статический класс и интерфейс, который обеспечивает энкодинг для HTML/XML, JavaScript, CSS и URL. Также возможно использование методов открытого класса StringUtils (com.sap.security.core.server.csi.util.StringUtils):
Вот неполный список методов. Более детально вы можете посмотреть в документе Securing SAP from XSS vulnerabilities
- escapeScriptEndTag(String pStr) - Подготавливает строку, которая будет использоваться для определения строк javascript с особым вниманием к тегу скрипта;
- escapeToHTML(String input) – Кодирует строку для вывода данных между тегами (см. Случай 1)
- escapeToJS(String input) – кодирует строку внутри JS declaration строки ( см. случай 5)
- escapeToURL(String input) – кодирует строку, которая представляет собой URL (случай 3). Обратите внимание, что эта функция вызывает 'disableScriptSignatures'.
- escapeToURL(StringBuffer sb, String input, int maxLength) - кодирует строку, которая представляет собой URL (случай 3). Обратите внимание, что эта функция вызывает 'disableScriptSignatures'.
- escapeToURL(String input, int maxLength) - кодирует строку, которая представляет собой URL (см. случай 3). Обратите внимание, что эта функция вызывает 'disableScriptSignatures'.
- urlEncode(String s) – незначительно измененная версия метода URLEncoder.encode
Ниже ряд примеров, которые используют те или иные функции энкодинга.
Случай 1 (вывод между тегами)
[CASE1]
Username
[CASE1]
Случай 2 (вывод внутри тегов, но выводимое значение – не URL)
Click here
Случай 3 (вывод - URL)
Случай 4 (вывод внутри SCRIPT’а, но вывод – не дескриптор строки)
Случай 5 (вывод – declaration строки)
В качестве альтернативы можно использовать класс XSSEncoder.
Имя класса - XSSEncoder (класс с именем пакета: com.sap.security.core.server.csi.XSSEncoder).
Методы использования для каждого контекста следующие:
Контекст
Метод
HTML / XML
out = XSSEncoder.encodeHTML( in ) and XSSEncoder.encodeXML( val );
JavaScript
out = XSSEncoder.encodeJavaScript( val );
URL
out = XSSEncoder.encodeURL( val );
CSS
out = XSSEncoder.encodeCSS( val );
Для получения информации об этих расширениях, см. SAP Security Note 1590008.
WebDynpro Java
Для WebDynpro Java, можно не волноваться о XSS. Безопасность обеспечивается самой архитектурой.
SAP UI Development Kit for HTML5
Для SAP UI Development Kit для HTML5, функция энкодинга представлена как плагин jQuery во фреймворке /_core/src/main/js/jquery.sap.encoder.js.
Функции использования в каждом контексте следующие:
Контекст
Функция
HTML / XML
jQuery.sap.encodeHTML(sValue) and jQuery.sap.encodeXML(sValue)
JavaScript
jQuery.sap.encodeJS(sValue)
URL
jQuery.sap.encodeURL(sValue)
CSS
jQuery.sap.encodeCSS(sValue)
С точки зрения администратора:
Администратор должен выставить следующие параметры для того, чтобы улучшить безопасность:
- Global_app_config/session_config/sessionTimeout = 900. Включает тайм-аут сессии для того, чтобы минимизировать потенциальное окно атаки.
- SystemCookiesDataProtection = true. Установка куки как HttpOnly повышает безопасность вашей системы, поскольку это исключает доступ к куки в веб-браузере через клиентские скрипты, апплеты, плагины и тому подобное. Установите флаг HTTPOnly, чтобы защитить куки и Logon tickets от передачи их на вредоносный хост при помощи XSS-уязвимости.
- ume.logon.httponlycookie= True. Logon tickets представляют собой куки, которые используются для аутентификации юзера и Single Sign-On в J2EE Engine. Значение “True” означает, что информация о сессии может быть передана только по HTTP и получение куки через document.cookie (типичный пример XSS-атаки) невозможен.
- SessionIPProtectionEnabled = True. Указывает, включена ли защита IP сессии. Когда этот параметр установлен в значение True, HTTP-сессии не могут быть доступны с разных IP. Обрабатываются только запросы с IP, который начал сессию.
С точки зрения расследования инцидентов
Для того, чтобы идентифицировать реальные атаки, произошедшие из-за XSS-уязвимостей, а также из-за некоторых других уязвимостей в веб-интерфейсе, рекомендуется настроить следующие параметры.
- LogCLF = TRUE в файле настройки http.properties позволяет logging в формате CEF.
- ArchiveOldLogFiles = ON. Log Configurator предоставляет возможность автоматического архивирования файлов журнала. Журналы записываются в виде набора файлов. Когда последний файл завершен, новые логи начинают перезапись старых логов. Если нет архивирования журналов доступа, все журналы будут перезаписываться.
- Включить логирование дополнительной информации.
- HttpTrace= Enable. Чтобы включить HTTP-трассировку для получения дополнительной информации, запустите ConfigTool. Откройте вкладку Свойства в HTTP Provider Service, работающем на диспетчере, и назначьте соответствующее значение свойства HttpTrace.
Защита для SAP HANA XS
И напоследок, рассмотрим как защитить от XSS-уязвимостей самую последнюю платформу – SAP HANA.
С точки зрения разработчика
Существует несколько правил защиты SAP HANA с помощью фреймворка SAPUI5.
- Проверка введенных свойств управления - ядро SAPUI5 проверяет значение свойств, установленных приложением по типу. Это гарантирует, что int всегда является int, и sap.ui.core является строкой.
- Экранирование – используйте вспомогательные методы чтобы экранировать значение свойств строки, написанной на HTML:
С точки зрения администратора
Администратор должен установить следующие параметры для того, чтобы улучшить безопасность:
- sessiontimeout = 900. Включает тайм-аут сессии для того, чтобы минимизировать потенциальное окно атаки.
- HttpOnly куки включены по умолчанию.
С точки зрения расследования инцидентов
Для того, чтобы идентифицировать реальные атаки, произошедшие из-за XSS-уязвимостей, а также из-за некоторых других уязвимостей в веб-интерфейсе, рекомендуется настроить следующие параметры.
- Для контроля всех HTTP (S) запросов, обрабатываемых в SAP HANA, вы можете настроить внутренний веб-диспетчер. Для того чтобы настроить веб-диспетчер на запись всех HTTP (S) запросов, добавьте свойство icm/http/logging _ 0:
- global _ auditing _ state = true. Следующий параметр настройки для аудита хранится в global.ini, в настройках секции аудита. Это позволяет записывать дополнительную информацию, такую как выходы из системы и запросы в базы данных, которые могут иметь отношение к расследованию XSS-атак. Эти настройки можно найти в SAP HANA Administration Console –> Security HDB –> Auditing Status menu.
Выводы
Вот в общем-то и все, что хотелось сказать про защиту от XSS. Получилось немало, но это еще раз показывает, насколько сложны бизнес-приложения SAP и как много в них разнообразных возможностей. И это только информация об XSS-уязвимостях – сотой доле проблем которые могут встретиться при разработке программ под SAP. Надеюсь эта статья вам поможет безопасно писать приложения под SAP и хотя бы минимизировать количество XSS-уязвимостей. Ниже дополнительная информация по XSS уязвимостям в SAP.
Да, еще хотелось бы сказать спасибо исследователям Дмитрию Частухину ( chipik ) и Султану Абубакирову за неоценимую помощь в написании этой статьи.
?
Ссылки