Безпека Android. Унікальні ідентифікатори

Унікальні ідентифікатори, це про що взагалі?

У цій серії статей ми з вами розглянемо найважливіші та найпроблемніші завдання розробки та тестування, пов’язані з безпекою Android-додатків. Кожен розділ міститиме докладний опис тієї чи іншої проблеми, де будуть озвучені best practices, а також приклади коду та рекомендації. Наприкінці кожного розділу виділемо список ключових питань, на яких слід зосередитися в процесі розробки та тестування мобільних застосунків із високим рівнем ризику - який обробляє фінансові, конфіденційні або особисті дані. Однак варто пам’ятати, що безпека Android застосунку - це індивідуальна характеристика і залежить від безлічі факторів. Те що ми розглянемо не може вважатися вичерпним, а використання тих чи інших механізмів захисту залежить від ризику та потенційних наслідків атаки на конкретний застосунок. Нарешті, треба не забувати, що екосистема Android дуже фрагментована, і це створює додаткові проблеми при розробці та тестуванні. Ці best practices можуть бути незастосовні до старих версій SDK, і розробникам, які бажають підтримувати такі SDK, доведеться докласти додаткових зусиль, щоб впоратися з усіма версіями та зберегти при цьому хорошу якість коду.

В подальшому нами буде розглянуто:

• Унікальні ідентифікатори в Android

• Виявлення та обхід root прав

• Робота з мережею

  • HTTPS

  • Certificate Pinning

• Локальне зберігання даних

• Захист від зворотного інжинірингу

• Webview в Android

Почнемо ми з самої теоритичної частини - унікальних ідентифікаторів Android

Унікальні ідентифікатори Android

У цьому розділі мова буде йти про унікальні ідентифікатори. Як би банально не звучало, але - не треба забувати використовувати ідентифікатор, що відповідає його призначенню. Наприклад, для рекламних цілей треба використовувати - advertismentId. У разі ідентифікації у додатках, чутливих до безпеки, не рекомендовано використовувати ідентифікатори, пов’язані з апаратним забезпеченням, оскільки це може спричинити проблеми з боку безпеки. Також потрібно уникати використання ідентифікаторів, які надаються Google, через досить часті зміни (самим же Google). Це може призвести до несумісності з різними версіями Android та інших неприємностей.

Рекомендується також використовувати незалежні та унікальні ідентифікатори, такі як - UUID, це забезпечить унікальність і незалежність від Google. Але про це ми поговоримо нижче.

Ідентифікація пристрою

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

Сучасний підхід до 2FA у мобільних додатках передбачає, що одним із факторів автентифікації є знання пароля/PIN. Другий фактор - це те, що є у користувача, як правило, це конкретний мобільний пристрій. Цей мобільний пристрій повинен мати унікальний ідентифікатор, який зіставляється з ідентифікатором користувача в процесі реєстрації. Одні з самих популярних 2FA додатків:

• Google Authenticator

• Microsoft Authenticator

• 2FAS

Ідентифікатори, які надаються SDK

У старі часи Android було доволі популярно використовувати одну з характеристик, яка пов’язана з апаратним забезпеченням. Така як IMEI, MAC-адреса або DeviceId (зазвичай серійний номер). 

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

У якийсь момент Google ввела новий ідентифікатор - androidId . Різниця між androidId (Secure.Settings.ANDROID_ID - SSAID) і deviceId, який використовувався раніше, в тому, що androidId змінювався при кожному скиданні налаштувань - він не був статичним. Також, починаючи з Android 8 (Oreo), значення ідентифікатора androidid стало унікальним для кожного конкретного застосунку, а точніше, комбінації імені застосунку і ключа підпису. Це означає, що androidid для застосунку A не міг бути доступний застосунку B.

Те, що компанія Google запровадила у 2018 року - сама ж Google прибрала у 2020 році 🪦. Новою рекомендацією стало уникати апаратних ідентифікаторів (гудбай androidId). Згідно з документацією, androidid могли отримати тільки додатки зі спеціальними дозволами оператора або системні додатки з дозволом READ_PRIVILEGED_PHONE_STATE. Дозвіл READ_PRIVILEGED_PHONE_STATE надається лише програмам, підписаним ключем платформи, і привілейованим системним програмам.

Як наслідок, кожен застосунок, що використовує androidId, раптово переставав працювати на пристроях з Android 10. До речі, прикладами таких застосунків є “IKO” - мобільний банкінг одного з найбільших польських банків і “mObywatel”, що постачається польським урядом і дає змогу ідентифікувати громадян.

Інший ідентифікатор, що надається Google, - advertisingId, повинен використовуватися виключно в рекламних цілях (як випливає з назви, ваш КЕП). Він не підходить для ідентифікації пристрою, оскільки може бути скинутий користувачем вручну.

Яких рекомендацій варто таки дотримуватися?

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

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

Одним із найкращих і найбезпечніших рішень є UUID у версії 4 (Universally Unique IDentifier). Він унікальний у всьому світі, безпечний, простий у використанні та не залежить від Google. Єдине, що потрібно зробити, - це згенерувати ідентифікатор у процесі реєстрації та надійно зберігати його (далі ми розглянемо це окремо в блоці - “Локальне зберігання даних”).

Трохи про UUID

UUID (англ. universally unique identifier “всесвітньо унікальний ідентифікатор”) - стандарт ідентифікації, що використовується у створенні програмного забезпечення, стандартизований Open Software Foundation (OSF) як частина DCE - середовища розподілених обчислень. Основне призначення UUID - це дозволити розподіленим системам унікально ідентифікувати інформацію без центру координації. Таким чином, будь-хто може створити UUID і використовувати його для ідентифікації будь-чого з прийнятним рівнем впевненості, що цей ідентифікатор ненавмисно ніколи не буде використаний для чогось ще. Тому інформація, позначена за допомогою UUID, може бути поміщена пізніше в загальну базу даних без необхідності вирішення конфлікту імен.

UUID являє собою 16-байтний (128-бітний) номер. У канонічному поданні UUID зображують у вигляді числа в шістнадцятковій системі числення, розділеного дефісами на п’ять груп у форматі 8-4-4-4-4-12. Таке представлення займає 36 символів:

123e4567-e89b-12d3-a456-426655440000xxxxxxxx-xxxx-Mxxx-Nxxx-xxxxxxxxxxxx

Загальна кількість унікальних ключів UUID (без урахування версій) становить 2128 = 25616 або близько 3,4 × 1038. Це означає, що генеруючи 1 трильйон ключів кожну наносекунду, перебрати всі можливі значення вдасться лише за 10 мільярдів років.

Зверніть увагу, що попередні версії UUID (Universally Unique IDentifier нижче за версію 4) застаріли і не вважаються безпечними, рекомендується уникати їх використання.

Підсумок

Нижче наведено приклад UUID, androidID, instanceId / firebaseId і advertismentId:

const val firebaseId = "fUq13Zf5QZiG5S_zPuzB2z"
const val advertisementId = "ca-app-pub-3940256099942544"
const val vuid = "b845d9a2-536a-4900-982c-8f8bb726ad5a"
const val androidId = "fc8fd5d216ebb394"

У підсумку ми можемо виділити такі рекомендації:

• використовуйте ідентифікатори, що відповідають їхньому призначенню.

• пам’ятайте, що Google часто змінює свої рекомендації та відмовляється від підтримки тих чи інших ідентифікаторів.

• для застосунків із високим ступенем ризику рекомендується використовувати унікальний ідентифікатор, що не залежить від платформи Android, наприклад UUID версії 4.