Как-то тихо и незаметно для меня релизнулась новая редакция OWASP для мобилок. После ознакомления с новой редакцией появилось несколько мыслей, которыми хотел поделиться. Ну и в целом попытался простыми словами передать суть пунктов чтобы инфобез-неофитам и разработчикам было проще понять суть происходящего.
M1: Improper Credential Usage
Хардкод ключей и прочих кредов для доступа к серверной инфраструктуре (более вероятно) или внутренностям приложения (менее вероятно). Сюда же относится неправильное использование этих данных и их передача небезопасным способом. Довольно странно, что эта штука вылезла на первое место. Видимо в индустрии мобильной разработки наблюдается кризис, и туда понабрали кого попало. А может сама индустрия слишком сильно усложнилась и разработчики уже не вывозят читать доки чтобы понимать какие ключи можно хардкодить, а какие не стоит.
M2: Inadequate Supply Chain Security
Популярная нынче история про внедрение вредоносного кода во всякие опенсорсы и прочие атаки на цепочку поставок. В целом, это довольно валидная история, и чем больше у приложения различных зависимостей (в том числе транзитивных), тем более оно подвержено этой проблеме. При этом вред может быть нанесен не всегда мобильному приложению напрямую. Достаточно вставить магическую строчку в build.gradle, которая будет вызвана при сборке на машине разработчика. И вот злоумышленники уже в инфраструктуре компании.
M3: Insecure Authentication/Authorization
В отличие от двух предыдущих — это уже довольно известный пункт, и в основном он относится к клиент-серверным приложениям. Хотя его также можно натянуть на локальную аутентификацию по пин-коду например. Суть его в том, что либо самое мобильное приложение, либо API предназначенное для приложения дает пользователю/злоумышленнику больше возможностей чем API для web-версии. А это чревато IDOR-ами, злоупотреблением правами ролей и прочими приятными вещами вроде RCE через “секретный” метод загрузки файлов.
M4: Insufficient Input/Output Validation
Тоже новый пункт, которого кажется давно не хватало, из-за чего приходилось натягивать сову на глобус, а иногда и ужа на ежа. Суть его простая: отсутствие адекватных фильтров входных данных, что приводит сразу к вороху различных уязвимостей от XSS до RCE. При этом не всегда это проблема в логике приложения. В библиотеках, и даже самом android фреймворке хватает интересных мест, которые можно использовать для атак. Также сюда относится санитизация выходных данных и проверка целостности данных. Казалось бы, зачем валидировать выходные данные? Ну например вы не контролируете входной поток данных, а этим занимается внешняя библиотека. Что если найдется уязвимость, которая позволит подсунуть вам на вывод тот самый заветный <script>alert(1)</script>? Если такие вещи для вас критичны, то стоит контролировать данные уходящие на отрисовку. Хотя если цепляться к понятиям, то это все равно сводится к “контроль входных данных”. Потому что для вашего кода это input =) А вот целостность данных это уже из области бинарщины. Если часто десериализовать что попало и от кого попало, то можно обнаружить что-нибудь необычное в необычном для себя месте. Думойте ;)
M5: Insecure Communication
Наш любимый SSL пиннинг и все что связано с хождением в сеть по HTTP вместо HTTPS. 5-я позиция этого пункта как бы намекает что половина разработчиков все еще занимается этим. И я бы не поверил. Но буквально на днях, в одном популярном приложении нашел общение с сервером по HTTP. А там летали очень конфиденциальные данные. Скажем так, подмена этих данных могла бы навредить пользователю в физическом мире.
M6: Inadequate Privacy Controls
Еще один свежий пункт, который вполне себе в духе эпохи утечек и всеобщей истерии вокруг персданных. Постулирует, что нельзя писать ПД в логи, передавать в URL и бэкапить. Звучит довольно разумно. Жаль только что вендоры так неохотно принимают подобные уязвимости, особенно если они не носят массовый характер. Ведь это просто угнали какие-то ПД какого-то пользователя в мобильном приложении, а не слили базу с сервера. Импакт низкий. Можно не обращать внимания. А на чувства одинокого Васи, чьи данные утекли, конечно же вендору накласть.
M7: Insufficient Binary Protections
Более адекватный взгляд на проблему, которая раньше была в двух разных пунктах: Code Tampering и Reverse Engineering. Суть этих пунктов всегда вызывала вопросы, и мне кажется никто до конца не понимал что они значат и зачем нужны. Это порождало кучу прочтений и фантазий. А фантазии в вопросах инфобеза скорее вредны чем полезны. Тут все должно быть квадратным. И кровати и сугробы =) Теперь есть вот этот пункт, который говорит, что если приходится поставлять вместе с приложением какие-то секреты или, например, AI-модели, то все это неплохо бы как-то защищать. А вот как защищать это уже отдельный вопрос. И каждая компания отвечает на него самостоятельно исходя из своих ресурсов.
M8: Security Misconfiguration
Долгожданное переосознание очень мутного пункта про Extraneous Functionality. Теперь должно быть меньше фантазий и разночтений на тему что же это черт возьми такое. Теперь сюда вполне себе ложатся вызовы разных методов с небезопасными параметрами по умолчанию, торчащие наружу content provider-ы и другие компоненты приложения, а также ненужные разрешения, которые могут быть использованы кем-то в цепочке атаки.
M9: Insecure Data Storage
Старое-доброе небезопасное хранение данных, которое уехало со второй позиции на девятую. Интересно, как они это посчитали? Я регулярно встречаю небезопасное хранение данных. И это при том, что сделать его безопасным можно вообще бесплатно 5-ю строчками кода. Ну да ладно. Напомню, что относится к этому пункту: хранение любой конфиденциальной инфы без шифрования, кэширование и логирование всего подряд без разделения на конфиденциальные и обычные данные, самопальное крафтовое создание временных файлов, которые не удаляются автоматически.
M10: Insufficient Cryptography
А вот это прямо сюрприз-сюрприз. Небезопасная криптография переехала с пятого пункта на десятый. При том, что этот пункт по сути является базисом для предыдущего. Т.е. получается, что неправильного использования криптографии почти нет, но данные все же почему-то хранят небезопасно. Загадка века! Тут все осталось как и было: старые алгоритмы, слабые ключи и мамкины изобретатели криптоалгоритмов.