Безопасный код

Повышение безопасности ASP.NET с помощью анализа кода в Visual Studio 2010

Саша Фауст

Любой, кто занимался разработками для ASP.NET, вероятно, согласится — открыто или нет, — что в какой-то период своей карьеры допускал ошибку, связанную с защитой, или сталкивался с соответствующей проблемой. На разработчиков часто давят, чтобы они как можно быстрее выдали код, а сложность платформы и огромное количество вариантов конфигурации нередко приводит к тому, что безопасность приложения оказывается в менее чем удовлетворительном состоянии. Кроме того, требования конфигурации для отладки и производственных условий различаются, из-за чего в производственном коде зачастую остаются отладочные настройки, вызывающие массу проблем.

С годами платформа ASP.NET повзрослела, через MSDN и блоги сообщества стала доступной более качественная документация, но узнать, какую именно функцию или параметр конфигурации следует использовать в каждом конкретном случае все равно затруднительно. Даже при хорошем знании функциональности, относящейся к безопасности, разработчик может допустить ошибки, которые могут создать бреши в защите приложения.

Рецензирование кода коллегами — полезный процесс и хороший способ отловить ошибки на ранних этапах. Тем не менее не у всех есть время и бюджет на это — или хотя бы знающие коллеги.

С введением анализа кода в Visual Studio 2005 разработчики получили возможность автоматически анализировать свой код на соответствие рекомендациям в решении широкого круга задач — дизайна, удобства в сопровождении, производительности и безопасности. Анализ кода был отличным инструментом, но не обеспечивал контроля в области безопасности для ASP.NET — до настоящего времени.

В этой статье я познакомлю вас с новыми правилами анализа кода ASP.NET, которые можно использовать совместно с анализом кода в Visual Studio и с автономной программой FxCop для повышения безопасности приложений ASP.NET.

Обзор

Вы можете скачать пакет правил для анализа ASP.NET-кода на безопасность для Visual Studio 2010 и FxCop версии 10.0 по ссылке go.microsoft.com/?linkid=9750555. В установочном комплекте содержатся три пакета новых правил:

  • ASP.NET.Security: В этой категории основной упор делается на рекомендациях по защите того, как инициализировать свойства System.Web.Ui.Page.
  • ASP.NET.MVC.Security: Правила безопасности, относящиеся к тому, как используется ASP.NET MVC.
  • ASP.NET.Security.Configuration: Правила безопасности, относящиеся к конфигурационным элементам в файлах web.config.

После установки пакета правил вы можете начать автоматический анализ безопасности своего веб-приложения, выбрав из меню Build команду Run Code Analysis on Web Site (рис. 1). В процессе анализа будут проверены каждый класс Page и файл web.config вашего приложения на соответствие правилам защиты для ASP.NET.

image: Running Code Analysis on a Sample Web Site

Рис. 1. Запуск анализа кода для примера веб-сайта

Например, одна из широко распространенных уязвимостей в защите веб-приложений — межсайтовые запросы, подделка которых позволяет злоумышленникам выполнять команды от лица другого пользователя. Стандартный способ для минимизации риска из-за этой уязвимости — применение свойства Page.ViewStateUserKey (bit.ly/cTSHM0). Вы также можете использовать AntiForgeryToken в ASP.NET MVC (bit.ly/ciiQIP). Оба способа предотвращают атаку с воспроизведением пакетов на ваше приложение. В процессе анализа кода осуществляются проверки на то, что в вашем приложении применяется подходящее решение.

Я довольно часто слышу от разработчиков, впервые выполняющих анализ кода, о чрезмерном количестве получаемых ими предупреждений (рис. 2). И поначалу легко почувствовать себя брошенным в одиночку разбираться, как все это исправить.

image: Violations Are Listed in the Error List Warnings Tab

Рис. 2. Нарушения правил перечисляются на вкладке Error List Warnings

Чтобы снять с вас часть бремени исправлений, в каждое правило включается четкое указание, что именно нужно сделать и как; заодно показываются некоторые ссылки, если вам нужно больше информации перед применением изменений (рис. 3).

image: Detailed Information in the Warnings Section

Рис. 3. Подробная информация в разделе Warnings

Анализ кода можно настроить на выполнение после каждой сборки; для этого выберите Website | Configure Code Analysis for Website, а затем установите флажок Enable Code Analysis on Build (defines CODE_ANALYSIS constant) (рис. 4).

