Laravel довольно безопасен, но легко упустить из виду мелочи, дополнительные уровни защиты и оставить где-то скрытую слабость.
Давайте углубимся в это и рассмотрим 10 самых распространенных проблем безопасности, которые вы можете обнаружить во время аудита безопасности.
Недостаточная проверка ввода
Обычно недостаточная проверка ввода разбросана по контроллерам. Часто будет валидатор, проверяющий ожидаемые входные ключи (хотя иногда даже этого нет), а затем он request()->all() будет использоваться сразу после отправки данных в модели, события. Без надлежащей проверки легко внедрить вредоносные значения в вызывать ошибки, инъекционные атаки и многое другое.
Например, обычная защита от массового назначения для этого считается по $fillable образцу, но если $fillable включить admin флаг для портала администратора, то любой может создать нового пользователя-админа со страницы регистрации.
Отсутствует целостность подресурсов (SRI)
Subresource Integrity (SRI) добавляет уровень защиты от скомпрометированных сторонних скриптов, влияющих на ваш сайт, и, на мой взгляд, серьезно недооценивается. Риск заключается в том, что сторонние скрипты и стили могут быть изменены для включения вредоносного кода, такого как Magecart, кейлоггеры, криптомайнеры. Если на вашем сайте есть скомпрометированный скрипт, ваши пользователи подвергаются риску, даже если ваше приложение не было т скомпрометировано.
SRI работает, определяя хэш целостности для каждого тега <script> и <style>, загружающего сторонний ресурс, который браузер проверяет перед загрузкой ресурса. Если хэш не совпадает, ресурс блокируется.
Недостаточное ограничение скорости
Ограничение скорости необходимо для ограничения атак ботов и предотвращения злоупотреблений, и тем не менее часто можно найти конечные точки, на которых отсутствует ограничение скорости. Это особенно важно, когда речь идет о таких маршрутах, как аутентификация, или о запросах конфиденциальной информации, например о существовании учетных записей пользователей. Например, я обнаружил, что в маршруте многофакторной аутентификации (MFA) на основе SMS отсутствует ограничение скорости, а срок действия 6-значного кода истекает через 5 минут. Было тривиально взломать действующий код и взломать вход.
Тем не менее, ограничение скорости может быть сложной задачей - вы основываете его на IP, или имени пользователя, или на том и другом? Или что-то другое? Это зависит от маршрута, но иметь немного определенно лучше, чем ничего. Так что не упускайте из виду!
Межсайтовый скриптинг (XSS)
XSS обычно появлялся на одном маршруте через один вход из-за чего-то вроде Markdown (который по умолчанию небезопасен) или ограниченного форматирования, которое пострадало от тонкого обхода экранирования.
Лучшая стратегия здесь — высматривать эти надоедливые неэкранированные блейд-теги ( {!! … !!}) и необработанные директивы HTML, такие как v-html, и убедиться, что все варианты использования правильно экранированы, что функции безопасности Markdown включены, а пользовательский HTML очищен. Я рекомендую избегать этих тегов, насколько это возможно, чтобы любое использование действительно выделялось и могло быть легко идентифицировано и рассмотрено.
Устаревшие и уязвимые зависимости
Когда вы в последний раз запускали composer/npm update?
Обычно обновления зависимостей откладываются, чтобы избежать поломок и обеспечить стабильность систем, но уязвимости в зависимостях могут сделать ваши приложения незащищенными, и вы ничего не сделаете. Также принято включать множество зависимостей, но каждая зависимость увеличивает потенциальные уязвимости, о которых вам нужно знать.
Я рекомендую обновлять все еженедельно или ежемесячно и использовать такие инструменты, как composer audit --locked и npm audit в вашей системе сборки, чтобы блокировать развертывание при обнаружении уязвимостей. Я также предлагаю свести ваши зависимости к минимуму, и все, что можно легко заменить простым внутренним промежуточным ПО или оболочкой.
Небезопасное использование функций
Я уже сбился со счета, сколько раз я видел md5(time()) и md5(microtime()) И к сожалению, эта тенденция сохраняется и по сей день. Часто используется для генерации случайных токенов или уникальных имен файлов. За исключением того, что это не случайно и не уникально.
Это не только md5(time()) конкретно, но и другие функции, такие как rand() и array_rand() которые не являются криптографически безопасными, и им не следует доверять для всего, что требует безопасности.
Всегда используйте надлежащие безопасные генераторы случайных чисел random_int() и Str::random(), для безопасного создания случайных значений.
Отсутствующие заголовки безопасности
Теперь мы переходим к дополнительным уровням защиты, которые не совсем понятны. Веб-браузеры включают в себя множество действительно потрясающих функций безопасности, вам просто нужно включить их на своем сайте с помощью заголовков ответа. Хотя их отсутствие напрямую не открывает ваш сайт для взлома, они помогают предотвратить такие вещи, как кликджекинг, утечка информации о реферере, атаки XSS и другие инъекции, атаки с понижением версии HTTPS и т. д. Включение многих из этих заголовков безопасности тривиально, но большинство сайтов этого не делают.
Лучшее, что я могу вам посоветовать, это зайти на securityheaders.com и просканировать ваш сайт. В нем будут перечислены все заголовки, которых вам не хватает, и даны ссылки на ресурсы, чтобы узнать больше об их добавлении.
Отсутствует политика безопасности контента (CSP)
CSP — это второстепенная линия защиты от XSS и кликджекинга, и они дают вам представление о том, какие сценарии, стили, шрифты, формы, фреймы и т. д. выполняются в вашем приложении. CSP сообщает браузеру, какие ресурсы разрешено использовать на сайте, и он будет блокировать или сообщать о любых нарушениях политики, предотвращая XSS-атаки и обеспечивая вам видимость того, что происходит на вашем сайте.
Их часто считают слишком сложными или «ломающими», однако развертывание политики только для отчетов обеспечивает полную видимость, ничего не ломая. Самый простой способ настроить его — использовать мастер CSP в URI отчета.
Отсутствует авторизация
Это включает в себя кучу вещей, связанных с авторизацией (и в некотором роде аутентификацией). Я видел: небезопасные прямые ссылки на объекты (IDOR), отсутствующие signed, промежуточное ПО для аутентификации и политик, забытые authorize() вызовы, веб-перехватчики без проверки и т. д. В конечном счете, код на самом деле не проверял, разрешено ли запрашивающей стороне делать то, что он хотел делать.
На самом деле я был удивлен, увидев это так высоко в списке, но оказалось, что для большинства проектов довольно часто где-то прячется один из них, ожидающий использования. Обычно это простой случай, когда разработчик забывает добавить строку, но это потенциально оставляет огромную дыру.
Моя лучшая рекомендация здесь — включить тесты для аутентификации и авторизации на каждом маршруте, наряду с другими вашими тестами. Таким образом, вы проверяете действительные и недействительные разрешения в рамках стандартного потока тестирования и заметите, отсутствует ли авторизация, потому что тест будет пройден, когда он должен был провалиться.
Открытые ключи и пароли API
Ключи и пароли API, переданные в систему контроля версий и разбросанные по кодовым базам. Это настолько смехотворно распространено, что я искренне удивляюсь, когда не сталкиваюсь с этим во время аудита.
Подумайте, куда идет ваш код. Он находится на всех компьютерах ваших разработчиков, используется совместно с подрядчиками, на GitHub, Bitbucket, GitLab и т. д., в сторонних сервисах и инструментах сборки. Он разбросан по разным местам. В то время как ваши ключи API разблокируют биллинг, хранилище файлов, личную информацию, резервные копии, инфраструктуру. Так много частей конфиденциальной информации и доступа, и если она попадет в чужие руки, ваша репутация будет испорчена.
Если вы случайно зафиксируете учетные данные, убедитесь, что вы отозвали их в источнике. Это не позволит никому использовать его, если он его найдет. Я также предлагаю использовать такие инструменты, как Gitleaks и TruffleHog, для поиска секретов в ваших кодовых базах.
Отсутствует файл security.txt!
Это не проблема безопасности как таковая, поэтому я включил ее в качестве бонуса, но добавление файла security.txt в ваше приложение — одна из самых простых и лучших вещей, которые вы можете сделать для своей безопасности.
security.txt это текстовый файл, который вы помещаете в /.well-known/security.txt, который предоставляет ваши (безопасные) контактные данные на случай, если кто-то обнаружит проблему безопасности на вашем сайте. Это позволяет специалистам по безопасности очень легко связаться с вами, сокращая время и усилия, необходимые для сообщения о проблемах, чтобы вы могли быстрее их исправить. Создайте его здесь https://securitytxt.org/.