С начала 2022 года я проводил аудит безопасности и тесты на проникновение для приложений Laravel. Я проверял приложения всех размеров, от крошечных приложений с несколькими контроллерами до огромных приложений с множеством модулей и множеством различных стилей кодирования и структур приложений.
Среди всего этого наблюдается довольно четкая тенденция, которая справедлива и для приложений, которые я проверял: Laravel довольно безопасен, но легко упустить из виду мелочи, дополнительные уровни защиты и где-то спрятать слабость.
На самом деле, справедливо сказать, что подавляющее большинство проблем, которые я обнаружил во время своих аудитов, были либо чем-то простым, что было упущено из виду в одном маршруте, либо являются дополнительными уровнями безопасности, о которых разработчики либо не знали, либо неудобно внедрять.
Итак, давайте углубимся в это и проверим 10 наиболее распространенных проблем безопасности, которые я обнаружил во время аудита безопасности.
# 10 → Недостаточная проверка
входных данных Часто можно встретить недостаточную проверку входных данных, разбросанных по всем контроллерам. Часто валидатор проверяет ожидаемые ключи ввода (хотя иногда даже этого нет), а затем request()->all() сразу после этого будет использоваться, отправляя данные в модели, события и т. Д. Без надлежащей проверки легко внедрить вредоносные значения, чтобы вызвать ошибки, атаки с внедрением и многое другое.
Например, обычная защита от массовых назначений для этого считается $fillable моделью, но если $fillable включает admin флаг для портала администрирования, то любой может создать нового пользователя-администратора со страницы регистрации... (И да, это реальный пример.)
# 9 → Отсутствует целостность подресурса (SRI)Целостность субресурса (SRI)
добавляет уровень защиты от скомпрометированных 3rd сторонних скриптов, влияющих на ваш сайт, и, на мой взгляд, серьезно недоиспользуется. Риск заключается в том, что 3rd сторонние скрипты и стили могут быть изменены для включения вредоносного кода, такого как Magecart, кейлоггеры, криптомайнеры и т. Д. Если скомпрометированный скрипт включен на ваш сайт, то ваши пользователи подвергаются риску, даже если ваше приложение не было скомпрометировано.
SRI работает, определяя хэш целостности для каждого <script> тега &<style>, который загружает 3-й сторонний ресурс, который браузер проверяет перед загрузкой ресурса. Если хэш не совпадает, ресурс блокируется.
Большинство сайтов, которые я проверял, не загружали ресурсы от 3-х сторон и, следовательно, в любом случае не нуждались в SRI, иначе я ожидал бы, что это будет намного выше в списке!
# 8 → Недостаточное ограничение скорости Ограничение скорости необходимо для ограничения атак ботов и предотвращения злоупотреблений, и все же часто можно найти конечные точки, в которых отсутствует ограничение
скорости. Это вызывает особую озабоченность, когда речь идет о маршрутах, таких как аутентификация, или запросе конфиденциальной информации, такой как существование учетных записей пользователей. Например, я обнаружил, что в маршруте многофакторной аутентификации (MFA) на основе SMS отсутствует ограничение скорости, и срок действия 6-значного кода истекает через 5 минут. Было тривиально подобрать действительный код и силой проникнуть внутрь. 😈
Тем не менее, ограничение скорости может быть сложным для правильного - вы основываете его на IP-адресе, или на имени пользователя, или на обоих? Или что-то другое? Это зависит от маршрута, но иметь их определенно лучше, чем ничего. Так что не упускайте это из виду!
#7 → Межсайтовый скриптинг (XSS)Одна
из самых неудивительных записей в Топ-10, но, вероятно, она намного ниже, чем вы ожидали! XSS обычно появлялся на одном маршруте через один ввод из-за чего-то вроде Markdown (который по умолчанию небезопасен) или ограниченного форматирования, которое страдало от тонкого обхода экранирования.
Лучшая стратегия здесь — обратить внимание на эти надоедливые неэкранированные теги blade ({!! … !!}) и необработанные директивы HTML, такие как v-html, и убедиться, что все виды использования правильно экранированы, что функции безопасности Markdown включены, а предоставленный пользователем HTML очищен. Я рекомендую избегать этих тегов, насколько это возможно, чтобы любое использование действительно выделялось и могло быть легко идентифицировано и просмотрено.
# 6 → Устаревшие и уязвимые зависимости Еще
одна неудивительная запись ... Когда вы в последний раз запускали обновление composer/npm?
Обычно обновления зависимостей откладываются, чтобы избежать поломок и поддерживать стабильность систем, но уязвимости в зависимостях могут оставить ваши приложения открытыми без каких-либо действий. Также часто включается множество зависимостей, но каждая зависимость увеличивает потенциальные уязвимости, о которых вам необходимо знать.
Я рекомендую обновлять все еженедельно или ежемесячно и использовать такие инструменты, как composer audit --locked и npm audit в вашей системе сборки, чтобы блокировать развертывание при обнаружении уязвимостей. Я также предлагаю сократить ваши зависимости до минимума, и все, что можно легко заменить простым внутренним промежуточным программным обеспечением или оболочкой, должно быть.
# 5 → Небезопасное использование
функций Я сбился со счета, сколько раз я видел md5(time()) (и md5(microtime())!) использовал с тех пор, как начал работать в PHP - я, вероятно, даже написал несколько из них в ранние годы! И, к сожалению, эта тенденция продолжается и по сей день. Хуже того, он часто используется для генерации случайных токенов или уникальных имен файлов. За исключением того, что он не является ни случайным, ни уникальным. Это невероятно легко угадать и грубой силой, и атаки столкновения также могут быть довольно тривиальными.
Бьюсь об заклад, если вы прямо сейчас зайдете в свою кодовую базу и выполните поиск, вы обнаружите, md5(что он где-то используется небезопасно... Серьезно, у меня травма из-за этого!
Дело не только md5(time()) в специально, но и в других функциях, таких как rand() и которые, которые не являются криптографически безопасными, и array_rand() им не следует доверять ни за что, что требует безопасности.
Всегда используйте правильные безопасные генераторы random_int() случайных чисел и Str::random(), чтобы безопасно генерировать случайные значения.
# 4 → Отсутствующие заголовки
безопасности Теперь мы переходим к дополнительным уровням защиты, которые не совсем понятны. Веб-браузеры включают в себя множество действительно потрясающих функций безопасности, вам просто нужно включить их на своем сайте с помощью заголовков ответов. Хотя их отсутствие напрямую не открывает ваш сайт для взлома, они помогают предотвратить такие вещи, как кликджекинг, утечка информации о реферере, XSS и другие инъекционные атаки, атаки с понижением версии HTTPS и т. д. Включение многих из этих заголовков безопасности тривиально, но большинство сайтов не включают даже простые... 😭
Лучшее предложение, которое я могу вам дать, - это зайти в securityheaders.com и отсканировать ваш сайт. В нем будут перечислены все отсутствующие заголовки и даны ссылки на ресурсы, чтобы узнать больше об их добавлении.
# 3 → Отсутствующая политика безопасности контента (CSP)
Политики безопасности контента настолько важны, что я дал им свое место в Топ-10. CSP являются вторичной линией защиты от XSS и кликджекинга и дают вам представление о том, какие скрипты, стили, шрифты, формы, фреймы и т. д. выполняются в вашем приложении. CSP сообщает браузеру, какие ресурсы разрешено использовать на сайте, и он будет блокировать и/или сообщать о любых нарушениях политики, предотвращая XSS-атаки и предоставляя вам видимость того, что происходит на вашем сайте.
Их часто отклоняют как слишком сложные или «ломающиеся», однако развертывание политики «Только отчет» обеспечивает полную видимость, ничего не нарушая. Так что это определенно путь, когда вы начинаете! Самый простой способ настроить его — использовать мастер CSP в URI отчета.
Я опубликовал свое промежуточное программное обеспечение CSP как простой способ начать работу с CSP: https://gist.github.com/valorin/d4cb9daa190fdee90603efaa8cbc5886
#2 → Отсутствует авторизация О боже, это включает в себя кучу вещей, связанных с авторизацией
(и в некотором роде аутентификацией). Я видел: небезопасные прямые ссылки на объекты (IDOR), отсутствующееsigned, auth и промежуточное программное обеспечение политики, забытые authorize() вызовы, веб-перехватчики без проверки и т. Д. В конечном счете, код на самом деле не проверял, разрешено ли запрашивающей стороне делать то, что он хотел.
На самом деле я был удивлен, увидев это так высоко в списке, но оказывается, что для большинства проектов довольно часто один из них где-то прячется, ожидая, чтобы его использовали. Обычно это простой случай, когда разработчик забывает добавить строку, но это потенциально оставляет огромную дыру.
Моя лучшая рекомендация — включить тесты для аутентификации и авторизации на каждом маршруте вместе с другими тестами. Таким образом, вы проверяете действительные и недействительные разрешения в рамках стандартного процесса тестирования и заметите, отсутствует ли авторизация, потому что тест пройдет, когда он должен завершиться неудачей.
# 1 → Раскрытые ключи API и пароли Сколько
раз я должен это повторять? Не вкладывайте секреты в Git! 😡
Это был неудивительно чемпион списка: ключи API и пароли зафиксированы в системе управления версиями и разбросаны по кодовым базам. Это настолько смехотворно распространено, что я, честно говоря, удивляюсь, когда не сталкиваюсь с этим во время аудита.
Подумайте, куда идет ваш код... Он находится на всех ваших машинах разработчиков, совместно используется с подрядчиками, на GitHub, Bitbucket, GitLab и т. Д. В сторонних сервисах и инструментах сборки. Он разбросан по разным местам. В то время как ваши ключи API разблокируют выставление счетов, хранение файлов, личную информацию, резервные копии, инфраструктуру и т. Д. Так много конфиденциальной информации и доступа, и если она попадет в чужие руки, ваша репутация исчезнет.
Я знаю, что есть учебники, которые рекомендуют фиксировать эти вещи, поэтому я могу понять, почему это происходит. Но это то, над чем нам нужно усердно работать, чтобы остановить это как сообщество.
Если вы случайно зафиксировали учетные данные, убедитесь, что вы отозвали их у источника. Это не позволит никому использовать его, если они его найдут. Я также предлагаю использовать такие инструменты, как Gitleaks и TruffleHog, чтобы найти секреты в ваших кодовых базах.
БОНУС → Отсутствует файл
безопасности.txt Это не проблема безопасности как таковая, поэтому я включил ее в качестве бонуса, но добавление security.txt файла в ваше приложение — одна из самых простых и лучших вещей, которые вы можете сделать для своей безопасности.
security.txt is a text file that you put at /.well-known/security.txt, which provides your (security) contact details in case someone finds a security issue with your site. This makes it super easy for security folks to contact you, reducing the time and effort it takes to report issues so you can get them fixed faster.
Сгенерируйте его здесь: https://securitytxt.org
Резюме
Хорошо, друзья мои, это мой топ-10! Были ли какие-то сюрпризы? Что вам нужно проверить в своих собственных приложениях? Может быть, вы с чем-то не согласны? Перейдите в ветку в Twitter, Fediverse или Substack Notes, чтобы присоединиться к обсуждению!
Ключевой вывод для меня заключается в том, что, хотя Laravel безопасен, это все мелочи, которые упускаются из виду и упускаются. Легко предположить, что вы проверили авторизацию на каждом маршруте, и ваши выходные данные полностью экранированы, но может быть один экземпляр, который вы пропустили. В этом и заключается преимущество аудита безопасности - привлечение кого-то, кто не делает предположений, к проверке вашего кода. Это также то, чему я учу в своем практическом курсе Laravel Security.
