PXLSecurity LTD., София, България Офанзивна сигурност от 2014[email protected]

Сигурност на мобилни приложения

Тестове за проникване в iOS и Android приложения

Тестваме приложението, данните на устройството, поведението по време на работа и договорения API обхват. Получавате доклад по MASVS, насоки за корекции и повторен тест.

В офертата договаряме платформите и версиите, тестовите акаунти, обхвата на сървърния API и срока за доклада.

Казус: приложение със съхранени данни за достъп →

Проследете приложението отвъд екрана.

01Пакет на приложението
02Устройство и изпълнение
03Сървърен API

Свързваме бинарния файл, устройството и API зад приложението.

Примерна илюстрация на тестването.
3 платформиiOS, Android и Windows в един ангажимент
MASVSОценено спрямо стандарта на OWASP
Устройство + APIПриложението и сървърът, с който общува

Клиентът е в ръцете на нападателя, не във вашите

Всяка друга цел е ваша. Мобилното приложение го раздавате: пакетът стига до всеки, който има достъп до магазина, и от този момент двоичният файл, локалното хранилище и изпълнението са на нападателя, за да ги разглобява на спокойствие. Започваме оттам, откъдето започва и той — разопаковаме публикувания артефакт и го четем — защото вграденото в него не може да бъде отменено с промяна на сървъра. При един ангажимент това беше достатъчно, за да се възстановят идентификационни данни, даващи активна, удостоверена сесия към вътрешен API за данни; цялата верига е публикувана.

Втората половина от работата е частта, до която скенерите никога не стигат: закачане към работещото приложение, за да се види срещу какво защитите му наистина устояват. Откриването на root и jailbreak, фиксирането на сертификати (certificate pinning) и защитата от подправяне са контроли, които очакваме да можем да преодолеем; въпросът, на който отговаряме, е какво пази всяка от тях и какво остава, когато я няма. Тестваме приложението и API, с който то общува, като една система, защото контрол от страна на клиента е контрол само ако сървърът не приема думата на клиента за чиста монета.

Какво тестваме

  • Публикуваният двоичен файл: тайни, ключове, крайни точки и логика, възстановени чрез обратно инженерство
  • Данни в покой: локални бази, използване на keychain и keystore, кешове, резервни копия и журнали
  • Криптография и извеждане на ключове, включително ключове, извлечими от самото устройство
  • Транспорт: валидиране на TLS, фиксиране на сертификати (certificate pinning) и конфигурацията, която го изключва
  • Платформена повърхност: deep links, IPC, експортирани компоненти, WebView и вградени локални сървъри
  • Устойчивост: откриване на root и jailbreak, защита от дебъгване и подправяне, закачане по време на изпълнение
  • Удостоверяване, управление на сесиите и биометрично заключване
  • API на сървъра, с който приложението общува, тестван като част от същата система

Защо има значение

Приложението е единствената част от системата ви, която давате в ръцете на нападателя

Мобилното приложение се различава от системите, чиято инфраструктура контролирате. След публикуването всеки, който го изтегли, разполага с двоичния файл, локалните данни и работещия процес. Това променя начина, по който трябва да защитавате тайните. Вграден в пакета ключ остава във всяко инсталирано копие, докато потребителят не го обнови; някои копия може никога да не бъдат обновени.

Последствията могат да надхвърлят самото приложение. Вградените данни за достъп могат да позволят работа със свързаните системи. Шифроването на локални данни не осигурява очакваната защита, ако нападателят може да възстанови ключа от устройството. Механизми като фиксиране на сертификати (certificate pinning), откриване на root и изключено дебъгване също трябва да се оценят спрямо това какво защитават, защото нападателят контролира клиентското устройство.

Тестваме в реда, в който нападателят изследва приложението: анализираме публикувания пакет, наблюдаваме и променяме поведението на работещия процес, а след това проверяваме API и данните, разкрити от клиента. Препоръките често засягат архитектурата: съхраняване на тайните на сървъра, правилно извеждане на ключове и проверки на правата от страна на сървъра.

Как протича

  1. Обхват и компилации

    Платформите, артефактите на компилациите, тестовите акаунти и достъпът до устройства или емулатори се договарят предварително.

  2. Статичен анализ

    Разопаковаме и подлагаме на обратно инженерство публикувания пакет: тайните, крайните точки, ключовия материал и логиката, които издава.

  3. Динамичен анализ и изпълнение

    Инструментирано тестване на устройство — закачане, прихващане, проверка на хранилището и заобикаляне на контроли — продължено към API зад приложението.

  4. Доклад и повторен тест

    Констатации, съотнесени към контролните групи на MASVS, приоритизирани, след което проверени и потвърдени писмено.

Защо PXLSec

Какво отличава нашето мобилно тестване

  • Ръчен анализ на публикувания пакет

    Анализираме публикувания пакет ръчно. Търсим използваеми данни за достъп, ключове за локалните данни и крайни точки, включително в двоични файлове с премахнати символи или обфускиран код.

  • Проверки на работещото приложение

    Наблюдаваме и променяме поведението на работещото приложение. Проверяваме фиксирането на сертификати (certificate pinning), откриването на root и jailbreak, локалното хранилище и извикванията на методи. Констатациите са подкрепени с доказателства от работещия процес.

  • Отделна проверка за всяка платформа

    При React Native, Flutter или MAUI общата кодова база може да се държи различно на отделните платформи. Тестваме всяка версия в обхвата и оценяваме специфичните за нея слабости и въздействие.

  • Проверка на API зад приложението

    Тестваме API и сървърните услуги зад приложението като част от същата проверка. Проследяваме дали сървърът разчита на клиентски защити, които нападателят може да заобиколи.

