Все что вы хотели знать про защиту от XSS в SAP

в 7:02, , рубрики: sap, SAP ERP, SAP HANA, sap security, xss, Блог компании «Digital Security», информационная безопасность

Введение

Давненько мы ничего не публиковали про SAP, и сегодня мы рассмотрим уязвимость, которая затрагивает любое SAP решение от старинного R/3 до новомодной HANA. Имя этой уязвимости – межсайтовый скриптинг (XSS). Статья эта, вопреки нашему обычному повествованию про поиск и эксплуатацию уязвимости, будет по большей части посвящена защите от данной уязвимости.

Межсайтовый скриптинг — одна из самых распространенных уязвимостей вообще, и в продуктах SAP в частности. Так, за 12 лет в SAP было обнаружено 628 XSS-уязвимостей, что составляет 22% от всех уязвимостей в SAP. Только исследователи ERPScan нашли 52 XSS-уязвимости в SAP, и то потому, что больше времени уходило на написание Advisory и бюрократические моменты, чем на непосредственный поиск уязвимостей. Более подробная информация по всем уязвимостям может быть изучена в нашем исследовании "Analysis of 3000 vulnerabilities in SAP", а мы переходим к основной части.

image

Десять самых распространенных уязвимостей в продуктах 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 в страницу.

image

Пример страницы, уязвимой к межсайтовому скриптингу

Как мы видим, атакующий может использовать переменную ‘id’ для того, чтобы внедрять код (строка 15), потому что значение переменной ‘id’ будет отображаться у пользователя без изменений (строка 28).
Эксплойтом для этой уязвимости служит следующий запрос:

example1234567.com/dir/start/error_msg.jsp?id=1111">

Общие меры защиты

Чтобы избежать подобных уязвимостей, нужно всегда экранировать/фильтровать пользовательский ввод. В нашем примере с DOM XSS, переменная 'ID' должна быть повторно заложена в методе 'URLEncoder.encode ()', потому что ее значение используется в качестве параметра HTTP-запроса.
image

Действия, необходимые для того, чтобы закрыть уязвимость

Как итог, представим еще несколько советов, как предотвратить возможность межсайтового скриптинга на этапе разработки:

  • Никогда не вводите данные из непроверенных источников (включая любой пользовательский ввод) в 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"%>
<html><body><form>
<% data: inputvalue type string.
inputvalue = request->get_form_field( 'x' ).
%>
<input type=text name=x value="<%=inputvalue%>">
<input type=submit>
</form></body><<video></video>/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 (вывод между тегами)


<head>
<title>[CASE1]</title>
</head>
<table>
<tr>
<td>Username</td>
<td>[CASE1]</td>
</tr>
</table>

Случай 2 (вывод внутри тегов, но выводимое значение – не URL)


<form name="CASE2">
<input type="text" name="user" value="[CASE2]">
<input type="text" name="user" value='[CASE2]'>
</form>
<a name="[CASE2]">Click here</a>

Случай 3 (вывод — URL)


<a href="CASE3" style="[CASE3]"><img src="[CASE3]" lowsrc="[CASE3]"></a>

Случай 4 (вывод внутри SCRIPT’а, но вывод – не дескриптор строки)

<script>
var a = [CASE4];
[CASE4];
</script>

Случай 5 (вывод – declaration строки)

<script>
var a = '[CASE5]';
alert("[CASE5]");
</script>

В качестве альтернативы можно использовать класс 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) и Султану Абубакирову за неоценимую помощь в написании этой статьи.

Ссылки

  1. Logging additional information
  2. ABAP protection SAP Encoding Functions for AS ABAP
  3. Java protection
  4. SAP Encoding Functions for AS Java and JavaScript
  5. Prevention of Cross-site Scripting SAP HANA protection
  6. Protecting SAP® Applications Based on Java and ABAP™ Against Common Attacks

Автор: Digital Security

Источник

Поделиться новостью

* - обязательные к заполнению поля