Все що ви хотіли знати про захист від XSS в SAP

Введення
Давненько ми нічого не публікували про 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-код і не тільки вкрасти інформацію про користувацької сесії, що зберігається в cookie, але і проексплуатувати компнент 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;
  • екрануйте ДО и з ненадійних джерел перед тим, як вставляти їх в HTML URL Parameter Values;
  • захистити систему від DOM XSS.
Також в браузерах існує кілька механізмів, які можуть значно знизити ризик XSS-атак:
  • Використовуйте прапор 'HTTPOnly' для cookie – ця міра безпеки буде перешкоджати отриманню даних про користувацької сесії з кукі-файлів через 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(input String) – Кодує рядок для виведення даних між тегами (див. Випадок 1)
  • escapeToJS(input String) – кодує рядок всередині JS declaration рядка ( див. випадок 5)
  • escapeToURL(input String) – кодує рядок, яка являє собою URL (випадок 3). Зверніть увагу, що ця функція викликає 'disableScriptSignatures'.
  • escapeToURL(StringBuffer sb, input String, int maxLength) — кодує рядок, яка являє собою URL (випадок 3). Зверніть увагу, що ця функція викликає 'disableScriptSignatures'.
  • escapeToURL(input String, 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 Service Provider, працюючому на диспетчера, і призначити відповідне значення властивості HttpTrace.
Захист для SAP HANA XS

І насамкінець, розглянемо як захистити від XSS-вразливостей останню платформу – SAP HANA.

З точки зору розробника
Існує кілька правил захисту SAP HANA з допомогою фреймворку SAPUI5.
  • Перевірка введених властивостей управління — ядро SAPUI5 перевіряє значення властивостей, встановлених додатком за типом. Це гарантує, що int завжди є int, і sap.ui.core є рядком.
  • Екранування – використовуйте допоміжні методи щоб екранувати значення властивостей рядка, написаної на HTML:

З точки зору адміністратора
Адміністратор повинен встановити наступні параметри для того, щоб поліпшити безпеку:
  • sessiontimeout = 900. Включає тайм-аут сесії для того, щоб мінімізувати потенційний вікно атаки.
  • HttpOnly cookies включені за замовчуванням.


З точки зору розслідування інцидентів

Для того, щоб ідентифікувати реальні атаки, які сталися через 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 AS for Java and JavaScript
  5. Prevention of Cross-site Scripting SAP HANA protection
  6. Protecting SAP® Applications Based on Java and ABAP™ Against Common Attacks


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.