📱 Внутри суперприложений
Сегодня стандартом современной мобильной разработки является экосистемный подход. Мессенджеры и экосистемные платформы давно перестали быть просто чатами — это полноценные «суперприложения» (super-apps), внутри которых живут сотни мини-приложений (mini-apps): от заказа еды и такси до банковских сервисов и игр 🎮.
Удобно ли это? Для меня спорно, но тренд есть тренд. Пользователю не нужно ставить десяток отдельных приложений, а владелец продвигает свои сервисы.
🏗 Для обычного приложения/суперприложения из Google Play или App Store ОС смартфона изолирует его в «песочнице». Приложения физически не могут просто так залезть в оперативную память, локальное хранилище или сетевой трафик друг друга 🔒.
Но с мини-приложениями всё устроено совершенно иначе. Большинство мини-аппов запускаются не как самостоятельный нативный код, а внутри WebView — встроенного браузерного компонента основного приложения (хозяина платформы).
С точки зрения ОС и само суперприложение, и запущенный внутри него мини-сервис — это единый процесс. Операционная система просто не может выстроить между ними такую же жесткую стену изоляции, как между двумя отдельно установленными программами.
Из этой архитектурной модели и вытекают возможности хоста (владельца платформы):
1️⃣Платформа имеет полный доступ к выполнению кода внутри мини-приложения, может менять логику интерфейса или отслеживать события ввода.
2️⃣ Полный доступ к локальному хранилищу (токены авторизации, ключи API, кэш и пользовательские данные).
3️⃣ Весь трафик мини-аппа идет через сетевой стек хоста.
4️⃣ Хост способен обращаться к системным функциям ОС и делать снимки экрана или элементов интерфейса в момент ввода данных.
Недавно вышло практическое исследование на примере платформы 🌆 MAX, в рамках которого исследователи проверили мини-приложения из самых разных сфер — от финансов и связи до госуслуг и медицины.
Они обнаружили ровно то, о чем я писал выше, а именно возможность:
🔹 Захвата интерфейса ввода.
🔷 Чтения данных в хранилище.
🔷 Маршрутизации трафика.
Исследователи подняли очень правильный вопрос про доверие основной платформе. И, конечно, использовали самый для них "безопасный" пример, где будет минимум хейта от аудитории.
❗️Но они отметили, что это не специальный бэкдор, а возможности любой платформы, которыми может пользоваться хост. Точно такие же возможности технически заложены в любое суперприложение мира, будь то Telegram, WeChat и др. А вот будут ли владельцы этим пользоваться в очередном обновлении? 🤔
💬 Итого: владелец платформы — это абсолютный владелец среды выполнения. Если вы доверяете хозяину приложения, вы автоматически доверяете ему всё, что происходит и вводится внутри каждого встроенного мини-аппа.
📖InfoSec Context | TG | Max | Web
Сегодня стандартом современной мобильной разработки является экосистемный подход. Мессенджеры и экосистемные платформы давно перестали быть просто чатами — это полноценные «суперприложения» (super-apps), внутри которых живут сотни мини-приложений (mini-apps): от заказа еды и такси до банковских сервисов и игр 🎮.
Удобно ли это? Для меня спорно, но тренд есть тренд. Пользователю не нужно ставить десяток отдельных приложений, а владелец продвигает свои сервисы.
🏗 Для обычного приложения/суперприложения из Google Play или App Store ОС смартфона изолирует его в «песочнице». Приложения физически не могут просто так залезть в оперативную память, локальное хранилище или сетевой трафик друг друга 🔒.
Но с мини-приложениями всё устроено совершенно иначе. Большинство мини-аппов запускаются не как самостоятельный нативный код, а внутри WebView — встроенного браузерного компонента основного приложения (хозяина платформы).
С точки зрения ОС и само суперприложение, и запущенный внутри него мини-сервис — это единый процесс. Операционная система просто не может выстроить между ними такую же жесткую стену изоляции, как между двумя отдельно установленными программами.
Из этой архитектурной модели и вытекают возможности хоста (владельца платформы):
1️⃣Платформа имеет полный доступ к выполнению кода внутри мини-приложения, может менять логику интерфейса или отслеживать события ввода.
2️⃣ Полный доступ к локальному хранилищу (токены авторизации, ключи API, кэш и пользовательские данные).
3️⃣ Весь трафик мини-аппа идет через сетевой стек хоста.
4️⃣ Хост способен обращаться к системным функциям ОС и делать снимки экрана или элементов интерфейса в момент ввода данных.
Недавно вышло практическое исследование на примере платформы 🌆 MAX, в рамках которого исследователи проверили мини-приложения из самых разных сфер — от финансов и связи до госуслуг и медицины.
Они обнаружили ровно то, о чем я писал выше, а именно возможность:
🔹 Захвата интерфейса ввода.
🔷 Чтения данных в хранилище.
🔷 Маршрутизации трафика.
Исследователи подняли очень правильный вопрос про доверие основной платформе. И, конечно, использовали самый для них "безопасный" пример, где будет минимум хейта от аудитории.
❗️Но они отметили, что это не специальный бэкдор, а возможности любой платформы, которыми может пользоваться хост. Точно такие же возможности технически заложены в любое суперприложение мира, будь то Telegram, WeChat и др. А вот будут ли владельцы этим пользоваться в очередном обновлении? 🤔
💬 Итого: владелец платформы — это абсолютный владелец среды выполнения. Если вы доверяете хозяину приложения, вы автоматически доверяете ему всё, что происходит и вводится внутри каждого встроенного мини-аппа.
📖InfoSec Context | TG | Max | Web