Захищаємо мобільні застосунки на React Native за допомогою OWASP MAS

💡 Усі статті, обговорення, новини про Mobile — в одному місці. Приєднуйтесь до Mobile спільноти!

Привіт! Я Юлія Межер, Lead Security Engineer у Cossack Labs. Працюю в команді security інженерів та інженерок, займаюся безпекою даних, зокрема, спеціалізуюся на оцінці ризиків та аналізі безпеки мобільних застосунків, а також на впровадженні SSDLC процесів у командах розробки.

Ця стаття може бути корисна security-інженерам, які займаються аудитом React Native застосунків, а також React Native розробникам, які хочуть покращити безпеку написаного ними коду.

Оригінал статті англійською можна знайти тут: Securing React Native Mobile Apps with OWASP MAS | OWASP Foundation. Стаття на сайті OWASP була опублікована в рамках Security Awareness Month. А цю публікацію на DOU присвячую Computer Security Day, що відзначається 30 листопада :)

Захист кожної частини застосунку

React Native — популярний фреймворк для кросплатформної розробки мобільних застосунків, який дозволяє розробникам і розробницям створювати React Native застосунки для iOS та Android, використовуючи єдину кодову базу. Як і будь-яке інше програмне забезпечення, React Native застосунки вразливі до різних загроз.

Для захисту React Native застосунку необхідно проаналізувати всі його компоненти та їхню взаємодію. Це вимагає розуміння кожної частини: React Native, платформ iOS та Android, а також комунікації між ними.

React Native застосунок використовує JavaScript, що виконується на JS-рушії (JavaScript engine). Важливим є розуміння нативних JS-рушіїв та рушія Hermes від Facebook, оскільки вони мають різні вектори загроз. Наприклад, використання нативних JS-рушіїв дозволяє легко витягнути мініфікований JS-код з пакетів застосунків, тоді як Hermes мав кілька зареєстрованих вразливостей у минулому.

Оцінка React Native застосунків за допомогою інструкцій від OWASP

Також важливо дотримуватися загальних практик безпеки мобільних застосунків, як ті, що описані в інструкціях та рекомендаціях від OWASP. Хоча не існує спеціальних інструкцій для React Native, OWASP надає рекомендації щодо покращення безпеки нативних застосунків від поширених загроз та вразливостей:

Рекомендації OWASP MAS для мобільних застосунків використовуються для аудиту безпеки під конкретну платформу (iOS або Android), тоді як рекомендації OWASP для JavaScript можна застосовувати для охоплення інших частин застосунку:

Спільною областю для оцінки кожного крос-платформного застосунку є перевірка методів, що пов’язують нативні та ненативні частини (наприклад, як JavaScript взаємодіє з нативним кодом). Скажімо, методи, які пов’язані між собою, можуть бути не обфускованими, що робить їх більш помітними під час реверсу.

Розділ про стійкість (Level R — Resilience) OWASP MASTG можна використовувати як посібник для захисту від реверс-інженерії та втручання в код, оскільки OWASP описує концепції, які можна застосувати до крос-платформних застосунків.

Нотатка: з моменту публікації цієї статті на сайті OWASP моя команда викликала доповнення до OWASP MASVS — опенсорсний фреймворк для перевірки безпеки мобільних застосунків Cossack Labs Mobile Security Score. Більше про нього — в нашій іншій статті та на GitHub.

React Native бібліотеки: безпечний вибір

JavaScript вносить у React Native одну з найболючіших проблем: управління великою кількістю залежностей та боротьбу з вразливостями в них. Інтеграція інструментів для перевірки залежностей у процес CI/CD, як-то OWASP Dependency-Check або GitHub Dependabot, стає обов’язковою для React Native застосунків.

Багато React Native бібліотек перенесені з екосистеми JavaScript, але вони можуть не пасувати до мобільних застосунків, особливо, коли мова йде про безпеку.

