Типичные ошибки безопасности в разработке ПО — и как с ними справиться

Михаил Курзин

---

Head of Security в ManyChat Armenia. Любит спорт — в частности, баскетбол и горный трекинг.

---

Ссылки

Типичные ошибки безопасности в разработке ПО со временем меняются. Организация OWASP, которая существует с 2001 года, отслеживает тренды и актуальные ошибки в разработке сайтов и приложений, в том числе мобильных. Раз в несколько лет она проводит исследование и публикует материалы с новыми актуальными ошибками. Последнее обновление OWASP Top 10 было в 2021 году.

Сейчас в топе такие угрозы безопасности:

• неправильная реализация систем аутентификации и авторизации;
• ошибки конфигурации компонентов приложения;
• атаки server-side request forgery, когда через внешний сервер идёт атака на внутреннюю инфраструктуру.

Эти ошибки и подробные рекомендации по их устранению публикуются в комьюнити OWASP.

Что нужно, чтобы защититься от атаки

Хакеры, как и все люди, движутся по пути наименьшего сопротивления. Если они видят незакрытую админку с паролем сотрудника из последней утечки какого-нибудь онлайн-сервиса, они этим воспользуются, ведь многие сотрудники переиспользуют пароли. А такой взлом гораздо проще, чем поиск сложных уязвимостей в ходе многомесячных исследований кода.

Чтобы отразить базовую, ненаправленную атаку, когда злоумышленник не владеет большим количеством ресурсов для нападения на вашу компанию, зачастую будет достаточно соблюдения элементарных правил кибергигиены:

• использовать VPN для доступа к критичным сервисам;
• использовать агенты EDR на рабочих станциях и серверах;
• установить антивирусы и средства защиты на компьютерах;
• использовать антиспам-системы, которые помогают фильтровать фишинговые письма;
• настроить MFA (multi-factor authentication) для доступа к критичным системам и админкам;
• своевременно устанавливать патчи для разных элементов системы — ОС, приложений, серверного ПО;
• сканировать системы на известные уязвимости;
• обновлять сторонние опенсорс-библиотеки, когда для них появляются исправления уязвимостей.

Многие корпорации тратят миллионы долларов на безопасность, но при этом не выполняют простых правил кибергигиены. Об этом свидетельствуют последние инциденты — например, в Microsoft в 2019 году ошибка в конфигурации сервера без пароля привела к утечке огромного количества данных из облачной системы.

Когда компании забывают обучать сотрудников правилам безопасности, самый простой и дешёвый путь вторжения — фишинговая атака. Провести её можно за 30 минут: создаётся форма, которая напоминает личный кабинет, и быстро рассылаются письма со ссылкой на неё. А дальше — чем больше компания, тем выше вероятность, что кто-то из пользователей введёт в эту форму свой логин и пароль.

Почему инфраструктурным инженерам важно дружить с безопасниками (и наоборот)

IT-инфраструктура — основа всего технического стека, поэтому отдел безопасности очень плотно взаимодействует с подразделением, которое занимается инфраструктурой.

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

Kubernetes, операционные системы, сетевое оборудование, облачные провайдеры — сейчас во все компоненты IT-инфраструктуры заложено огромное количество встроенных механизмов безопасности, и чаще всего это довольно сложные сущности — гораздо сложнее кнопок «Вкл» и «Выкл». Так что в них тоже нужно серьёзно вникать, разбираться, как они работают, — чтобы понимать пользу и негативные последствия включения каждого механизма.

Например, если сайт поддерживает старый протокол TLS 1.0, мы можем довольно легко его отключить, но нужно понимать, что для какого-то процента клиентов со старыми операционными системами наш сайт перестанет работать.

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

Так что и в большой, и в маленькой инфраструктуре IT-специалист должен дружить с безопасностью. Хотя в большой компании могут быть тысячи серверов, а в компании поменьше — десятки, но и там и там будут ресурсы, которые нужно защищать.

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

Подход к безопасности в корпорациях и небольших IT-компаниях

