Сама презентация:

Невоторые полезные ссылки

 

 


Уже послезавтра (ну ладно, почти послезавтра) я буду делать доклад на очередной встрече харьковских QA - QAClub'е. И все было бы ничего, если б в анонсе встречи не были добавлены следующие строчки:

"Докладчики постараются рассказать на уровне, который будет доступен и для людей, только знакомящихся с темой безопасности web-приложений. Для понимания доклада про XSS (cross site scripting) знание JavaScript не обязательно".

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

  • Безопасность и Web - последние тредны о security в web'е.
  • JavaScript и HTML - пару слов об этом, браузерах и DOM, это необходимый минимум теории, который позволит понять остальное.
  • XSS – что это такое и с чем его едят? - наконец-то расскажу что означают буквы "XSS". 
  • XSS: тогда и сейчас - от 90-х до сегодня, экскурс в историю, основные тренды.
  • Делаем первые шаги - приступаем к практике, видео реальной XSS специально для QAClub(!).
  • Как это было у них? - истории взлома известных сайтов.
  • Что дальше? - пару слов об advanced техники xss.
  • Пару слов о защите

Как-то так. Хотелось бы услышать вопрсы/предолжения/комментарии от всех, кто собирается прийти на ивент и просто интересующихся этой темой.

До встречи на QAClub 1 марта 2012г.


