Безопасность приложений

Почти все время я участвую в разработке крупных мобильных и веб-приложений и бэкенда под них.

Сегодня хочу рассказать немного про безопасность.

Это не обзорная статья всех уязвимостей, а примеры кейсов, с которыми я часто сталкиваюсь. Некоторые детали будут опущены по понятным причинам, но суть, я думаю, будет ясна.

Приложение – это не только код, на котором оно написано. Сервера, операционные системы, микросервисы, бд и так далее – все это и есть вместе приложение.

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

Костыли – это всегда потенциальная уязвимость.

Что такое костыль в приложении?

Одно из проявлений – это какая-то часть бизнес-логики или даже вся бизнес-логика. В этот момент нарушается принцип инкапсуляции, и вы открываете часть бизнес-процесса в коде злоумышленникам. Часто, например, так фильтры выносят на фронт для скорости реализации проекта. В фильтрах используются различные статусы объектов, их состояния и содержание. Изучив условия этих фильтров, можно понять, что ожидают на бэке, тем самым получив почву для компрометации. Максимально инкапсулируйте бизнес-логику за пределами клиентской части.

Код никогда не безопасен. Даже если вы каждый релиз проводите сканирование безопасности. Это нужно делать всегда, хотя бы потому, что ни одна команда разработки не гарантирует полностью безопасный код. Однако, во-первых, все сканеры – это машины, которые постоянно нужно обучать, во-вторых, ваш код доступен многочисленным сотрудникам, и, при всем уважении, среди них могут оказаться недобросовестные люди или те, кто просто по глупости вынесет часть кода в интернет.

Мобильные и веб-приложения работают с «ручками», которые открыты в интернет. Это очень важный момент, даже если они спрятаны за каким-то WAF и сервисами аутентификации и авторизации. Это не гарантия. Нужно постоянно думать о внедрении умных прокси защиты и об отдельных защищенных контурах. Думать и внедрять.

DRP (Disaster-Recovery-Plan) – это также один из ключевых методов грамотной защиты и обеспечения надежности ваших приложений. План необходимо минимум 2 раза в год обновлять и проводить реальное тестирование. Порой при аварийном отключении какой-то системы можно получить доступ к закрытым данным через приложения. Самый простой пример, который можно привести и часто встретить при серфинге в интернете – это сайты, разработанные на какой-нибудь дешевой CMS. Обычно, когда там случается проблема с бд, ошибки с запросами вардампятся прямо на главную страницу, и там частенько можно увидеть не только сами запросы и составить структуру бд, но и хосты и порты, по которым разорван коннект.

Мой канал - https://t.me/carbonka

(Продолжение в следующем посте)