Контролюйте свої ABAP-розробки

Сьогодні на 2014 рік, російські компанії, що впровадили продукти компанії SAP витратили велику кількість ресурсів на клієнтську доопрацювання рішень. Однак не привносять ці розробки додаткові ризики у ваші бізнес-процеси? Компанія SAP гарантує якість коду в своїх додатках завдяки ручному аудиту поставляється коду і використання найбільш сучасних механізмів статичного та динамічного аналізу своїх продуктів на різні уразливості. Автор цих рядків провів дослідження в університеті р. Саарбрюккен (Німеччина) метою якого був аналіз кодів продуктів SAP (рішення щодо електронної комерції) самими сучасними інструментами статичного аналізу і переконався у високій якості цього коду. Програмний код компанії SAP проходить ручний і автоматизований аналіз, тисячі спеціальних тест-кейсів. Клієнтський програмний код найчастіше не може бути так повно проаналізовано, особливо, в умовах стислих термінів проектів, в яких доводиться працювати. Варто задуматися про якість клієнтського коду у ваших системах. Важливо розуміти, що перевірка авторизації користувача (синонім безпеки SAP для багатьох підприємств) не допоможе запобігти використання такого роду помилок, оскільки користувач, що використовує помилки в коді, виходить за межі повноважень, визначених системним адміністратором.

Розглянемо помилки, які можуть бути присутніми в клієнтському програмному коді.

Ін'єкція коду

Залишена можливість ін'єкції коду — одна з найбільш поширених та найбільш небезпечних вразливостей класифікації OWASP. Більшість широко відомих вразливостей, включаючи OpenSSL Heartbleed (29.04.2014) і злом майданчики Ebay (22.05.2014) пов'язані з ненавмисно залишеної можливістю ін'єкції користувальницького введення всередину програми. Небезпека такого роду помилок полягає в практично непередбачувані результати виконання вразливих програм. Результатом ін'єкції SQL коду може бути як витік паролів, так і повне видалення всіх даних системи. Додаткова проблема, пов'язана з такими уразливими полягає в складності їх пошуку автоматизованими засобами. Пошук на основі правил і патернів не дасть позитивного результату з-за великої кількості помилково сформульованих припущень. Єдиним по-справжньому ефективним способом пошуку помилок може бути статичний аналіз потоку даних, що надходить в програму (Information Flow Control). Статичний аналіз потоку даних дозволяє простежити дані, які надходять в потенційно небезпечні точки і висунути найбільш точні припущення про наявність або відсутність уразливості ін'єкції коду.

Обхід каталогу

Іншою небезпечною помилкою програмного коду є ненавмисно залишена можливість підміни даних вводу, яка дозволяє обхід каталогу. Атакуючий, що використовує таку вразливість отримує можливість зчитувати або записувати дані, що знаходяться поза зумовленого каталогу. Таким чином, можуть бути зчитані критичні системні налаштування або перезаписані конфігураційні файли, що може вивести систему з ладу на достатньо довгий проміжок часу. Можливі досить специфічні варіанти використання цієї помилки. Наприклад, виклик оператора OPEN DATASET dset FILTER iv_filter, відкриває файл для читання, у системі Unix поставляє дані з считываемого файлу в зумовлений процес, який може здійснювати непередбачені дії на рівні операційної системи. Таким чином, неправильна конфігурація ОС і вразливий код, що не мають помилок окремо, можуть призводити до критичних наслідків працюючи спільно. Про проблеми некоректних конфігурацій ви дізнаєтеся в наших наступних статтях.

Помилки авторизації


Керуються ваші програмісти концепцією повноважень у розробці своїх програм? Згідно з цією концепцією, доступ до будь-якого функціонального блоку програми має бути заборонений до тих пір, поки не визначено інше. На жаль, на багатьох проектах, розмежування доступу відбувається на рівні транзакцій, що робить можливим комбінування різних існуючих повноважень з метою доступу до забороненої інформації. Наприклад, використання оператора CALL TRANSACTION (який масово використовується розробниками) на проектах з розмежуванням доступу на рівні транзакцій є небезпечним. Без вказівки WITH AUTHORITY-CHECK оператор CALL TRANSACTION дозволяє переходити з будь-якої іншої транзакції. Можливий також випадок, коли перевірка авторизації є, але зроблена вона неправильно. Такі випадки також потрібно знаходити і виправляти.

Бекдори

До цього ми розглянули деякі випадки вразливостей, коли програмісти скоїли ненавмисні помилки, в результаті чого код став вразливим. Однак, можливі також випадки, коли програміст навмисно змінює хід виконання програми для певних користувачів (недокументовані можливості»), або взагалі залишає так званий бекдор, який дозволяє обходити всі перевірки, виставлені системою. Розробник може робити бекдор і без зловмисних цілей, як наприклад отримання повноважень SAP_ALL для «ефективної» роботи на проекті впровадження. Очевидно, що це не благає тих ризиків, які привносить наявність бекдорів. У мережі існує велика кількість прикладів таких бекдорів, які можуть бути просто скопійовані і перенесені в продуктивну систему. Відловити наявність документованих можливостей і бекдорів дуже складно, по-перше, з-за величезної кількості клієнтського коду, по-друге-за особливостей мови програмування SAP. ABAP дозволяє виконувати код на льоту і зберігається в СУБД, тобто може бути захований дуже і дуже глибоко.

Як шукати помилки?

Існує кілька різних способів пошуку вразливостей в коді, найбільш досконалим з яких є статичний аналіз потоку даних. У SAP Netweaver AS присутній модуль, що реалізує аналіз потоку даних на наявність або відсутність вразливостей (Code Vulnerability Analysis). Є сертифіковані партнерські рішення, які дозволяють сканувати код додатків на наявність вразливостей. SAP Code Vulnerability Analysis (CVA) заснований на інструменті Code Inspector, який вже багато років дозволяє перевіряти клієнтський код на наявність потенційно небезпечних конструкцій, але на відміну від Code Inspector, використовує у своїй роботі аналіз потоку даних. Найбільш доцільним є використання CVA з першої стадії проекту — зі стадії розробки (до перенесення розробок далі по ландшафту), т. к. внесення виправлень пізніше (наприклад, при продуктивної експлуатації) є більш складним і витратним. Впровадження CVA передбачає не тільки пошук і виправлення помилок, але зміна самого підходу до розробки стандартів на підприємстві. Внесення будь-якої нової розробки в продуктивну систему повинно бути санкціоновано експертом, що керується у своїй роботі найсучаснішими інструменту аналізу розробок.

Підсумок

Цією статтею ми хотіли показати, що питання безпеки продуктів SAP набагато більш широкі, ніж це часто представляється нашим клієнтам. Важливо чітко уявляти собі весь спектр проблем, які можуть виникати при підтримці рішень на базі SAP. Для цього потрібно бути в курсі поточного стану справ, про це ми і будемо розповідати вам в рамках циклу статтею.

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

0 коментарів

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