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

public class Comment {
    int CommentId {get; set;};
    // еще много разных полей …
    string Text {get; set;};
    string Author {get; set;};
    bool IsApproved {get; set;};
}

Представим себе, что при отправке формы пользователь заполняет поле textarea с идентификатором Text и input поле с идентификатором Author, а на стороне сервера действие, сохраняющее комментарий в базу данных выглядит как:

[HttpPost]
public ActionResult SaveComment( Comment obj) {
    // тут всякий разный код
    UpdateModel( obj );
    // тут еще какой-то разный код
}

В этом случае нехороший пользователь может эмулировать POST обращение на сервер и передать пару значений IsApproved = true, чтобы автоматически показать сообщение без модерации. В этом сценарии, может быть, это не так страшно – комментарий можно удалить, однако похожий сценарий может быть применим к каким-то более важным бизнес-данным, поэтому такого допускать нельзя.

Есть три основных подхода, позволяющие избежать подобной проблемы.

Минимум кода – привязывать только нужные поля.

Для этого можно передавать параметры в метод UpdateModel():

UpdateModel ( obj, "Comment", new string { "Text", "Author" };

Еще один вариант, пометить аргумент действия атрибутом Bind:

[HttpPost]
public ActionResult SaveComment( 
                 [Bind(Include = "Text, Author")] Comment obj) {
    // … тут всякий разный код
    UpdateModel( obj );
    // тут еще какой-то разный код
}

Атрибут Bind можно использовать и в варианте [Bind(Exclude = “”)], указывая список полей, привязку которых не следует осуществлять. Однако метод с указанием только нужных полей оказывается надежнее при дальнейших модификациях модели – свойства остаются защищены от изменений, несмотря на то, что добавляются новые свойства в модели.

Чуть больше кода – использовать промежуточные модели.

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

public class CommentViewModel{
    string Text {get; set;};
    string Author {get; set;}
}

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

Совсем много кода – привязывать поля вручную

Самый гибкий, но и самый кропотливый в реализации способ – отказаться от использования методов UpdateModel и TryUpdateModel и проводить валидацию всех полей и конструирование нужных объектов самостоятельно. Этот метод оправдан когда для передаваемых данных необходимо выполнять сложные проверки и конструировать не один объект, а набор объектов со сложной логикой связи между ними. Кроме того, этот метод любят те, кто боится доверять привязку данных MVC Framework.

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

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

Базовые советы по обеспечению безопасности веб-приложений

1. Валидация пользовательского ввода

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

Основная рекомендация – отклонять некорректные данные и предлагать пользователю ввести данные в правильном формате.

Сложности возникают в классической задаче: ввод HTML тегов для оформления публикуемых на сайте текстов. Если пытаться вырезать недопустимые теги, существует большая вероятность, что злоумышленник придумает способ, как обойти «вырезалку» теги. Если же отклонять введенный текст, то пользователь может быть очень расстроен тем, что не понимает, из-за чего его текст был отклонен и где в нем недопустимый тег. Здесь на помощь приходит следующий совет.

Для часто используемых проверок имеет смысл создать вспомогательный класс, содержащий методы для проверки вводимых данных, тогда код может выглядеть как-то так:

public ActionResult ProcessData ( DataObject data )
{
    // Валидация
    if (! SomeValidationLogic.ValidateSomeData (data.DataField) )
        ModelState.AddModelError ("DataField", "DataField is invalid");
    // ... там дальше много кода
}

В свое время для MVC Framework 1.0 создавались различные библиотеки валидации вроде Validator Toolkit for ASP.NET MVC или xVal – можно посмотреть на их устройство для общего развития. Из неплохих современных фреймворков для валидации данных существует FluentValidation.

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

2. Форматирование вывода пользовательских данных

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

Для того чтобы избежать проблем с выводом разметки, там где вы ее не ожидаете, используйте метод Html.Encode(). Если же нужно допустить вывод некоторых тегов, то вы можете воспользоваться методами AntiXss.HtmlEncode() и AntiXss.HtmlAttributeEncode(), реализованном в библиотеке AniXSS, входящей в проект Microsoft Web Protection Library. В библиотеке AniXSS также доступен метод AntiXss.GetSafeHtmlFragment(), позволяющий выводить «безопасные» теги, вырезая «опасные» и корректно форматируя разметку.

Библиотеку AntiXss можно зарегистрировать в для использования по умолчанию для кодирования HTML разметки, об этом написано пошаговое руководство в блоге у Фила Хаака.

3. Корректное использование метода POST и защищенного протокола HTTPS

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

Хорошая практика использовать метод POST при выполнении важных действий, таких как удаление или изменение данных, поскольку злоумышленник легко может подставить пользователю ссылку вроде /somecontroller/delete/1 с другого сайта, заставив авторизованного ранее на вашем сайте пользователя, выполнить не всегда полезное действие.

Для данных, имеющих большую ценность, например, таких как персональные данные и данные о кредитных картах, стоит использовать безопасный протокол передачи данных HTTPS. При этом, сами формы, запрашивающие данные, должны быть отправлены по HTTPS пользователю, чтобы не давать злоумышленнику возможностей украсть или модифицировать данные перед отправкой на ваш сервер. Здесь на помощь приходит атрибут RequireHttps на соответствующих действиях контроллеров, требующий передачи данных по протоколу HTTPS.

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

public class UseHttps : ActionFilterAttribute 
{ 
  public override void OnActionExecuting(
                             ActionExecutingContext filterContext) { 

      if ( !filterContext.HttpContext.Request.IsSecureConnection) { 
          filterContext.Result =  
            new RedirectResult(
              filterContext.HttpContext.Request.Url.ToString().Replace
                                                  ("http:", "https:"));

               filterContext.Result.ExecuteResult(filterContext); 
      } 
      base.OnActionExecuting(filterContext); 
   } 
}

4. Корректная обработка ошибок и исключений

Ошибки и исключения в веб-приложениях случаются. В случае обращения по несуществующим адресам, либо при вызове действий контроллеров с идентификаторами несуществующих записей или некорректными идентификаторами данных сообщения об ошибках должны быть информативны для пользователя, однако не предоставлять информации о внутреннем устройстве веб-приложения. Аналогично и в случае возникновения исключений в обрабатывающем запросе коде или коде нижележащих слоев приложения. Достигается это с помощью включения Custom Errors в web.config.

Отдельно стоит обратить внимание на поведение веб-приложения при попытке неудачной загрузки файла: проверить корректность сообщений об ошибках при недостатке свободного места во временной директории на сервере, а также при загрузке чрезмерно большого файла (таймаут, ограничение на размер запроса на уровне IIS). Злоумышленник не должен меть возможность получать информацию о структуре файловой системы сервера.

5. Контроль прав доступа пользователей

При осуществлении пользователем действий, требующих определенных привилегий, необходимо проверять наличие у пользователя этих привилегий (роли, прав доступа к данным) при каждом обращении. Недостаточно проверять права доступа только при отображении основного действия со списком команд и в дальнейшем проверять лишь наличие авторизации пользователя. Совет достаточно простой, однако о нем легко забыть, пользуясь атрибутом [Authorize]. Следует проверить, что на действиях, требующих принадлежности к определенным ролям, указаны эти роли, например [Authorize(Roles = “Admin, Moderator”)].

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

public class AuthorizeItemAttribute: FilterAttribute, IAuthorizationFilter 
{ 
 
    public void OnAuthorization(AuthorizationContext filterContext) 
    { 
        //...
        // здесь идет код логики авторизации
        // доступа к данным на основании свойств
        // данных
        // ...
}

Частая ошибка, которую делают разработчики в таких случаях – скрывают ссылки на редактирование объектов, не защищая сам метод, позволяющий редактировать объект.

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

Почему эти советы особенно важны в контексте использования ASP.NET MVC?

В технологии ASP.NET WebForms часть из описанных выше проблем безопасности была решена за разработчика автоматически, например, WebForms брали на себя кодирование выводимого на экран текста (если не использовался Response.Write(), конечно), валидацию ViewState, валидацию параметров запросов и защиту от инъекций через валидацию механизма клиентских событий. Разумеется, для полной защиты от разных типов атак, разработчику требовалось соблюдать базовые принципы безопасности, однако во многом платформа WebForms брала заботы о безопасности на себя.

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

Зачем ломают веб-сайты?

Часто веб-разработчики пренебрегают угрозой, считая свой сайт защищенным методом «неуловимого Джо, который совсем никому не нужен». Однако, современные хакеры в большинстве своем не веселые добряки из девяностых годов, ломающие сайты только ради взлома или дефейса (публикации ругательных надписей и забавных картинок на главных страницах сайтов). Современным хакером движет жажда наживы и его цели вовсе не так прозрачны, как «просто уронить сайт». Взломщики охотятся за базами персональной пользовательской информации, списками рассылок, возможностями осуществлять спам-рассылки от лица вашего сайта, данными учетных записей сервисов в социальных сетях, если они как-то представлены на вашем сайте. Помимо этого, цель взломщиков может быть еще более хитрой – получение информации о друзьях пользователей и их предпочтениях в музыке, кино, книгах, с целью дальнейших рассылок с возможностью «втираться» в доверие пользователей, представляясь их друзьями, что-то знающими об их вкусах.

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

Как жить дальше?

Помнить об основных принципах безопасности веб-приложений и жить хорошо. В ближайшие дни я опубликую еще несколько небольших статей про самые неприятные атаки на веб-приложения и борьбу с ними.

Пожелания и комментарии по статье с радостью принимаются. Безопасность – тема сложная и всеобъемлющая, поэтому буду рад, если вы поделитесь советами в комментариях к этой статье.

Вспоминая прошлые годы, когда я активно участвовал в организации конференции “Платформа”, ближе ко времени конференции постоянно приходили люди, которым не хватило билетов, и слезно просили помочь купить билетик-другой. К сожалению, исключений мы не делали и делать не будем, на конференцию попадут только те, кто купит билеты пока они есть. Просто хочу напомнить, что лучше купить билет сейчас, чем потом кусать локти от обиды, получая отказы от организаторов.

Зарегистрироваться на конференцию Tech∙Ed Russia 2011 можно на официальном сайте по следующей ссылке.

По CMS есть набор видео (на английском), есть возможность заказать платные красивые шаблоны (способ монетизации проекта).

Быстро установить проект и начать создавать сайты можно через WebMatrix или даже без WebMatrix через Web Gallery.

[Оригинал сообщения]

Если есть желание использовать вместо ссылок изображения, то подойдет вот такой фрагмент:

<a href="@Url.Action("Create", "Products", new { ParentId = 1 })" title="Create">
        <img src="../../Content/Images/Create.png" />
</a>

В результате HTML будет таким:

<a href="/Products/Create?ParentId=1" title="Create">
        <img src="../../Content/Images/Create.png" />
</a>

Если есть желание использовать вместо ссылок кнопки, то подойдет вот такой фрагмент:

<input type="button" title="Create" value="Create" onclick="location.href='@Url.Action("Create", "Products", new { ParentId = 1 })'" />

В результате HTML будет таким:

<input type="button" title="Create" value="Create" onclick="location.href='/Products/Create?ParentId=1'" />

P.S. По тегу FAQ буду размещать краткие статьи, которые являются ответами на часто задаваемые вопросы.

Доступны бесплатная Community-редакция и пробная версия коммерческой редакции, которые можно скачать с сайта https://www.bitrix.net/ru/download/

Качайте и делитесь вашими отзывами, пожалуйста.

Требования: опыт работы на рынке интернет рекламы от 3 лет, позитивно-агрессивный настрой, умение работать в команде, стрессоустойчивость, чувство юмора и здоровый карьеризм.

Вознаграждение за успешную рекомандацию: коробки Windows 7 ultimate, Office 2011 для Mac и Call of Duty: Black OPS для Xbox

Присылайте резюме на gaidarma@microsoft.com

• 1 место – XBOX 360 + Kinect – ЗАО Ингениос и 56web
• 2 место – XBOBX 360 – Авдеев Александр и Wilmark Design
• 3 место – поездка на конференцию www.msDevCon.ru – ВебИнформСервис  и ООО "Кортек"

Поощрительный приз – книга Виктора Гичуна «Как создать интернет-компанию и заработать миллион» получат:

• Mindfor, Ltd.
• CrewBeat
• GreatDevelop
• Krona
• SoftAIN
• yuri
• Декларативные технологии
• Игнатьев Романэ
• ИП Основина ТЮ
• Лагута Юрий
• Лев Бондаренко
• Научно образовательный центр "Темп"
• Никита
• Общество с ограниченной ответственностью "БУКМАК"
• ООО "БИЗНЕС-ВЕБ"
• ООО "Воротько Корпорейшн"
• ООО "Компьютер Агент"
• ООО "КреатАйТи"
• ООО "ПРОЕКТ 24"
• ООО "РэйДизайн"
• ООО "Тайдекс"
• ООО "Хорошие решения"
• ООО АДО-Инжиниринг
• ООО НТЦ "ПартнерЪ"
• Павел
• Романов Вячеслав Александрович
• Студия "Интеллис"
• Терентьев Алексанр
• Юлий

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

Обязанности:

• продвижение продукта .NET Forge в онлайн-сообществах
• поддержка сообщества на русском и английском сайтах
• активность в блогах, форумах, соцсетях, твиттере + задействовать другие способы коммуникаций в онлайне
• подготовка контента для публикации в онлайн-СМИ
• организация PR-акций для продвижения продукта
• публичные выступления на конференциях

Требования к кандидату:

• профессиональное знание .NET на уровне разработчика
• кругозор и образование в сфере ИТ
• знание веб-технологий
• опыт работы с интернет-порталами
• опыт работы с контентом в онлайне (блоги, статьи, новости и пр.)
• активность и инициативность
• опыт публичных выступлений на конференциях
• отличный английский язык (технический, письменный)
• высшее образование

З/п по результатам собеседования (з/п хорошая :)).

Кандидатам обращаться на email: job@bitrix.ru