Ах, автоматизация. Каждый раз, когда я обнаруживаю, что делаю одну и ту же вещь более одного раза, у меня появляется склонность связать все это во что-то, что может начать происходить одним щелчком мыши. Или даже лучше, без кликов.
В последнее время я много писал о непрерывной интеграции , в основном используя TeamCity для выполнения задач по изменению исходного кода, по ночам и по требованию. Я автоматизировал развертывание веб-сайтов с помощью веб-развертывания , развертывание баз данных с RedGate , качество кода с помощью NDepend , статистику кода с помощью StatSVN и безопасность приложений с помощью Netsparker .
Недавно я начал использовать WCSA или, не в аббревиатуре, анализатор безопасности Web.Config. Эта маленькая прелесть позволяет вам вводить файл Web.config, затем он возвращается и сообщает вам все, что вы сделали неправильно в мире конфигурации безопасности. Я немного рассказал о безопасности Web.config в OWASP Top 10 для разработчиков .NET, часть 6: Неверная конфигурация безопасности, но есть гораздо больше, чем просто старые ошибки, отладка и трассировка.
Поскольку Web.config имеет тенденцию немного меняться со временем и представляет собой потенциально серьезную угрозу безопасности, если он плохо реализован, проверка его созрела для автоматизации.
Что мы на самом деле сканируем?
Как оказалось, очень много
- Отладка ASP.NET включена
- Учетные данные открытого текста
- Пользовательские ошибки отключены
- Аутентификация без cookie включена
- Незашифрованная связь с Auth. Печенье
- Используется неуникальный файл cookie для аутентификации
- Скользящий срок годности
- Определен либеральный путь
- Перенаправление URL возможно
- Ваши заявки не зашифрованы-проверены
- Ваши билеты не подтверждены
- Ваши билеты не зашифрованы
- Веб-куки не HttpOnly
- Веб-куки не требуют SSL
- ViewState для CSRF
- Нет проверки целостности на ViewState
- ViewState не зашифрован
- ViewState не может быть зашифрован
- Проверка страницы не используется
- Для cookie для roleManager не требуется SSL
- roleManager Cookie Истек срок действия
- Cookie-файлы roleManager не зашифрованы — проверены
- Cookie-файл roleManager не проверен
- cookie для roleManager не шифруется
- Роль cookie-файла roleManager является либеральной
- Состояние сеанса без файлов cookie включено
- Уровень доверия вашего веб-приложения выше минимального
- Используются жестко закодированные учетные данные
Многие из них — на самом деле я бы сказал, что большинство из них — часто упускаются из виду. Вы, вероятно, будете удивлены количеством выводов, которые инструмент обнаружит в вашем типичном файле Web.config. Хорошей новостью является то, что их (как правило) очень легко исправить, не прибегая к коду.
Сканирование правильного Web.config
Вернувшись в мою серию «Вы неправильно внедряете» Я автоматизировал развертывание веб-приложения на удаленном сервере IIS. Часть этого процесса включала использование конфигурационных преобразований, так что файл Web.config был изменен в соответствии с подходящей целевой средой в зависимости от используемой конфигурации сборки.
Когда дело доходит до безопасности Web.config, мы можем захотеть немного ослабнуть в среде разработки или интеграции. Например, мы можем оставить эти пользовательские ошибки отключенными и разрешить трассировку для помощи в процессе разработки. Тем не менее, это определенно не то, что мы хотим в тестовой и производственной средах, поскольку мы хотим, чтобы эти парни были последовательными и безопасными.
Суть в том, что нам нужно сканировать файл Web.config после его преобразования в соответствии с реальной средой . Чтобы сделать это, мы не можем просто просканировать Web.config в том виде, в котором он существует в системе контроля версий, а нам нужно проверить упакованную версию, которая должна быть развернута.
Вернувшись во второй части вышеупомянутой серии блогов, я посмотрел, как преобразуется Web.config и помещается в пакет, готовый к развертыванию. Это тот парень, которого мы хотим, поскольку он соответствует тому, что в конечном итоге окажется на сервере.
Настройка сборки
Во-первых, эта сборка будет зависеть от той, которую я настроил в пятой части серии, на которую я продолжаю ссылаться. Я назвал эту сборку «Пакет и развертывание», и то, что она делала как часть всего процесса, заключалась в том, чтобы сохранить развертываемый пакет как артефакт сборки. Это означает, что для нас уже проделана большая часть тяжелой работы, поскольку преобразованный Web.config просто сидит и ждет анализа.
Но прежде чем приступить к настройке TeamCity, нам нужно иметь консольное приложение WCSA на сервере. Это доступно на странице загрузок для WCSA и не должно быть перепутано с версией GUI. Помните, что это должно быть в состоянии бежать без присмотра. Я взял RAR-файл и просто распаковал его в каталог Program Files.
Приступая к делу, вот как выглядят общие настройки сборки:
Артефакты важны, поскольку это будет фактический отчет, который генерируется процессом. Обратите внимание, что есть и файл .html, который является фактическим отчетом, и папка «Отчетность», которая содержит некоторые зависимости отчета. С настройками VCS говорить не о чем, просто вернитесь к предыдущим постам, и все они абсолютно одинаковы.
Приступая к важному этапу — этапу сборки — вот что на самом деле сделает тяжелую работу:
Большая часть вышеперечисленного довольно проста, мы вскоре вернемся к тому, как Web.config попадает в каталог проверки сборки. Все, что нам нужно знать на данный момент, это то, что он будет существовать в корне каталога извлечения.
Теперь вы можете подумать: «Ну и дела, это была очень простая команда, где будет создаваться отчет?» и вы были бы правы — это просто. Информация об использовании WCSAConsole.exe показывает только один параметр (исходный файл Web.config), а быстрый просмотр WCSA.dll с помощью Reflector показывает, что определенно используется только один аргумент, что означает, что нам нужно проявить творческий подход.
На самом деле происходит то, что консоль WCSA создает отчеты только в папке «OutputReports» приложения, а затем уникально именует целевой HTML-файл, например «Report-web.config-129450894350422843.html». Там также есть папка «Отчетность», от которой зависит отдельный отчет (логотип и пара HTML-файлов). К счастью, их очень легко подобрать с помощью небольшого количества волшебства командной строки, заключенного в пакетный файл:
FOR /F %%I IN ('DIR *.html /B /O:-D') DO COPY %%I %1\WCSA.html & XCOPY Reporting %1\Reporting /I /Y & EXIT /B
То, что это делает, перечисляет все файлы в каталоге с расширением .html и делает это в обратном хронологическом порядке. Затем он копирует первый файл по пути, указанному в первом аргументе, переданном команде, и называет целевой объект «WCSA.html». Затем следует копия папки «Отчетность», а затем, прежде чем перечисление переходит к следующему файлу, программа завершает работу. Легко 🙂
На самом деле, два ресурса, на которые есть ссылки в этом скрипте, важны, потому что мы ссылались на них ранее, когда настраивали артефакты. Сценарий, приведенный выше, гарантирует, что они существуют в правильном месте, когда все этапы сборки завершаются, и TeamCity продолжает поиск артефактов.
Теперь мы собираемся вызвать это из TeamCity на втором этапе сборки и передать в качестве параметра каталог сборки. После того, как он запустится, у TeamCity будет все приятное и удобное для поиска в качестве артефактов и прикрепления к сборке для проверки.
Параметр команды на экране выше важен, так как командный файл будет использовать его для размещения артефактов в правильном месте.
Далее нам нужно решить, как запустить сборку. Поскольку он очень быстрый (всего несколько секунд) и создает небольшие артефакты, я собираюсь запускать его при каждой успешной сборке «Пакет и развертывание»:
Теперь это означает, что при каждом развертывании в серверной среде регистрируется, насколько безопасно был настроен наш Web.config после применения преобразований конфигурации. Ницца.
Теперь нам нужно установить некоторые зависимости, как зависимость моментального снимка от предыдущей сборки (мы хотим, чтобы она работала с той же версией VCS), так и зависимость артефакта, чтобы мы могли извлечь преобразованный файл Web.config откуда-то. Помните, что это Web.config после применения преобразований конфигурации:
Наконец, я хочу придать сборке профессиональный вид, поэтому давайте добавим вкладку отчета, перейдя в раздел Администрирование -> Конфигурация сервера -> вкладка Отчеты и попросив ее найти файл WCSA.html:
Вот и все, больше ничего не нужно делать, кроме как запустить сборку и насладиться великолепным небольшим отчетом Web.config:
Резюме
Это довольно простая небольшая сборка, и это хорошо. Что мне действительно нравится в этом, так это то, что он помогает поверхностным аспектам Web.config, которые часто не поняты или не реализованы. На самом деле для многих людей они будут немного неясными.
Например, файлы cookie только HTTP являются отличной защитой от межсайтовых скриптовых атак, которые пытаются украсть данные, сохраняемые в браузере, поскольку они не доступны клиентскому JavaScript. Все, что нужно, это простая запись < httpCookies > . Или проверка запроса, которая по умолчанию включена, но часто отключается в процессе разработки (практика, которую я оплакивал в прошлом ), является отличной защитой от ненадежных данных, содержащих вредоносную полезную нагрузку.
Хотя эти настройки являются базовыми, они часто проскальзывают и попадают в производственную среду. Эта сборка повышает их наглядность и позволяет легко создавать шаблоны и вставлять их после развертываний. Проверка безопасности не становится легче, чем это!
Обновление: я замаскировал (или, скорее, полностью пренебрег), чтобы сослаться на тот факт, что в идеале приложение WCSA должно храниться в VCS, а не устанавливаться на сервере, что создает зависимость конфигурации на компьютере сборки. Даг Рэтбоун очень хорошо формулирует это в своем ответе, озаглавленном « Сторонние инструменты, живут под вашим контролем над источниками, и в результате у нас получился хороший стеб». Хотя я полагаю, что есть действительные исключения, WCSA не является одним из них и может быть легко упакован с приложением. Сделайте все, что я изложил выше, просто поместите приложение WCSA в папку VCS вместе с приложением и вызовите его оттуда. Или не стесняйтесь спорить об обратном 🙂
Источник: http://www.troyhunt.com/2011/03/continuous-webconfig-security-analysis.html