11 ошибок новичка, которые могут привести к дырам в кибербезопасности

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

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

Ведущий специалист по тестированию компании BI.ZONE Андрей Колесников разобрал 11 распространенных ошибок, которые могут сделать ваше приложение уязвимым. По большей части эти ошибки влекут за собой кражу денег или данных, удаленное выполнение кода, отказ в обслуживании или повышение привилегий.

В статье рассмотрено, как тот или иной недочет приводит к дырам в безопасности, а также предложены варианты решения.

Андрей Колесников

ведущий специалист по тестированию компании BI.ZONE

1. Отсутствие экранирования, неправильное форматирование, а также некорректное использование форматной строки и параметров у printf-функции

Проблема. Данные, попадающие в приложение из внешнего источника, недостаточно валидируются и фильтруются, в результате чего нарушается логика работы приложения.

Угроза. Такие ошибки связаны с целым рядом уязвимостей и атак: SQL Injection, NoSQL Injection, XXE, XSS, уязвимость форматной строки и прочими. Последствием наличия таких недостатков может стать возможность компрометации системы организации.

Решение. Фильтруйте и валидируйте все данные, поступающие из внешних недоверенных источников, а также используйте встроенные средства языков программирования, спроектированные специально для устранения таких проблем (например, Prepared Statements в случае с SQL).

2. Некорректная работа с конфиденциальными данными

Проблема. Чувствительные данные, например, номера банковских карт, пароли или персональная информация, выводятся в журналы или передаются третьей стороне в открытом виде.

Угроза. Из-за недостаточно бережного отношения к конфиденциальным данным они могут стать доступны третьей стороне.

Решение. Отслеживайте цепочку работы с конфиденциальными данными: как они хранятся, обрабатываются, передаются и на каком из этих этапов может что-то пойти не так. В случае журналирования или передачи третьей стороне — применяйте маскирование: +7 (999) 888-77-66 -> +7 (999)***-**-66 и т.п.

3. Десериализация ненадежных данных

Проблема. Приложение десериализует данные из недоверенного источника без достаточной их валидации. Такая уязвимость имеет идентификатор CWE-502 и находится на восьмом месте в рейтинге критических рисков веб-приложений OWASP Top Ten.

Угроза. В результате атаки на механизмы десериализации злоумышленник нередко получает возможность удаленно исполнять команды в скомпрометированной системе.

Решение. По возможности используйте простые форматы (например, JSON) для передачи данных и для их сохранения на диск или в базу данных. Кроме того, ведите белый список допустимых классов и подписывайте передаваемые сериализованные данные.

4. Хранение аутентификационных данных в исходном коде

Проблема. Пароли, ключи, токены хранятся в исходном коде или репозитории исходного кода.

Угроза. Информация из кода может попасть к третьим лицам. Если там хранятся аутентификационные данные, злоумышленник легко получит доступ к системе или ее компонентам.

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

5. Использование непроверенного чужого кода

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

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

Решение. Не рискуйте без необходимости: обязательно проверяйте чужой код, а лучше всегда обращайтесь к уже зарекомендовавшим себя библиотекам, например GSON, Apache Commons, Bouncy Castle и так далее.

6. Использование устаревших версий библиотек и софта

Проблема. Устаревшие версии библиотек и ПО содержат уязвимости, информация о которых есть в открытом доступе.

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

Решение. Регулярно обновляйте версии библиотек и ПО, которые используете. Также указывайте в конфигурационных файлах конкретные версии библиотек: в будущем это поможет избежать проблем с совместимостью.

7. Неграмотное использование криптографии

Проблема. Принципы криптографии весьма неочевидны и в попытке изобрести лучшее решение неопытные разработчики используют свои «костыли» вместо проверенных средств.

Угроза. С непроверенными алгоритмами криптографическая стойкость снижается: уязвимости могут появиться где угодно. Выстроенная защита не работает и злоумышленникам легко ее обойти.

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

8. Использование паролей по умолчанию или полное отсутствие аутентификации

Проблема. В конфигурациях различных сервисов и программных продуктов (базы данных, CMS и т. д.) остаются настройки, заданные по умолчанию.

Угроза. Слабые пароли или отсутствие аутентификации — прямой путь для доступа злоумышленника к системе и ее компонентам.

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

9. Игнорирование официальной документации

Проблема. В процессе разработки продукта не учтены рекомендации и практики из официальной документации.

Угроза. Если не задать объектам определенные свойства, качество кода в целом снизится и могут возникнуть уязвимости.

Решение. Все объекты, с которыми вы работаете, требуют бережного отношения и скрупулезно заданных свойств. Официальная документация — отличный помощник в этом: в ней содержится огромное количество практических советов. Мы регулярно сталкиваемся с ситуациями, когда подход Secure by default совершенно не работает даже в очень популярных open-source-решениях. В таких случаях единственный способ безопасно использовать компонент — внимательно изучать документацию и возможные настройки.

10. Проверки на стороне клиента

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

Угроза. В серверную часть приложения могут попасть непровалидированные данные, что нередко приводит к уязвимостям (см. п. 1) или нарушениям бизнес-логики.

Решение. Выполняйте все проверки на стороне сервера приложения. Проверки на стороне клиента — это не мера безопасности, а улучшение пользовательского опыта.

11. Недостаточные журналирование и мониторинг

Проблема. В системе реализовано недостаточное количество методов журналирования и мониторинга происходящих событий и параметров.

Угроза. Когда в системе остаются слепые пятна, есть опасность пропустить происходящие в ней аномалии и не заметить атаку злоумышленника.

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

Ошибки совершают все. Но опытных разработчиков от начинающих отличает умение предвидеть хотя бы некоторые из них. Думать о безопасности, а значит, думать стратегически — это признак профессионала. К такому подходу и стоит стремиться в разработке.