5 упущений программистов в системах безопасности

1. Вы доверяете старому или непроверенному чужому коду

Если вы зарабатываете программированием, то вы редко – если вообще хотя бы раз – разрабатывали продукт с нуля. Чаще всего вы формируете приложение, составляя его из фрагментов проприетарного кода, который создан вами или вашими коллегами с использованием опен-сорсных или чужих коммерческих источников или программного обеспечения, которому вы доверяете в вопросах создания важных фрагментов исходного кода. Такой исходный код может описывать все от элементов графического интерфейса до алгоритмов авторизации и шифрования (вспомним об OpenSSL).

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

Что же делать, чтобы минимизировать количество уязвимостей? Переписывание кода с нуля, очевидно, выходом не является. Но и держать скрещенными пальцы и надеяться на лучшее тоже не стоит. А потому советуем вам обратиться к руководствам по проверке third-party кода на надежность. Например, Trustworthy Software Initiative или Appropriate Software Security Control Types for Third Party Service and Product Providers.

2. Вы оставляете для себя запасные пароли и бэкдор аккаунты

Да, да, мы знаем. Вы оставляете их для тестирования, а потом забываете избавиться от них. А может быть, вам сверху пришло решение оставить этот бэкдор. В любом случае, вот вам вопрос на засыпку: кто сможет получить доступ к этому административному аккаунту? Ответ очевиден: возможно, никто – а возможно… злоумышленники. Считаете ли вы, что только дураки ловятся на наличии запасных аккаунтов или что все ловятся на этом – вы не ошибетесь.

В частности, ранее компания Cisco подтвердила наличие в некоторых роутерах ее производства недокументированных бэкдор аккаунтов, через которые можно было получить root доступ к оборудованию. Что самое неприятное, существуют случаи, когда разработчики не признают необходимости избавиться от запасных административных аккаунтов: в частности, такая ситуация имела место в 2012 году, когда организация Project Basecamp добровольно провела аудит некоторых прошивок таких устройств, как программируемые логические контроллеры, а компании, в чьих продуктах была найдена подобная уязвимость, представили их как элемент, упрощающий использование их ПО. Вот такая вот фича. А кто знает, кому в голову придет этой фичей воспользоваться и в каких целях?

3. Вы не проверяете пользовательский ввод

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

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

4. Вы не защищаете обрабатываемые данные

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

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

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

5. У вашего приложения есть пользователи

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

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

Однако и в этом случае нельзя быть уверенным в сознательности пользователя. Самый лучший и универсальный способ – это снижения количества данных аккаунту прав. В этом случае злоумышленник, очевидно, просто физически не сможет серьезно навредить системе.