OWASP Top 10: A6 Неправильная конфигурация безопасности

Что такое неправильная настройка безопасности?

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

Как определить неправильную конфигурацию безопасности

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

Недостаточное усиление безопасности. Мы часто забываем, что это касается всех частей стека приложений, это также включает в себя безопасность API, о которой часто забывают. Большинство приложений в наши дни состоят из полных технических решений, и проблемы могут возникнуть в любом из этих компонентов. Однако для правильного тестирования нам необходимо иметь хороший обзор нашей тестируемой системы.
Когда наша цель использует облачные сервисы, им также необходимо правильно настроить аутентификацию и авторизацию для них.
Если включены функции, которые не используются, это может привести к некоторому опасному воздействию на безопасность в определенных случаях. Пример, который мы можем придумать, - оставить открытым ненужный порт, когда на нем запущено уязвимое программное обеспечение.
Некоторые администраторы очень ленивы, и они могут оставлять пароли по умолчанию или их очень легко угадать, например, test / test. Конечно, это также неправильная настройка безопасности.
Наша цель должна поддерживать свои системы и зависимости в актуальном состоянии. Помимо поддержания их в актуальном состоянии, нам необходимо убедиться, что эти компоненты включены и настроены должным образом.
Если для любого из параметров, связанных с безопасностью, установлено небезопасное значение.
Сервер не будет отвечать заголовками безопасности или директивами. Конечно, когда они установлены, они должны содержать соответствующие значения безопасности.

Какие меры по смягчению последствий

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

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

1. Протестируйте конфигурацию сетевой инфраструктуры

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

2. Неправильные настройки облачного хранилища

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

3. Тестирование альтернативных методов HTTP

Как мы уже говорили в главе 5 (Неработающий контроль доступа), мы можем использовать метод OPTIONS http, чтобы узнать, какие методы http мы можем выполнить, и иногда это может касаться методов http, которые не полностью реализованы на сервере.

4. Протестируйте строгую транспортную безопасность HTTP

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

Итак, как мы ищем это?

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

Мы можем начать с поиска в Google и поиска файлов conf или yaml или xml или чего-либо, связанного с конфигурациями.

```xml
filtype:cfg or filetype:yml or filetype:xml or intitle:"Config" or ...
```

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

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

Примеры неправильной настройки безопасности

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

https://hackerone.com/reports/1066410

Во время его попыток мы видим, что он нашел файл, содержащий ключ API Google. Этот ключ API использовался для сокращения URL-адресов, что позволило бы злоумышленнику замаскировать свои URL-адреса под URL-адрес компании. Это может привести ко всем видам фишинговых и мошеннических атак. Во время атаки также было заметно, что возможно открытое перенаправление, когда URL-адрес “https://lnk.clario.co/?link =[URLHERE]принял бы любой URL-адрес, если бы он имел “clario.co ” в нем. Это несколько замечательных примеров неправильных настроек безопасности, когда у нас есть частные токены в общедоступном скрипте и когда открытое перенаправление было возможно на другой конечной точке.

Еще один замечательный пример был найден пользователем с именем “yourdarkshadow”, который обнаружил, что заголовок установлен неправильно, что приводит к неправильной настройке безопасности. https://hackerone.com/reports/12453 Это был заголовок Strict-Transport-Security, который защищает веб-сайты от так называемых атак с понижением рейтинга.

Как исправить неправильную настройку безопасности

Мы должны убедиться, что автоматизированные системы на месте, чтобы легко развернуть новую среду, которая идентична среде PRD в отношении безопасности и конфигурации.
Среды DTAP (разработка, тестирование, приемка и производство) в идеале должны быть идентичными, при этом убедитесь, что учетные данные не используются повторно.
Нам нужно включить минимально возможный объем функциональности. Если нам не нужен компонент для нашего приложения, мы должны отключить эти компоненты. Сюда входят теневые API, которые являются подключенными API, но о которых никто не знает, что они существуют.
Нам необходимо внедрить процесс периодического обзора безопасности, который фокусируется на стратегиях облачного хранилища (т. Е. сегментах s3)
Хорошее разделение компонентов с вниманием к разделению клиентов, если они используют одно и то же оборудование.
У каждого компонента должен быть очень четко определенный профиль безопасности
Наши приложения всегда должны отправлять директивы безопасности, такие как заголовки
Мы должны максимально автоматизировать проверку наших параметров безопасности, чтобы мы могли выявлять проблемы до того, как они будут перенесены в реальную среду. Статические обзоры кода также могут помочь.