Самая важная часть моей работы как рецензента кода — помогать другим разработчикам обеспечивать безопасность их систем. Это то, к чему я не отношусь легкомысленно, и есть много причин, по которым приложение может не пройти проверку с точки зрения безопасности. Вот то, что я нахожу чаще всего — надеюсь, здесь будет несколько вещей, которые бросятся вам в глаза, когда вы в следующий раз увидите их в PR.
ПРИМЕЧАНИЕ. Следующие примеры кода были созданы для подробного иллюстративного представления реальных проблем безопасности, которые я обнаружил при просмотре кода. Они не были извлечены из реальных кодовых баз или коммитов. Они написаны на Python и Ruby, но их концепции широко применяются.
Contents
1. Конфиденциальная информация в лог-файлах
Информация, позволяющая установить личность (PII), регулируется несколькими различными законами: GDPR в Европе и CCPA в Калифорнии являются двумя наиболее актуальными примерами на момент публикации, хотя в ближайшие несколько лет по этой теме появится больше законов. Эти законы регулируют способы, которыми компании могут хранить и использовать личную информацию, такую как имена, физические адреса, адреса электронной почты, идентификационные номера и тому подобное. Как правило, это законодательство требует, чтобы такая информация хранилась в безопасном месте. Ведение журнала является одним из крупнейших нарушителей этого требования. Возьмем следующий пример:
Это якобы разумно и безопасно, но на самом деле это утечка адресов электронной почты пользователей в файлы журналов. Что делает регистрацию этой информации проблемой безопасности? Системы ведения журналов, как правило, не имеют такой же защиты, как базы данных. Злоумышленники это знают и могут этим воспользоваться. Адрес электронной почты в приведенном выше коде следует заменить запутанным или зашифрованным идентификационным номером пользователя.
Секреты также могут попасть в лог-файлы. Как следует из названия, «секретные» ключи — это учетные данные, которые не следует раскрывать, в то время как некоторые ключи API безопасны для раскрытия. Я обнаружил, что многие из главных нарушителей — это драйверы баз данных, которые распечатывают всю строку подключения при сбое подключения. Как правило, попытки подключения для некоторых из этих, к сожалению, ошибочных драйверов должны быть заключены в обработчик исключений, который проглатывает ошибку, а не печатает ее в журналах. Меньшие нарушения включают ведение журнала, добавленное программистами для целей отладки, которое затем проникает в запрос на вытягивание или код ведения журнала, предназначенный для среды разработки, для которой задан неправильный уровень журнала.
2. Плохой выбор криптографии
Обычно это касается систем, в которых используется одноразовый ключ или другой токен. Я видел времена, когда люди пытались найти легкий путь, выполняя кодировку Base64 временной метки (очень угадываемую и вовсе не псевдослучайную) или выбирая хэш с высокой степенью коллизии для уникального ключа (например, md5) без уникальное ограничение на таблицу. Другие сбои включают использование алгоритмов шифрования, которые, как известно, недостаточно сложны для обеспечения безопасности.
3. Недостаточный контроль доступа
Также известен как Broken Access Control от OWASP. В 2021 году Broken Access Control переместился на первое место в списке OWASP Top 10 самых критических угроз безопасности веб-приложений.
Broken Access Control поднимается с пятой позиции в категорию с самой серьезной угрозой безопасности веб-приложений; предоставленные данные показывают, что в среднем 3,81% протестированных приложений имели одно или несколько общих перечислений слабых мест (CWE) с более чем 318 тыс. случаев CWE в этой категории риска. 34 CWE, сопоставленные с Broken Access Control, чаще встречаются в приложениях, чем в любой другой категории.
Наиболее распространенный пример этого связан с безопасностью на уровне строк, когда пользователь может получить доступ к подмножеству информации в таблице. Легко забыть добавить фильтр к запросу или проверку к конечной точке, и может быть сложно увидеть ошибку в пользовательском интерфейсе программы, если фильтрация происходит надлежащим образом в другом месте кода. Это легче всего обнаружить, проверив, что фильтры запросов для действий с индексами также присутствуют для всех других действий, которые работают с отдельными строками.
Другая распространенная ошибка управления доступом, которую я наблюдаю, — это отсутствие проверки сеанса на конечных точках — когда, скажем, для каждой конечной точки требуется декоратор Python для проверки сеанса, его легко отключить. Лучшая стратегия здесь — по умолчанию закрыть все, а затем использовать декораторы, чтобы вместо этого открыть доступ.
Подробнее об этом здесь .
4. Незащищенные кеши
По мере того, как одностраничные приложения становятся все более сложными и распространенными, я наблюдаю все больше и больше паттернов: уровни кеша открыты для внешнего интерфейса, где любой член кеша доступен для загрузки, если вы знаете ключ кеша. Это может привести к утечке конфиденциальной информации между сеансами и может привести к эскалации атак на привилегии, особенно если сеанс используется для хранения ключей доступа. При реализации внешнего доступа к кешу важно предоставить систему для ограничения доступа к кешу только теми элементами, которые написаны текущим пользователем, или, если это общий кеш, гарантирующий, что записи проверяются на стороне сервера, чтобы избежать атак с внедрением на основе плохих данных. поведение со стороны пользователей.
5. Слишком доверять клиенту
Если вы новичок в разработке, вы можете думать о клиенте как о «внешнем интерфейсе», с которым взаимодействуют пользователи, а о «бэкэнде» — как о системах, обеспечивающих работу внешнего интерфейса.
Один из первых уроков безопасности, который я преподал, заключался в том, чтобы никогда не доверять вводу данных на стороне клиента; всегда проверяйте, что клиент делает то, что мы от него ожидаем. Я вижу все больше и больше примеров меньшего количества элементов управления на стороне сервера и большей зависимости от внешнего интерфейса JavaScript для обеспечения проверки данных и контроля над пользовательским потоком.
Например, скажем, в приложении есть функция, с помощью которой пользователи могут загружать изображения. У внешнего клиента может быть проверка, чтобы убедиться, что выбранный файл отформатирован так, чтобы он содержал ожидаемый тип файла (например, имя файла заканчивается на «.png», «.jpg»), но эту проверку можно легко обойти с помощью Злоумышленник ищет способы вставить исполняемый файл в систему. Слишком большое доверие к клиенту для этой проверки открывает брешь в безопасности и возможность для злоумышленника сделать это. Серверная часть приложения также должна выполнять проверку правильности и ожидаемого типа файла.
Хотя у меня нет доказательств этого, кроме личного опыта, PullRequest предоставляет инженерам в сети рецензентов, таким как я, уникальную линзу и точку зрения на рецензирование кода для множества инженерных команд. И из того, что я наблюдал, это видимая и растущая тенденция.
Я считаю, что рост такого поведения является результатом, по крайней мере частично, растущей специализации в отрасли — веб-разработка становится все более фрагментированной на специалистов по внешнему и внутреннему обслуживанию и требует более тесного сотрудничества между двумя группами для создания функциональных возможностей. программного обеспечения. Когда это сотрудничество идет не очень хорошо, может возникнуть тенденция переноса внутренних проблем на внешний интерфейс, что может создать уязвимости в системе безопасности.
Вывод
Эти пять проблем безопасности особенно важно выявить при проверке кода запросов на вытягивание, поскольку они, как правило, очень маловероятны для контроля качества. Они могут быть обнаружены в обычном тесте на проникновение (или тесте на проникновение), если ваша организация участвует в них, но тестирование на проникновение обычно проводится с более длительными интервалами, в то время как проверка кода запроса на вытягивание является очень регулярной, постоянной и активной — тестирование на проникновение обычно раскрывает проблемы безопасности, которые уже существуют. Короче говоря, намного безопаснее выявить проблемы безопасности при проверке кода до вас, иначе злоумышленник обнаружит их в рабочей среде.
Если бы у меня был только один совет, который я мог бы передать каждому программисту, он заключался бы в том, чтобы проверять каждую вещь, которую вы записываете в журналы, на наличие PII и секретов, а также каждую ошибку, которую вы выдаете, на то же самое. Это самая распространенная повторяющаяся проблема, с которой я сталкиваюсь снова и снова.
Этот пост изначально был опубликован на сайте PullRequest . 28 апреля 2022 года HackerOne приобрела PullRequest , чтобы помочь разработать решения для тестирования безопасности, ориентированные на разработчиков.
Найдите автора сообщения Уилла Барретта здесь .
Статья является переводом hackerone.com