Я работаю в ManyChat — это относительно небольшая международная компания. До ManyChat я работал в корпорации с 70 тысячами сотрудников и поэтому хорошо понимаю разницу в подходах к безопасности.

У SaaS-компаний чёткий фокус на облачные решения, внутреннюю инфраструктуру и бизнес-системы. Есть множество облачных средств защиты, которые довольно быстро внедряются. Иногда они даже эффективнее и безопаснее внутренних, потому что ими пользуется большее число клиентов. Также в SaaS-компаниях сильнее упор на безопасную разработку и анализ кода.

В больших организациях все системы стараются сделать внутренними, в крайнем случае используют CRED-облака. У такого подхода своя специфика в части выстраивания систем защиты. Часто они и вовсе отдают R&D-отделы либо в дочерние организации, либо на аутсорс. Сейчас этот тренд постепенно уходит, но тем не менее часто разработку не рассматривают как основную деятельность.

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

И в маленькой компании вклад безопасников может быть куда серьёзнее. Например, когда «Фейсбук»* покупал WhatsApp, в том было всего 50 сотрудников и несколько сотен серверов, но они обслуживали миллионы клиентов. Если мы делаем антифрод-систему, то она и в большой, и в небольшой компании может защищать миллионы клиентов — в зависимости от специфики.

Проблемы безопасности Open Source — и как их избегать

Сейчас без опенсорса не развивается практически ни один продукт. Он используется всюду: и в критичных, и в коммерческих системах — в том же Chrome куча свободных библиотек и различных внешних компонентов. А ведь все эти библиотеки взаимосвязаны и могут иметь уязвимости.

И на самом деле, с безопасностью открытых библиотек постоянно возникают проблемы. Есть даже регулярно обновляемые списки «опасных» библиотек — их публикуют вендоры, которые занимаются безопасностью опенсорсных либ. Воздействия, скрытые в таких библиотеках, делятся на два вида:

• Лозунги. Например, вывести сообщение всем пользователям поверх всех окон.
• Вредительство. Например, удалить данные, когда библиотека видит, что её скачивают с определённых IP-адресов.

Чтобы внести изменения в опенсорсный продукт, достаточно закоммитить несколько строчек кода. Отследить их гораздо сложнее, потому что опенсорса в зависимостях почти у каждого IT-решения сейчас очень много. Например, React подключает много различных внешних библиотек, как, впрочем, и другие фреймворки.

Автоматические инструменты помогают выявить проблемные библиотеки, но они работают, как правило, уже постфактум. То есть должен пострадать хотя бы один клиент — а когда он зарепортит проблему, сервисы обновят свои базы, выкатят эти обновления на остальных клиентов и будут предотвращать возникновение проблемы или предупреждать, что не стоит обновляться до последней версии той или иной библиотеки из-за определённой угрозы.

У компаний, которые занимаются безопасностью опенсорсных библиотек, большая клиентская база, и они реально помогают бизнесу, уведомляя подписчиков о рисках. Именно поэтому многие компании сейчас не торопятся обновлять библиотеки. Они ждут некоторое время — неделю или две, чтобы убедиться, что это безопасно.

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

Использовать опенсорсное ПО относительно безопасно, главное — использовать его правильно. Считается, что иногда оно даже более безопасно, чем проприетарное, потому что открыто для всех, а значит, любой человек может найти в нём уязвимость. Проприетарное ПО разрабатывает конкретная компания, поэтому непонятно, насколько качественно проверяются уязвимости.

Плохой практикой также считается security by obscurity, когда безопасность достигается за счёт того, что информация о том, как реализована система безопасности, не предоставляется.

Если мы используем операционную систему, но не имеем доступа к исходному коду, то не знаем, как в ней реализованы механизмы безопасности. В этом плане опенсорс лучше. Но нужно соблюдать правила безопасности:

• не обновляться сразу до последней версии;
• не делать автообновлений;
• использовать инструменты software composition analysis — типа Snyk, Black Duck и других.

* Решением суда запрещена «деятельность компании Meta Platforms Inc. по реализации продуктов — социальных сетей Facebook и Instagram на территории Российской Федерации по основаниям осуществления экстремистской деятельности».