Актуальність питання захищеності персональних даних тільки збільшується, це стосується як великих компаній, так і меншого бізнес-сегменту. QA Team Lead у IT-компанії Kitsoft Ярослав Беззубець проаналізував поширені проблеми у застосунках малого та середнього бізнесу, через які можна у кілька кліків отримали персональні дані користувачів. 

Привіт, мене звати Ярослав, я працюю на посаді QA Team Lead. Крім контролю якості продукту я також відповідаю за його безпеку. Проте кібербезпека для мене — не лише обов’язок, а й хобі. 

Я аналізую застосунки, якими користуються мільйони українців та я сам. На жаль, багато з них містять помилки в налаштуваннях, які лежать на поверхні, тож зловмисник може отримати інформацію про персональні дані користувачів у декілька кліків. 

У колонці я продемонструю реальні приклади таких помилок та надам рекомендації, як бізнесу покращити безпеку застосунків.

Для мене важливо, щоби застосунки, які ми всі використовуємо щодня були безпечними. У колонці я не вказую назви компаній та прибрав впізнавану айдентику зі скриншотів — моєю метою було не розслідування, а професійний інтерес. Крім того, з усіма компаніями, приклади яких наводжу, було проговорено про наявність цих вразливостей ще кілька місяців тому. Та, на жаль, на сьогодні жодна з компаній їх не виправила. 

Загалом, наведені тут приклади є досить поширеними, тому сподіваюся, вони допоможуть бізнесу звернути увагу на безпеку своїх застосунків, а користувачам – бути більш обізнаними щодо кібербезпеки.

Політика конфіденційності VS Реальність

Кожен із нас відчуває в повсякденному житті позитивний вплив онлайн-присутності малого та середнього бізнесу – супермаркетів, аптек, доставки їжі, інтернет-магазинів. Це зручно, і ми віримо, що політика конфіденційності працює, а наші персональні дані зберігаються надійно. 

Проте реальність може виявитися іншою. Під час аналізу я виявив незахищеність та багато помилок у налаштуваннях безпеки таких застосунків. 

Я не буду тут говорити про складні технічні вразливості, такі як 0-day, віддалене виконання коду, SQL-ін’єкції, XSS. Помилки, які будуть продемонстровані можна класифікувати згідно з методологією OWASP TOP 10, як A01:2021 – Порушений контроль доступу та A07:2021 – Помилки ідентифікації та автентифікації.

Ці вразливості розташовані в самій архітекторі застосунку, тобто – налаштуванні бізнес-логіки опрацювання замовлення: від реєстрації, передачі запиту з інтерфейсу користувача до сервера й назад.

У наведених прикладах, можна побачити, як зловмисник у кілька кліків може отримати доступ до особистої інформації користувачів, зокрема контактних даних, деталей замовлення, місце проживання, деталей листування тощо. 

Приклад № 1. Вебзастосунок із доставлення суші

Коли ми замовляємо доставку їжі через вебзастосунок, нас, зазвичай, просять попередньо авторизуватися та вказати свій мобільний номер для отримання коду підтвердження. На перший погляд, це здається логічним і безпечним, але придивимося ближче.

У запиті для надсилання коду підтвердження реєстрації крім номера, який ми вказали, є ще один параметр «number», якому встановлено значення «4». Цей параметр визначає довжину коду підтвердження. Просто змінивши це значення на «1», зловмисник може отримати коротший код підтвердження. Це означає, що достатньо лише перебирати цифри від 0 до 9, щоб авторизуватися в чужому кабінеті користувача. 

Так будь-хто з мінімальними технічними навичками може отримати із застосунку доступ до персональної інформації, включно з контактними даними та інформацією про замовлення.

Приклад № 2. Віджет технічної підтримки користувачів

В інтерфейсі застосунків малого та середнього бізнесу різних галузей діяльності присутні віджети технічної підтримки. Це знайомі всім віконечка, що спливають поверх екрана, у яких пропонуються написати консультанту на випадок, якщо виникли питання чи проблеми з користуванням сервісом.

Якщо проаналізувати запити, які надсилаються від клієнта до сервера під час використання віджета, ми побачимо що в тілі POST-запиту «/auth», який надсилається клієнтом, передається параметр «customer_id».

У відповідь від сервера надходить «Bearer token», який використовується в наступних запитах, для отримання інформації про листування користувача. 

Якщо ми спробуємо в POST-запиті «/auth» змінити значення параметра «customer_id», на менше значення, у відповідь ми отримаємо «Bearer token» попереднього користувача, і зможемо за допомогою GET-запиту «/customer/chat/{chatId}/messages/transcript», підставивши в заголовок запиту токен, отримати у відповідь деталі листування попереднього користувача.