Какво получавате

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

  • Резюме за ръководствотоБизнес рискът, представен ясно за ръководството и управителния съвет.
  • Доклад, съотнесен към MASVSВсяка констатация със степен на критичност, доказателства, стъпки за възпроизвеждане и контролната група по MASVS, към която принадлежи — заедно с възстановените артефакти и прихванатия трафик зад нея.
  • Приоритизирани корекцииКонкретни стъпки за отстраняване, съобразени с платформата и рамката, които използвате.
  • Писмо за повторен тестПроверяваме вашите корекции и потвърждаваме писмено закриването им.

Кога ви е нужно

Кога мобилният тест се изплаща

Това са моментите, в които тестването на самото приложение отговаря на въпрос, на който тестването на вашите API не може.

  • Преди изданието да стигне до магазините

    Веднъж публикувана, компилацията не може да бъде изтеглена обратно, а тайната в нея остава активна във всяко инсталирано копие. Тестването на кандидата за издание е последната точка, в която това е евтино за поправяне.

  • Приложението пази данни на устройството

    Офлайн режими, кеширани записи, локални бази и „запомни ме“ означават данни в покой върху хардуер, който не контролирате. Тестваме дали шифроването около тях издържа при пълен достъп до устройството.

  • Корпоративно приложение, доставяно на клиенти

    Ако приложението ви се внедрява в устройствата на други организации, тяхната MDM конфигурация става част от вашия модел на заплахите. Откривали сме управленска настройка по подразбиране, която тихо изключва фиксирането на сертификати (certificate pinning) — контрол, който доставчикът е смятал за активен.

  • Клиент, одитор или преглед в магазина поставя въпроса

    Корпоративните купувачи и регулираните сектори все по-често искат независимо мобилно тестване спрямо признат стандарт. Доклад, съотнесен към MASVS, отговаря директно на това, а писмото за повторен тест документира закриването.

Методология и стандарти

Методологии и източници, на които стъпваме

  • OWASP MASVS (Mobile Application Security Verification Standard)
  • OWASP MASTG (Mobile Application Security Testing Guide)
  • OWASP Mobile Top 10
  • OWASP API Security Top 10
  • NIST SP 800-163 (проверка на мобилни приложения)
  • CWE
  • CVSS и EPSS за контекст на критичността

Често задавани въпроси

Често задавани въпроси

По какво се различава от услугата ви за тестване за проникване?

Нашата услуга за тестване за проникване обхваща мобилното приложение като една цел сред няколко и за много обхвати това е правилният ангажимент. Този тук е задълбочената версия: целият бюджет отива за приложението, тестването е структурирано около контролните групи на MASVS и докладът е съотнесен към тях. Ако тествате уеб платформа, която между другото има и приложение, започнете с тест за проникване. Ако приложението е продуктът или някой ви иска специфична увереност за мобилната част, започнете оттук.

Кои платформи и рамки тествате?

Нативни iOS и Android, както и кросплатформени приложения, изградени с React Native, Flutter, .NET MAUI, Xamarin, Cordova и подобни хибридни стекове. Провеждали сме ангажименти, обхващащи компилациите за iOS, Android и Windows на един и същ продукт в рамките на една работа. Ако използвате нещо необичайно, кажете ни при определянето на обхвата и ще ви отговорим директно дали сме правилната фирма за него.

Нужен ли ви е нашият изходен код?

Не. По подразбиране работим от публикувания артефакт, защото точно това има нападателят, и тестването по този начин е единствената честна мярка за това какво издава двоичният файл. Ако можете да предоставите и изходен код, ще го използваме, за да стигнем по-далеч и по-бързо, но той не е предварително условие.

Какво ви е нужно от нас, за да започнете?

Артефактите на компилациите за всяка платформа в обхвата — IPA файл или покана за TestFlight, APK или AAB — плюс тестови акаунти с ролите, които имат значение, и евентуална сървърна среда, към която бихте предпочели да ни насочите вместо към продукционната. Обикновено не се налага да осигурявате физически устройства.

Ще заобиколите ли откриването на root и фиксирането на сертификати (certificate pinning)?

Почти сигурно да — и това не е констатацията. Контролите за устойчивост от страна на клиента повишават цената на атаката; те не я спират, а всеки доклад, който третира едно заобикаляне като критичен резултат сам по себе си, е пълнеж. Това, което докладваме, е какво е пазел всеки контрол и какво реално остава изложено, след като го няма — а когато контролите са наистина слаби спрямо риска, който приложението носи, го казваме и обясняваме как да бъдат подсилени.

Включен ли е повторен тест?

Да, стандартно. След като екипът ви отстрани констатираните проблеми, тестваме всяка от тях повторно и издаваме писмено потвърждение какво е закрито, което можете да покажете на клиенти и одитори.

Нека обсъдим обхвата на теста.

Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.

Поверителност от първия разговор

Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.

Как защитаваме информацията ви · Политика за поверителност