SDO СryptoNet

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

Одним из популярных векторов атаки явлются всевозможные инъекции: html, javascript, sql. Поэтому многие авторитетные источники рекомендуют экранировать юзер инпут посредством различных заклинаний. В этой статье излагается одно простое правило, следуя которому можно гарантированно решить проблему инъекций.

Правило простое: Не смешивайте форматы данных!

• Не присваивайте строки разного формата:
  

  lblName.Text = person.Name;

  Плохо: HTML ← обычный текст



• lblName.Text = HtmlEncode(person.Name);

  Хорошо: HTML ← HTML


• Не соединяйте строки разного формата:
  

  "<span>" + person.Name + "</span>"

  Плохо:HTML + обычный текст + HTML



• "<span>" + HtmlEncode(person.Name) + "</span>"

  Хорошо: HTML + HTML + HTML


• Будьте осторожны с вложенными форматами:
  

  label.Text = "<script>" + string.Format(script, string.Format(summary, string.Format(personUrl, id)) + "<script>";

  Плохо:HTML + JavaScript + URI + текст + HTML
  
  

  label.Text = "<script>" + HtmlEncode(string.Format(script, JavaScriptEncode(string.Format(person.Summary, UrlEncode(string.Format(personUrl, id)))))) + "</script>";

  Хорошо: HTML + HTML(JavaScript(URI(текст)) + HTML

Формат

У всех данных есть формат. Самый простой формат это обычный текст где все символы равны и не несут никакого дополнительного смысла. Любой другой формат основанный на текстовых данных будь то csv, html, javascript имеет управляющие символы — запятые, теги, спец. символы. При вышеуказанном смешивании форматов возникают опасные ситуации когда один формат трактуется как другой.
Например в ASP.NET у Label контрола, свойство Text трактуется как HTML. Поэтому если мы присвоем этому свойству значение в другом формате (например обычный текст), то мы откроем потенциальную HTML уязвимость. Именно поэтому нужно использовать специальные переходники между форматами, которые экранируют спец. символы. Так переходник из обычного текста в HTML превратит "<script>" в "&lt;script&gt;". А переходник из обычного текста в URI превратит «example.com?<script>alert('pwned');</script>» в «example.com%3F%3Cscript%3Ealert('pwned')%3B%3C%2Fscript%3E».
Подобные переходники существуют практически во всех языках и платформах — .NET: HtmlEncode, UrlEncode, PHP: htmlentities, urlencode, серверный JavaScript: escape, encodeURI & encodeURIComponent. Для SQL запроса достаточно использовать параметризированные запросы которые будут обработаны уже самой базой данных.

Вот 3 простых пункта которые облегчат вам жизнь:

• Знайте формат используемых текстовых переменных, свойств, полей. Для удобства можете добавить суффиксы к именам: HeaderHtml, AvatarUrl.
• Сделайте библиотеку переходников: HtmlEncode, UrlEncode, JavaScriptEncode.
• Будьте внимательны при работе с данными разного формата.

Про PHP-инъекции
В одном из обсуждений этой статьи мне привели аргумент, что моё правило не работает с php-инъекциями. Я хочу показать, что оно работает. Итак, рассмотрим банальный код:

include($_GET['path']);

Если я передам в GET запросе «evil.php», то скрипт благополучно запустит указанный эксплоит. А теперь рассмотрим эту ситуацию в стиле моего правила. Из описания ясно, что функция include ожидает путь к файлу в формате текущей файловой системы или URI. А формат содержимого $_GET['path'] это обычный текст. Как избежать инъекции? Написать pathEncode который приведет этот текст к правильному формату пути, или если это невозможно вернет пустую строку (например проверит по белому списку разрешенных путей). В таком случае

include(pathEncode($_GET['path']));

или упадет с эксепшином или загрузит файл. Главное четко понимать какой формат ожидает include и какой формат приходит от пользователя.

Источник: habrahabr.ru