Так, за зміни ідентифікатора клієнта зловмисник може отримати доступ про переписку будь-якого клієнта. Це особливо небезпечно для застосунків, повʼязаних із фінансовою галуззю. Наприклад, людина хоче через застосунок оформити позику, відповідно в переписці може йти уточнення ІНН, дівочого прізвища матері, даних карток, банківських реквізитів. 

Приклад № 3. Мобільний застосунок доставлення їжі, та CRM-система опрацювання замовлень

Деякі ІТ-компанії пропонують готові рішення для малого та середнього бізнесу, наприклад, мобільний застосунок для доставлення їжі та CRM-система для опрацювання замовлень. 

У таких застосунках кастомізується лише інтерфейс, а взаємодія застосунку з CRM-системою залишається стандартною. Якщо з’являється вразливість, вона впливає на всі підключені застосунки одразу. 

Під час аналізу одного з таких сервісів виявилося, що після авторизації за допомогою мобільного телефону відбувається звернення до CRM-системи за допомогою GET-запиту «/api/clients.getClients». У цьому запиті передаються query-параметри «phone» та «token». Після виконання запиту сервер повертає інформацію, яка містить ім’я, телефон, пошту, деталі замовлень та іншу інформацію про користувача. 

Відповідно, якщо ми змінимо значення параметра «phone» на номер іншого зареєстрованого користувача застосунку, отримуємо доступ до його особистих даних.

Тобто зловмисник може взяти знайомий чи будь-який номер і за ним дізнатися інформацію про людину в популярному застосунку — персональні дані, номер картки, що вона купує тощо. Окрім того, змінити суму бонусів на своєму рахунку й потім розрахуватись нею. 

Приклад № 4. Мобільний додаток магазину косметики

У цьому прикладі схожі проблеми. Після виконання авторизації в застосунку, викликається POST-запит «/api/im/customer/info», у тілі якого передається номер телефону та OTP-код підтвердження. Цей запит повертає інформацію про поточного користувача. 

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

Проте, якщо із запиту прибрати параметр, який відповідає за OTP-код, і виконати його повторно, отримаємо персональні дані за номером цього користувача, усі його замовлення та накопичені бонуси. 

Кібербезпека — це безперервний процес

У цій статті розглянули конкретні приклади недоліків у застосунках, які використовуються щоденно мільйонами українців. Зокрема, виявили проблеми в механізмах авторизації, обробці запитів та взаємодії між мобільними застосунками та CRM-системами. 

Забезпечення конфіденційності даних користувачів та їхня безпека повинні мати найвищий пріоритет та рівень захисту під час розробки. 

Кілька рекомендацій, які допоможуть посилити безпеку мобільних застосунків для бізнесу:

1. Запит відправлення коду підтвердження не повинен містити параметра, що визначає його довжину.
2. Довжина коду підтвердження повинна бути мінімум 6 цифр.
3. Під час введення неправильного коду підтвердження понад 3 рази, код має бути деактивованим.
4. Під час надсилання декількох кодів підтвердження, активним має бути лише останній.
5. Параметр, що відповідає за ідентифікацію користувача, повинен складатися не лише з послідовно присвоєних цифр, а й також має бути захищеним від перебору.
6. Токен користувача не має визначатися на основі одного ідентифікатора.
7. Запити, надіслані від імені одного користувача з модифікованими параметрами, які відповідають за ідентифікацію користувача, не мають повертати інформацію, яка містить конфіденційні дані інших користувачів.
8. Під час списання бонусів в офлайн-магазинах має бути додаткова верифікація номера користувача, наприклад відправлятися код підтвердження.
9. Перед релізом в AppStore та PlayMarket застосунки мають обов’язково проходити аудит із безпеки на потенційні помилки.

Пересічний користувач, а часто і власник малого чи середнього бізнесу, без спеціальних знань навряд може перевірити захищеність застосунку. Під час купівлі ІТ-системи бізнес може запросити в розробників сертифікат аудиту з безпеки або звіт про виконаний тест на проникнення. У ньому мають бути відсутні помилки критичного, високого, та середнього рівня. Це дає хоча б мінімальні гарантії, що в додатку відсутні архітектурні вразливості.

Що стосується користувачів, важливо враховувати ризики і зважувати, чи варто і, якщо так, то кому довіряти інформацію про себе.

Разом із тим, ми всі маємо бути свідомі, що те, що здавалось безпечним учора, може виявитись вразливим уже завтра. Тому перевірка ІТ-систем на вразливості і їх виправлення мають бути неперервним процесом.