Android-приложениям перекроют доступ к IDFA при отказе юзера от рекламы

Android-приложениям перекроют доступ к IDFA при отказе юзера от рекламы

Android-приложениям перекроют доступ к IDFA при отказе юзера от рекламы

Компания Google уведомила создателей Android-приложений о грядущем изменении порядка обработки рекламных ID, которые позволяют отслеживать преференции пользователя. Чтобы исключить злоупотребления этими идентификаторами, их будут сбрасывать (обнулять), если пользователь отказался от рекламы.

Рекламный идентификатор (IDFA) присутствует во всех приложениях и обновлениях, публикуемых в Google Play. Он предоставляет разработчикам возможность монетизации продуктов за счет показа персонализированной рекламы. Отказаться от трекинга с помощью IDFA пользователь может, отключив в настройках опцию «Реклама».

К сожалению, подобный отказ редко останавливает приложения, которые также могут использовать IDFA для аналитики или противодействия мошенничеству. Новая мера Google призвана повысить прозрачность в отношении использования ПДн, а также усилить безопасность и приватность пользователей.

Блокировка доступа к IDFA в соответствии с волеизъявлением пользователя будет вводиться постепенно: в этом году для Android 12, в будущем — для всех остальных устройств с установленным клиентом Google Play.

Разработчиков существующих программ с доступом к IDFA обяжут удалить все собранные пользовательские данные. Для тех, кто использует этот идентификатор с другой целью — для аналитики, противодействия мошенничеству, Google пообещала придумать альтернативу.

Другой техногигант, Apple, тоже недавно принял похожие меры для защиты пользователей мобильных устройств от трекинга. Его новый механизм App Tracking Transparency даже круче: он работает по принципу opt-in, а не opt-out, то есть запрещает приложениям отслеживать действия пользователей без их согласия.

Пример Apple, видимо, не дает покоя Google. В конце прошлого года создатель iOS обязал разработчиков приложений публиковать в App Store информацию об использовании ПДн. Через четыре месяца такое же требование выставил Google Play.

Расширения Chrome могут слить секреты URL через атаку по стороннему каналу

Как оказалось, расширения Chrome можно использовать для слива кодов авторизации, сеансовых ID и других секретов из URL любой открытой вкладки. Никаких специальных разрешений для этого не понадобится, только доступ к declarativeNetRequest API.

Этот механизм, пришедший на смену webRequest API, позволяет расширениям сообщать браузеру, что следует изменить или заблокировать на загружаемой странице (заголовки, реклама, трекеры).

Правила обработки запросов при этом добавляются динамически, а фильтрация осуществляется по регулярным выражениям, соответствующим подмножествам знаков, которые могут присутствовать на определенных позициях в URL.

Исследователь Луан Эррера (Luan Herrera) обнаружил, что блокировку, диктуемую правилами, Chrome производит почти мгновенно, за 10-30 мс, а остальные запросы выполняются дольше (~50-100ms) — из-за сетевых подключений. Эту разницу во времени расширение может использовать для бинарного поиска с целью посимвольного слива URL.

// extensions/browser/api/web_request/extension_web_request_event_router.cc:1117-1127
case DNRRequestAction::Type::BLOCK:
  ClearPendingCallbacks(browser_context, *request);
  DCHECK_EQ(1u, actions.size());
  OnDNRActionMatched(browser_context, *request, action);
  return net::ERR_BLOCKED_BY_CLIENT;

Оракул для подобной тайминг-атаки строится с использованием chrome.tabs.reload для перезагрузки страницы и перехватчика chrome.tabs.onUpdated, помогающего отследить событие status === "complete". Замер времени между reload и завершением загрузки покажет, заблокирован запрос или успешно обработан.

Повторение проверок и бинарного поиска позволяет получить полный URL (с довеском после «?»), затратив на каждый знак строки несколько прогонов. Таким образом, можно незаметно для пользователя украсть включенные приложением в адрес секреты — токены OAuth и сброса пароля, API-ключи, ссылки на контент, закрытый для поисковых систем.

Проверка PoC проводилась на Windows 11 24H2 с использованием Chrome разных версий:

  • 144.0.7559.97 (Stable)
  • 145.0.7632.18 (Beta)
  • 146.0.7647.4 (Dev)
  • 146.0.7653.0 (Canary)

В Google подтвердили возможность подобной атаки по стороннему каналу, но заявили, что решить проблему нереально.

RSS: Новости на портале Anti-Malware.ru