
Зміст статті
У фінтеху і платіжних сервісах першим перевіряють усе, що веде до грошей: вхід і відновлення акаунта, зміну реквізитів і отримувачів, API (інтерфейс обміну даними між програмами) для мобільного застосунку й партнерів, логіку переказів, лімітів і повернень, а також місця, де опиняються дані карток. Таку перевірку варто доручати команді з досвідом саме банківських і платіжних систем, яка тестує вручну, розуміє вимоги НБУ та PCI DSS і працює лише в погоджених межах за письмовим дозволом.
Нижче: що атакують зловмисники, таблиця «загроза, приклад, що перевірити», регуляторний контекст простими словами з датами документів і чекліст. Коли варто йти далі пентесту і перевіряти весь шлях атаки, теж розповім.
Коротко
- Бізнес-логіка означає правила продукту: ліміти, комісії, повернення, бонуси, порядок підтверджень. Зловмисники шукають, як ці правила обійти, і автоматичний сканер такого не бачить.
- Найдорожчі сценарії: захоплення акаунта, зміна реквізитів, зловживання API і помилки в логіці переказів.
- Положення НБУ для банків прямо вимагає перевіряти захист периметра мережі періодичними тестами на проникнення. [1]
- Якщо компанія зберігає, обробляє або передає дані платіжних карток, на неї поширюється PCI DSS. Чинна версія стандарту 4.0.1. [5] [6]
- Для зрілих команд пентест доповнює Red Team: контрольовану перевірку всього шляху зловмисника до критичної цілі.
Що атакують зловмисники у платежах
Захоплення акаунта
Зловмисник входить у чужий кабінет: пароль із чужого витоку, підбір, перехоплений код із SMS, слабке відновлення доступу або помилка в сесії. У фінтеху після входу гроші доступні одразу, тому вхід, відновлення пароля і зміна номера телефону мають бути найзахищенішими місцями продукту.
Зміна платіжних реквізитів
Зловмисник змінює рахунок отримувача або додає нового, а повторне підтвердження не вимагається чи його можна обійти. У платежах між компаніями це часто поєднується з фішингом: лист від «постачальника» з новим IBAN (номером рахунку отримувача). Перевіряють, чи потрібне повторне підтвердження змін, чи отримує власник повідомлення і чи є затримка для нових отримувачів.
Зловживання API
Мобільний застосунок, кабінет і партнери працюють через API. Типові проблеми: доступ до чужих рахунків і транзакцій заміною номера в запиті, відсутні ліміти на кількість запитів, зайві дані у відповідях. OWASP, відкрита спільнота з безпеки застосунків, окремо виділяє в переліку ризиків API 2023 року доступ до чужих об'єктів і зловживання чутливими бізнес-процесами. [8] [9]
Помилки в логіці переказів
Приклади: два одночасні запити на виведення проходять обидва, хоча грошей вистачає на один; повернення більше за суму покупки; від'ємна сума в переказі; кешбек нараховується кілька разів за одну операцію. Такі речі знаходить людина, яка розуміє продукт, а не сканер.
Дані карток поза захищеною зоною
Зловмисники шукають, де номер картки (PAN, повний номер на картці) з'являється там, де його не мало б бути: у журналах, аналітиці, листах підтримки, резервних копіях. Що менше систем торкаються даних карток, то менша зона дії PCI DSS і то менше, що можна атакувати.
Загроза, приклад, що перевірити
| Загроза | Приклад | Що перевірити |
|---|---|---|
| Захоплення акаунта | Вхід за паролем з іншого витоку, перехоплений код із SMS | MFA (другий фактор при вході), ліміти спроб, відновлення доступу, зміну телефону й пошти |
| Зміна реквізитів | Новий отримувач або IBAN без повторного підтвердження | Підтвердження змін, повідомлення власнику, затримку для нових отримувачів |
| Доступ до чужих даних через API | Заміна номера рахунку в запиті показує чужі транзакції | Перевірку прав на кожен об'єкт, ролі, ключі партнерів |
| Масовий перебір через API | Перебір номерів телефонів чи карток | Ліміти запитів, захист від ботів, зайві поля у відповідях |
| Логіка переказів | Два одночасні виведення, від'ємна сума, повторне повернення | Блокування одночасних операцій, перевірку сум і статусів |
| Дані карток поза зоною | Повний номер картки в журналах або аналітиці | Пошук номерів у журналах, маскування, межі зони з даними карток |
| Внутрішній доступ | Підтримка бачить повні дані карток і клієнтів | Ролі в адмінці, журнал дій, мінімальні права |
Регуляторний контекст простими словами
Нижче лише те, що прямо написано в текстах документів на сайтах НБУ та PCI SSC. Це не юридична консультація: які саме вимоги діють для вашої ліцензії, уточнюйте з юристом в актуальній редакції документів.
Банки. Положення про організацію заходів із забезпечення інформаційної безпеки в банківській системі України затверджене постановою Правління НБУ № 95 від 28 вересня 2017 року і набрало чинності 1 березня 2018 року. Воно зобов'язує банк впровадити систему управління інформаційною безпекою згідно з ДСТУ ISO/IEC 27001 і перевіряти захист периметра мережі періодичними тестами на проникнення. [1]
Кіберзахист банків. Положення про організацію кіберзахисту в банківській системі України затверджене постановою № 178 від 12 серпня 2022 року. Серед методів зовнішнього аудиту безпеки воно прямо називає тестування на проникнення. [2] Постанова № 24 від 25 лютого 2025 року запровадила щорічний звіт банку про стан інформаційної безпеки станом на 31 березня. У ньому банк зазначає, чи проводив за звітний період тест на проникнення периметра, хто його виконував і чи виправлені критичні та високі вразливості. [3]
Платіжні системи. Положення про захист інформації та кіберзахист у платіжних системах затверджене постановою НБУ № 43 від 19 травня 2021 року. Воно визначає вимоги до захисту інформації та кіберзахисту у сфері переказу коштів для платіжних організацій, учасників платіжних систем і операторів послуг платіжної інфраструктури. [4]
Картки. PCI DSS означає галузевий стандарт захисту даних платіжних карток, який веде PCI SSC, Рада зі стандартів безпеки платіжних карток. Він поширюється на тих, хто зберігає, обробляє або передає дані власників карток. [5] Версію 4.0.1 опубліковано в червні 2024 року без нових чи вилучених вимог; версія 4.0 перестала діяти 31 грудня 2024 року, а нові вимоги четвертої версії стали обов'язковими з 31 березня 2025 року. [6] Керівництво PCI SSC з пентесту описує тест на проникнення щонайменше раз на рік і після значних змін, а якщо мережу розділено, ще й перевірку того, що зона з даними карток справді відокремлена від решти систем. [7]
Як обрати виконавця з банківським досвідом
Банківський досвід видно не з логотипів, а з відповідей на конкретні запитання. Попросіть розповісти без назв клієнтів, як команда тестувала дистанційне банкінгове обслуговування, платіжні API чи процесинг, як працювала з робочими системами, де помилка коштує грошей, і як виглядав звіт для служби безпеки банку та для НБУ.
Я з 2019 року працював пентестером у проєктах для банків і платіжних систем, а потім керував командою кібербезпеки у фінансовому секторі. Усе це під NDA (угодою про конфіденційність), тому замість назв я показую знеособлені приклади звітів і методику.
Якщо у вас уже є служба безпеки, моніторинг і регулярні пентести, наступний крок Red Team: перевірка, чи помітить команда цільову атаку і як швидко зупинить її. Для більшості фінтех-компаній на ранній стадії правильний старт інший: ручний пентест кабінету, мобільного застосунку і API.
Чекліст для фінтеху і платіжного сервісу
Завантажити чекліст підготовки (PDF)PDF · A4
FAQ
Чи є в Україні компанії з кібербезпеки з досвідом банківської безпеки?
Так, і найкраще їх перевіряти запитаннями: хто саме тестуватиме, які банківські чи платіжні системи ця людина вже перевіряла, як команда працює з робочими системами і чи можна побачити знеособлений звіт. Назв клієнтів зазвичай не дають через NDA, і це нормально.
Чи зобов’язаний банк в Україні робити пентест?
Положення НБУ № 95 вимагає перевіряти захист периметра мережі банку періодичними тестами на проникнення, а щорічний звіт банку для НБУ питає, чи такий тест проводився за звітний період. [1] [3]
Чи потрібен PCI DSS, якщо картки обробляє платіжний провайдер?
Стандарт поширюється на тих, хто зберігає, обробляє або передає дані карток, а також на системи, що можуть вплинути на їхню безпеку. Якщо картку вводять лише на сторінці провайдера, ваша зона значно менша, але не завжди нульова. Обсяг уточнюйте з провайдером і аудитором.
Що перевіряти першим у новому платіжному сервісі?
Вхід і відновлення доступу, зміну реквізитів, права доступу в API і логіку переказів. Саме там помилка найшвидше перетворюється на втрачені гроші.
Чим Red Team відрізняється від пентесту для фінтеху?
Пентест шукає якомога більше вразливостей у погоджених системах. Red Team перевіряє, чи дійде зловмисник до конкретної цілі, наприклад до платіжного шлюзу, і чи помітить це ваша команда. Red Team має сенс, коли базові пентести вже регулярні.
Посилання
- НБУ: постанова № 95 від 28.09.2017, Положення про організацію заходів із забезпечення інформаційної безпеки в банківській системі України bank.gov.ua
- НБУ: постанова № 178 від 12.08.2022, Положення про організацію кіберзахисту в банківській системі України bank.gov.ua
- НБУ: постанова № 24 від 25.02.2025, зміни з питань інформаційної безпеки та кіберзахисту bank.gov.ua
- НБУ: постанова № 43 від 19.05.2021, Положення про захист інформації та кіберзахист у платіжних системах bank.gov.ua
- PCI SSC: PCI Data Security Standard pcisecuritystandards.org
- PCI SSC: Just Published: PCI DSS v4.0.1 (June 2024) blog.pcisecuritystandards.org
- PCI SSC: Penetration Testing Guidance v1.1 (2017) listings.pcisecuritystandards.org
- OWASP API Security Top 10 2023: API1 Broken Object Level Authorization api-security.owasp.org
- OWASP API Security Top 10 2023: API6 Unrestricted Access to Sensitive Business Flows api-security.owasp.org