Безпечна бібліотека React Native:

  • Без вразливостей: бібліотека не має відомих вразливостей та має адекватну історію виправлення відомих проблем.
  • Не має відкритих issues з безпеки: перегляньте розділ «Issues» на GitHub, щоб побачити, як розробники та розробниці реагують на проблеми безпеки.
  • Активно підтримується багатьма фахівцями: бібліотека повинна підтримуватися кількома людьми. Особливо важливо, щоб бібліотеки, пов’язані з безпекою, підтримувалися фахівцями з безпеки та криптографії, а в ідеалі — пройшли аудити третьою стороною.
  • Оптимізована для мобільних платформ: наприклад, бібліотека з криптографічно безпечним генератором псевдовипадкових чисел не повинна залежати від кліків миші (пояснення прикладу).
  • Має простий у використанні API: бібліотека має добре задокументовані API, які однаково працюють на iOS та Android.
  • Має ліцензію: зверніть увагу на ліцензію, оскільки не всі open-source бібліотеки є безплатними для використання.
  • Має тести: переконайтеся, що бібліотека має модульні (unit) та інтеграційні тести, особливо якщо вона працює з криптографією або обробляє чутливі дані.

Досліджуйте бібліотеки React Native та їхні залежності, перш ніж використовувати їх для роботи з чутливими даними.

7 кроків до захищеного React Native застосунку

Зробіть React Native застосунок безпечним, дотримуючись кроків, які ми виокремили для спрощення цієї задачі:

  1. Зрозумійте наслідки додавання ще одного постачальника (Facebook) та покладання на безпеку його платформи.
  2. Переконайтеся, що ваша команда має достатню експертизу в галузі безпеки для iOS, Android та React Native. Залежно від рівня ризику застосунку та чутливості даних в ньому, можливо, слід найняти зовнішніх експертів з безпеки.
  3. Навчайте свою команду розробки найкращих практик безпеки, безпечного коду, можливості автоматизації для перевірок безпеки, OWASP Mobile Top-10 та OWASP MAS.
  4. Створюйте засоби контролю безпеки для мобільних застосунків, оскільки React Native застосунки — це все ж таки мобільні застосунки. Використовуйте OWASP MAS як основний посібник. Якщо виникне потреба — додайте засоби контролю безпеки, властиві React Native.
  5. Керуйте залежностями у ваших React Native застосунках та підтримуйте їх в актуальному стані. Автоматизовані аналізатори залежностей і сканування коду — хороший проактивний підхід.
  6. Покривайте функціональність, пов’язану з безпекою, тестами. Особливо якщо вона пов’язана з криптографічними операціями, Secure Enclave та StrongBox Keystore.
  7. Залучайте зовнішніх експертів до аудиту безпеки вашого застосунку. Виправляйте слабкості в коді, покривайте його тестами та додавайте знайдені проблеми до контрольного списку регресійного тестування.

Підтримання безпеки мобільних застосунків на React Native вимагає цілісного підходу до всіх аспектів процесу розробки — від вибору безпечних бібліотек до впровадження безпекового функціоналу.

👍ПодобаєтьсяСподобалось4
До обраногоВ обраному4
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дякую за статтю, особливо за масу корисних посилань!

Який хороший опенсорсний сканер депенденсі для реактівських апок можете порадити? Як раз зараз шукаю це рішення)

Безпечна бібліотека React Native:

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

Моя практика показує, що навіть досвідчені розробники (.NET, JavaScript тощо) не завжди глибоко розбираються в бібліотеках, які використовують. Завдяки Stack Overflow і ChatGPT достатньо базових знань і придатності до монкікодінгу, щоб підключити бібліотеку до проекту іі почати її використовувати. Однак активна розробка й підтримка бібліотеки сама по собі не є ознакою безпеки. Часто навіть ті, хто створює бібліотеку, можуть не враховувати аспектів безпеки, адже їхня основна мета — функціональність, а не захист, вони не є спеціалістами, не кажучи вже про якісь сертифікації або досягнення (black-white, неважливо).

Перші чотири пункти можна розглядати як реальні маркери безпеки. Водночас друга половина (оптимізація, API, ліцензія) не завжди має пряме відношення до безпеки. Наявність тестів є позитивним сигналом, але це лише базовий рівень впевненості. Тести можуть охоплювати лише передбачувані сценарії, а не потенційні вразливості чи неочікувані кейси.

За статтю дякую, кину у беклог порісерчити цю тему.

Підписатись на коментарі