|
Professor Seleznov
|
Спойлер: оба, но по-разному - и это важно понимать.
Каждый раз, когда слышим «у нас все нормально с безопасностью, мы же не банк», что-то внутри сжимается. За этой фразой обычно стоят токены аутентификации в SharedPreferences, SQL-запросы без параметризации и Firebase без правил доступа. Эта статья - попытка честно сравнить два мира, найти точки пересечения и разобраться, почему одни проблемы одинаковые, а другие - принципиально разные.
Исходные данные: OWASP Top 10 Web 2025, OWASP Mobile Top 10 2024, статистика NVD/CVE-базы, данные реальных пентестов, IBM Cost of a Data Breach 2024.
Масштаб проблемы: цифры, которые отрезвляют
По данным OWASP и NVD за последние годы картина не меняется кардинально - меняются только детали.
Инъекции стабильно лидируют по числу CVE среди всех веб-категорий. Проблема существует с 90-х годов, описана в каждом учебнике по безопасности - и все равно встречается в production-приложениях ежедневно.
Сбои аутентификации - credential stuffing, session fixation, отсутствие MFA на критичных операциях. По данным OWASP, уязвимости аутентификации встречаются в десятках тысяч приложений ежегодно.
Криптографические ошибки - MD5 для паролей, ключи в коде, TLS 1.0 на продакшене. Причем правильные решения существуют и хорошо задокументированы уже много лет.
Нарушения контроля доступа (веб) - по данным OWASP, выявляются в более чем 90% протестированных приложений. Именно поэтому эта категория занимает первое место в Web Top 10 третий рейтинг подряд.
По мобильным приложениям картина не радостнее. Исследования в рамках OWASP Mobile Security Testing Guide показывают:
- Большинство мобильных приложений содержат хотя бы одну уязвимость из Mobile Top 10
- Небезопасное хранение данных (токены в незащищенных хранилищах, незашифрованные базы) - одна из самых частых находок при аудитах.
- При статическом анализе APK захардкоженные API-ключи обнаруживаются значительно чаще, чем хотелось бы думать.
Последствия реальные: утечки персональных данных, финансовые потери, регуляторные штрафы (152-ФЗ, GDPR). По данным IBM Cost of a Data Breach 2024, средняя стоимость утечки данных составила 4,88 миллиона долларов, а среднее время обнаружения и сдерживания взлома - около 194 дней. И это без учета репутационного ущерба.
OWASP Top 10: детальное сравнение
Прежде чем идти в детали, посмотрим на оба списка рядом и сразу найдем общее.
OWASP Top 10: сравнение
Несмотря на разные платформы, веб и мобильные приложения страдают от одного и того же набора фундаментальных уязвимостей: слабый контроль доступа и ошибки аутентификации позволяют злоумышленникам действовать от чужого имени или получать данные без прав; неправильная криптография - будь то слабые алгоритмы или незашифрованное локальное хранилище - делает чувствительные данные читаемыми; небезопасная конфигурация открывает лишние точки входа на обеих платформах; проблемы цепочки поставок означают, что стороннее ПО становится вектором атаки задолго до попадания в продакшн; наконец, недостаточная проверка ввода и инъекции остаются хронической проблемой везде, где пользовательские данные попадают в интерпретатор без санации - неважно, браузер это или мобильное приложение.
В вебе уникальные угрозы сосредоточены вокруг серверной логики и наблюдаемости: ненадежный дизайн означает, что архитектурные просчеты закладываются еще на этапе проектирования бизнес-процессов и не поддаются патчингу без переписывания; сбои целостности ПО и данных бьют по CI/CD-пайплайнам и механизмам автообновления; а отсутствие нормального логирования и мониторинга делает атаку невидимой - злоумышленник может месяцами находиться внутри периметра, пока никто не смотрит в логи. Неправильная обработка исключений довершает картину: стектрейсы и внутренние сообщения об ошибках утекают в браузер, давая атакующему карту внутренней инфраструктуры.
В мобилке угрозы смещаются в сторону самого устройства и экосистемы приложения: небезопасное взаимодействие через незащищенные IPC-каналы, deep links и межпроцессные интенты открывает атаки, которых в вебе просто не существует; недостаточная защита бинарного кода позволяет реверс-инжинирить приложение, извлекать захардкоженные ключи и переупаковывать APK с вредоносной начинкой; недостаточный контроль конфиденциальности отражает специфику мобильных разрешений - геолокация, камера, контакты утекают через сторонние SDK незаметно для пользователя. Все это проблемы, которые веб-разработчик даже не рассматривает как вектор угрозы.
Архитектура определяет угрозы
Почему списки различаются - понятнее становится, когда смотришь на архитектуру.
Ключевой вывод из схемы: в вебе злоумышленник атакует сервер, используя браузер как инструмент. В мобилке злоумышленник может атаковать само приложение - скачать, декомпилировать, модифицировать, запустить на рутованном устройстве с перехватом трафика.
При этом бэкенд общий - и мобильные, и веб-клиенты работают с одним API. Уязвимость на сервере опасна для обоих.
Общие уязвимости: где риски одинаковы
1. Аутентификация и авторизация
Это самый большой пласт проблем, одинаково актуальный для обеих платформ. Типичные ошибки:
Ссылка на код тут
IDOR - изменение чужих данных (мобильный API):
Ссылка на код тут
Безопасное управление сессией (PHP):
Ссылка на код тут
2. Инъекции
Встречаются везде, где есть пользовательский ввод и интерпретатор.
SQL-инъекция (Python):
Ссылка на код тут
XSS (JavaScript/PHP):
Ссылка на код тут
Инъекция в WebView (Android/Kotlin) - пересечение веб и мобилки:
Ссылка на код тут
3. Небезопасные зависимости (Supply Chain)
Supply chain атаки получили отдельную категорию в обоих топах - и это не случайно: один скомпрометированный пакет дает злоумышленнику доступ к тысячам организаций одновременно.
Как проверять зависимости (SCA - Software Composition Analysis)
Небезопасные зависимости легко ловить через SCA-подход - просто сканируйте дерево пакетов. В JS/Node.js запускайте npm audit, в Python - pip-audit, а в PHP - используйте встроенную команду composer audit или внешнюю утилиту local-php-security-checker. Добавьте Dependabot в репозиторий для авто-обновлений и настройте CI/CD так , чтобы сборка падала при High/Critical уязвимостях - это сильно снижает риски и дает спокойствие. Попробуйте на своем проекте, ждем результат.
Специфика мобильных приложений
Локальное хранилище: иерархия безопасности
Самая частая ошибка в мобильной разработке - хранить чувствительное там, куда доберется любой с рутованным телефоном.
Правильное хранение токена в Android (Kotlin) с использованием EncryptedSharedPreferences:
Ссылка на код тут
iOS - Keychain (Swift):
Ссылка на код тут
Certificate Pinning: защита сетевого трафика
Без pinning любой, у кого есть доступ к сети (или само устройство), может перехватить трафик через прокси.
Android Network Security Config (без кода):
Ссылка на код тут
Защита бинарного кода: уникальная мобильная проблема
В вебе исходники на сервере недоступны. В мобилке - APK можно скачать из магазина, декомпилировать через jadx и читать код почти как исходник на Java.
Специфика веб-приложений
Небезопасная конфигурация: инфраструктурные грехи
С ростом сложности инфраструктуры (Kubernetes, облако, микросервисы) неправильная конфигурация стала #2 в OWASP Web 2025. Примеры из реальной жизни:
Минимальный набор заголовков безопасности (Express.js):
Ссылка на код тут
Ненадежный дизайн: что не починишь рефакторингом
Это категория, которая появилась в OWASP 2021 и остается - потому что проблема реальная. Некоторые уязвимости возникают не из-за плохого кода, а из-за плохих архитектурных решений.
Пример: если система принимает цену товара от клиента, никакой input validation не поможет - нужно менять дизайн. Если механизм восстановления пароля основан на «секретных вопросах» - это дизайнерский провал.
Платформы: что дают, чего не дают
Выводы
Проблема не в платформе, а в подходе. Большинство уязвимостей - не экзотика. Хардкод ключей, отсутствие валидации, слабое хеширование - они существуют не потому что разработчики не знают как правильно, а потому что «работает же, потом поправим».
Бэкенд - общая точка ответственности. Мобильное приложение и веб-сайт могут работать с одним API. Если API уязвим к IDOR - оба клиента уязвимы. Безопасность серверной части важнее защиты конкретного клиента.
Мобилка сложнее с точки зрения клиентской безопасности. Разработчику веба не нужно думать о декомпиляции своего кода или краже данных при физическом доступе к устройству. У мобильного разработчика эта ответственность есть - нужно выбирать правильные хранилища, шифровать данные, защищать бинарник.
Supply chain - новая реальность. И в вебе (npm), и в мобилке (CocoaPods, Maven) зависимости - это внешний код, которому мы доверяем. Автоматическое сканирование (SCA) и SBOM - не опция, а необходимость.
Логирование и мониторинг - то, о чем все забывают. OWASP выделяет это в отдельную категорию не случайно. Среднее время обнаружения взлома - более 200 дней. Приложение без нормального мониторинга - приложение с незакрытым парадным входом.
Практический чек-лист
Для бэкенда (общий)
- Параметризованные запросы или ORM везде, где есть пользовательский ввод
- Авторизация проверяется на сервере, а не на клиенте
- ID пользователя берется из токена, а не из тела запроса
- Rate limiting на критичных эндпоинтах (логин, восстановление пароля)
- Логирование событий безопасности с алертами
- Регулярный аудит зависимостей (npm audit, pip-audit, dependabot)
Для веб-фронтенда
- CSP без 'unsafe-inline' для скриптов
- SameSite=Strict для авторизационных кук
- HttpOnly + Secure флаги
- CSRF-токены на формах изменения состояния
- HSTS с includeSubDomains
- Никакого innerHTML с пользовательскими данными
Для мобилки
- Токены - только в Keystore/Keychain, не в SharedPreferences/UserDefaults
- Certificate pinning с backup-пином и сроком обновления в календаре
- R8/ProGuard на релизных сборках
- FLAG_SECURE на экранах с чувствительными данными (защита от скриншотов)
- Никаких секретов в коде - даже обфусцированных
- Проверка на root/jailbreak - как доп. слой, не основной
Что почитать и поизучать дальше
- OWASP Web Security Testing Guide (WSTG) - исчерпывающее руководство по тестированию веба, бесплатно
- OWASP Mobile Application Security (MAS) - MASVS (стандарт) + MASTG (гайд по тестированию) + MAS Checklist
- OWASP MobSF - автоматический статический и динамический анализ мобильных приложений
- CWE/SANS Top 25 - список самых опасных классов уязвимостей независимо от платформы
- iOS Security Guide от Apple - официальная документация по механизмам безопасности iOS
- Android Security Guidelines от Google - официальные рекомендации для Android-разработчиков
- PortSwigger Web Security Academy - бесплатные практические лабораторные по веб-уязвимостям
Авторы статьи:
- Илья Новиков, технический директор @inova99
- Данил Мануйлов, Максим Быков, Линар Огай, Максим Савченко, тимлиды
- Тимофей Ищенко, техлид Frontend-разработки (направление web) @Is_Tim
- Даниил Николаев, Frontend-разработчик (направление web)
Если статья вам откликнулась - поделитесь в комментариях, какие неочевидные находки были у вас на пентестах и аудитах. Самое интересное в безопасности - именно нестандартные кейсы, которых нет в OWASP.-Источник
|