Со времен ASP.NET 1.1, по умолчанию, у всех страниц свойство ValidateRequest было равно true. Это означает, что при вводе в поле ввода определенные спецсимволы (пример: <,>,&,#)  и отправки формы на сервер мы успешно получим HttpRequestValidationException.

Непонятное, на первый взгляд, поведение объясняется достаточно просто - защита от XSS атак. XSS (cross site scripting) - один из типов атак на веб-сайт, целью которой является вставка (инъекция)  чужого javascript-кода на атакуемый сайт. Результатами такой атаки могут быть от показа пользователю ненужных ему сообщений, до кражи cookie и перенаправления на другой сайт, который может содержать вредоносный код. Пример такой ситуации можно посмотреть в XssSample.aspx.

Но так как в определённых ситуациях должна быть возможность ввести любой символ, то приходится отключать request validation. Для предотвращения XSS-атаки при отображении пользователю введенного текста необходимо экранировать специальные символы с помощью метода Server.HtmlEncode(). Пример кода находится в AntiXssSample.aspx.

На первый взгляд, кажется что всё просто и понятно. Но есть некоторые нюансы:

  • необходимо помнить о том, что request validation отключен и нужно экранировать весь введенный пользователем текст во все поля (помним правило: никогда(!) не доверять данным, которые ввёл пользователь);
  • если используется Server.HtmlEncode(), то помним, что есть ещё “обратный” метод Server.HtmlDecode();
  • можно не отключать request validation и экранировать все введенные данные на стороне клиента с помощью javascript, но при этом не забывать о валидации (проверки) данных на сервере.

В целом, при правильном подходе никаких проблем с отключением request validation не должно быть, но всегда необходимо помнить о безопасности.

Ещё стоит отметить то, что механихм request validation немного поменялся в ASP.NET 4. Теперь он, по умолчанию, проверяет не только запросы к aspx страницам, но и все остальные запросы к серверу. Отключить это можно в web.config таким способом:

<httpRuntime requestValidationMode="2.0" />

Ссылки по теме:

Ссылка на пример: https://github.com/e0ne/BlogSamples


HTML Decode/Encode.

Если кто-то слышал об такой атаке на веб-сайты, как XSS Injection, то он(она) знает что для предотвращение такой атаки необходимо использовать функции HtmlEncode/HtmlDecode. XSS Injection (Cross-site injection) - один из способов атак веб-приложений, главной идеей которого является вставка(инъекция) чужого javascript-кода на атакуемый веб-сайт. Как минимум, это может привести к краже печенек cookies и получении прав администратора сайта. ...

1.1. ASP.NET

Это происходит, примерно, так:
Допустим, у нас есть форма для отправки комментарием, где пользователь вводит свой еmail и текст коммеентария. Самый простой обработчик кнопки добавить окмментарий будет выглядить так:

protected void OnAddCommentClick(object sender, EventArgs e)
{
 var pageId = this.GetPageId();
 var email = this.txtEmail.Text;
 var comment = this.txtComment.Text;
 CommentsService.AddComment(pageId, email, comment);
}

С первой точки зрения этот код не содержит никаких ошибок, компилируется и корректно сохраняет данные в БД. Но, если в тексте  комментария будет любой HTML или JavaScript-код, то при отображении этого комментария на страницу без предварительной обработки мы увидем, что HTML и JavaScript-код без особых проблем обрабатываются браузером.
Таким образом, мы сделали наш сайт уязвимым и нарушили одно из базовых правил проектирования ПО: “Не доверять данным, которые пришли извне нашей системы”. От себя еще добавлю: вдвойне недоверять данным, которые были введенны пользователем. Чтобы исправить это ошибку, необходимо всего-лишь вызвать метод HttpServerUtility.HtmlEncode(), перед сохранением данных в базу:


 var email = Server.HtmlEncode(this.txtEmail.Text);
 var comment = Server.HtmlEncode(this.txtComment.Text);

После чего, строка вида “<script>alert(‘hello!’);</script>” будет сохранена в базу в таком виде:

 &lt;script&gt;alert(‘hello!’);&lt;/script&gt;

Теперь все хорошо: любой введенный пользователем текст не ламает нашу верстку и не вызывает выполнения стороннего javascript (пример 2).
Но все не так просто, как кажется. Теперь, если такой код вставить в обработчике OnAddPage(), где администратор сайта будет добавлять страницы, то вместо красивого текста пользователи увидят набор непонятных символов. Поэтому, при отображении содержимого страницы мы вызываем метод HttpServerUtility.HtmlDecode(), который переведет сохраненный в базе данных текст в такой вид, чтобы браузер его корректно обрабатывал.

Таким образом, мы избавили наш сайт от XSS Injection дали возможность пользователям воодить разнообразные данные без вреда для сайта.

Примечание. Во всех примерах выше свойство странице EnableRequestValidation было установлено в false для возможноти ввода символов “<“ и “>”.
Примечание для ASP.NET 4.0/ASP.NET MVC 2.0. В ASP.NET 4.0/ASP.NET MVC 2.0 появилась конструкция <%: ... %>, которая делает за нас HTML Decode/Encode.

1.2. JavaScript

Если нам необходимо реализовать данную функциональность на клиенте с помощью javascript, то нам на помощь приходит jQuery:

function htmlEncode(html) {
 return $('<div/>').text(html).html();
}
function htmlDecode(text) {
 return $('<div/>').html(text).text();
}

1.3 Python/Django

В фреймворке Django HTML Decode работает по умолчанию, и для его отключение в шаблоне (template) добавить блок {% autoescape off %} и в нем поместить все элементы, для которых нам не нужен HTML Decode, после чего закрыть блок с помощью {% endautoescape %}.

2. URL Decode/Encode.

В отличии от HTML Encode/Decode незаэкранированный url больших проблем не вызывает, за исключением двух моментов: url становится не таким простым и понятным для пользователя и это не очень хорошо влияет на SEO.

2.1 ASP.NET

Рассмотрим такую ситуацию: у нас есть сайт с функцией поиска по нем. Стандартная форма поиска содержит поле для вводи и кнопу "Поиск". В простейшем случае при нажатии на кнопку “Поиск” у нас есть такой обработчик:


protected void OnSerachClick(object sender, EventArgs e)
{
 var searchText = this.txtSearch.Text;
 car url = String.Format(“{0}?q={1}”, VirtualPathUtility.ToAbsoluteUrl(“~/Search.aspx”), searchText);
 Response.Redirect(url);
}

Вполне рабочий код, за исключением того, что в некоторых случаях в итоге мы получаем не очень красивый url вида:

/Search.aspx?q=some%20keywords

Конечно, такой url правильно обрабатывается браузером, но не всем пользователям будет понятно что он значит. Происходит это из-за того, что браузер автоматически заменяет символ пробела и ряд других символов на  их шестнадцатиричное значение вида %XX, где XX - код символа в шестнадцатиричной системе.
Сделано это было давно, кода браузеры были маленкими еще не умели отображать нелатинские символы в строке ввода адреса и для правильного отображения разнообразных символов.
И тут нам на помощь приходят методы HttpServerUtility.UrlEncode() и HttpServerUtility.UrlDecode() которые предназначены для переобразования параметров строки запроса в понятный для пользователей вид. Отдельно отчему, что эти методы предназначены для обработки исключительно параметров url, а для переобразования адреса к необходимому ресурсу существует метод HttpServerUtility.UrlPathEncode(), работа которого больше похожа на работу метода HttpServerUtility.HtmlEncode(), но учитывает все особенности построения url. Этот метод не имеет метода для обратного переобразования, но при правильном подходе к проектированию приложенич это не понадобится.

2.2. JavaScript

Аналог URL Encode в javascript - функция encodeURI()