image: Enabling Code Analysis During Build

Рис. 4. Включение анализа кода при каждой сборке

Анализ кода с помощью FxCop

Анализ кода доступен только в Visual Studio версий Premium и Ultimate. Однако вы можете использовать и автономную программу FxCop для анализа ASP.NET-кода. FxCop является частью Windows SDK. Выпуск Windows SDK 7.1 можно скачать по ссылке bit.ly/dzCizq.

При использовании стандартной утилиты FxCop для выполнения анализа потребуется чуть больше работы. Я пошагово проведу вас по операциям, необходимым для подготовки к анализу.

Обычно, когда вы компилируете свой веб-проект, разметка страницы (код страницы, не включаемый в файл отделенного кода) не компилируется и остается нетронутой в корне Web вашего приложения. ПРи первом запросе этой страницы пользователем ее разметка компилируется в отдельные сборки. Это позволяет обновлять сайт без перекомпиляции всего остального. (Подробнее о процессе компиляции ASP.NET-страниц см. по ссылке msdn.microsoft.com/library/ms366723.)

Поскольку автоматически компилируется не весь код, его часть не видна при анализе и некоторые важные проблемы защиты могут быть пропущены. Чтобы весь код был доступен для анализа, нужно выполнить принудительную предкомпиляцию всех страниц. Это можно сделать с помощью утилиты Publish Web Site, которая запускается выбором Build | Public Web Site. Эта утилита позволяет вам настроить, как будет опубликован веб-сайт, и именно здесь можно включить предкомпиляцию. Просто сбросьте флажок Allow this precompiled site to be updatable и щелкните OK (рис. 5). В итоге вы получите полностью скомпилированный сайт, готовый для анализа.

image: Publishing Web Site with Precompilation

Рис. 5. Публикация веб-сайта с предкомпиляцией

Теперь, когда у вас есть полностью скомпилированный сайт, «науськайте» на него FxCop.

Анализ ASP.NET требует функциональности, которая доступна только в версии FxCop для командной строки, поэтому откройте окно командной строки и перейдите в каталог, где установлена FxCop. Скорее всего это будет один из двух каталогов в зависимости от того, какую версию Windows вы используете — 32- или 64-разрядную:

C:\Program Files (x86)\Microsoft FxCop 10.0
  C:\Program Files\Microsoft FxCop 10.0

Из каталога FxCop можно запустить Fxcopcmd.exe, чтобы начать анализ кода. Для веб-сайта ASP.NET нужно ввести команду:

fxcopcmd.exe /file:"H:\MSDN\PrecompiledWeb\
    MSDNSampleSite\bin" /rule:
    AspNetConfigurationSecurityRules.dll 
    /rule:AspNetMvcSecurityRules.dll 
    /rule:ASPNetSecurityRules.dll /aspnet /console

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

Параметр /file указывает, какие сборки нужно анализировать. В этом примере мои предкомпилированные сборки сайта находятся в каталоге H:\\MSDN\\PrecompiledWeb\\MSDNSampleSite\\bin.

Параметр /rule задает, какие правила следует использовать при анализе. В этом примере я использую только три правила безопасности ASP.NET: AspNetConfigurationSecurityRules.dll, AspNetMvcSecurityRules.dll и ASPNetSecurityRules.dll.

Параметр /aspnet включает анализ ASP.NET, а параметр /console направляет выходные данные после анализа в консольное окно. Результаты показаны на рис. 6. Подробнее о Fxcopcmd и его разнообразных параметрах см. по ссылке msdn.microsoft.com/library/bb429474(VS.80).

image: Running ASP.NET Rules Using Fxcopcmd.exe

Рис. 6. Выполнение правил ASP.NET с использованием Fxcopcmd.exe

Заключение

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

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

Кроме того, вы можете реализовать собственные правила анализа кода. Если вас интересует этот путь, некоторую очень полезную информацию вы найдете в публикации Дьюка Камстра (Duke Kamstra) в блоге Code Analysis Team (bit.ly/blpP38). Также вам пригодится руководство по соответствующему процессу, описанное Татамом Одди (Tatham Oddie) в блоге (bit.ly/5tFrMw).

Саша Фост (Sacha Faust) — разработчик отдела платформы Microsoft Office 365. С ним можно связаться через блог blogs.msdn.com/b/sfaust.

Выражаю благодарность за рецензирование этой статьи эксперту: Брайан Салливан (Bryan Sullivan)