A7. XSS. OWASP TOP 10

На чтение 13 мин Просмотров 548 Опубликовано Обновлено

Автоматизированные инструменты могут обнаруживать и использовать все три формы XSS, есть свободно доступные платформы эксплуатации. XSS является второй по распрастраненности проблемой в OWASP Top 10 и встречается примерно в 2/3 всех приложений. Автоматизированные инствументы могут автоматически обнаруживать некоторые проблемы XSS, особено в зрелых технологиях, таких как PHP, ASP.NET. Влияние XSS является умеренным для отраженного и DOM XSS и серьезным для хранимого, с удаленным выполнением кода в браузере жертвы, например кража учетных данных или доставка вредоносного ПО.

Содержание
  1. Является ли приложение уязвимым?
  2. Как предотвратить
  3. Профилактика XSS.
  4. Правило 0.
  5. Правило 1.
  6. Правило 2.
  7. Правило 3.
  8. Правило 4.
  9. Правило 5.
  10. Правило 6.
  11. Правило 7.
  12. Дополнительное правило 1. HttpOnly.
  13. Дополнительное правило 2. Политика безопасности контента.
  14. Дополнительное правило 3. используйте заголовок ответа X-XSS-Protection.
  15. Полезные ссылки
  16. XSS — Cross-Site scripting. Суть уязвимости заключается во внедрении в выдаваемую сервером страницу вредоносного кода.
  17. Важная информация для приложений на ASP.NET:
  18. Валидация входных данных по WhiteList:
  19. Способ получения невалидированных данных на сервере:
  20. Защита от XSS атаки:

Является ли приложение уязвимым?

Существует три формы XSS, обычно предназначенные для браузеров пользователей:

  • Отраженный XSS : приложение или API включает не проверенный и неэкранированный пользовательский ввод как часть вывода HTML. Успешная атака может позволить злоумышленнику выполнить произвольный HTML и JavaScript в браузере жертвы. Как правило, пользователю необходимо взаимодействовать с какой-либо вредоносной ссылкой, указывающей на контролируемую злоумышленником страницу, например с вредоносных веб-сайтов, рекламных объявлений и т. П.
  • Хранимый XSS : приложение или API хранит неанизированный пользовательский ввод, который позже просматривается другим пользователем или администратором. Сохраненный XSS часто считается высоким или критическим риском.
  • DOM XSS. Платформы JavaScript, одностраничные приложения и API, которые динамически включают контролируемые злоумышленником данные на страницу, уязвимы для DOM XSS. В идеале приложение не должно отправлять контролируемые злоумышленником данные в небезопасные API-интерфейсы JavaScript.

Типичные атаки XSS включают в себя кражу сеанса, захват учетной записи, обход MFA, замену или удаление узла DOM (например, панели входа в троян), атаки на браузер пользователя, такие как загрузка вредоносного программного обеспечения, регистрация ключей и другие атаки на стороне клиента.

Как предотвратить

Для предотвращения XSS необходимо отделить ненадежные данные от активного содержимого браузера. Это может быть достигнуто путем:

  • Использование каркасов, которые автоматически выходят из XSS, таких как последняя версия Ruby on Rails, React JS. Изучите ограничения XSS-защиты каждого фреймворка и соответствующим образом обработайте варианты использования, которые не охвачены.
  • Экранирование ненадежных данных HTTP-запроса на основе контекста в выводе HTML (тело, атрибут, JavaScript, CSS или URL) устранит уязвимости отраженного и хранимого XSS. OWASP Шпаргалка «Предотвращение XSS» содержит информацию о требуемых данных вылетающих техники. https://www.owasp.org/index.php/XSS(CrossSiteScripting)PreventionCheatSheet.
  • Применение контекстно-зависимой кодировки при изменении документа браузера на стороне клиента действует против DOM XSS. Когда этого нельзя избежать, к интерфейсам API браузера можно применить аналогичные контекстно-зависимые методы экранирования, как описано в Шпаргалке OWASP «Предотвращение XSS на основе DOM» .
  • Включение Политики безопасности контента (CSP) в качестве средства защиты от XSS, обеспечивающего глубокую защиту. Это эффективно, если не существует других уязвимостей, которые позволили бы размещать вредоносный код через локальные файлы (например, перезапись пути или уязвимые библиотеки из разрешенных сетей доставки контента).

Профилактика XSS.

Следующие правила предназначены для предотвращения всех XSS в вашем приложении. Хотя эти правила не дают абсолютной свободы при помещении ненадежных данных в документ HTML, они охватывают (или должны охватывать) подавляющее большинство случаев общего использования. Вам не нужно разрешать все правила. Многие организации могут обнаружить, что правила №1 и №2 являются исчерпывающими для их нужд.

Правило 0.

Правило заключается в том, чтобы не помещать ненадежные (непроверенные) данные в HTML, если он не входит в скоуп правил 1-5. Причина правила 0 состоит в том, что в HTML так много странных контекстов, что список экранирующих правил становится очень сложным. Невозможно придумать какую-либо вескую причину для того, чтобы помещать ненадежные данные в эти контексты. Это включает в себя «вложенные контексты», такие как URL внутри js.

<script> ... НИКОГДА НЕ ОСТАВЛЯЙТЕ НЕПРАВИЛЬНЫЕ ДАННЫЕ ЗДЕСЬ ... </ script> непосредственно в скрипте
<! - ... НИКОГДА НЕ ОСТАВЛЯЙТЕ НЕПРАВИЛЬНЫЕ ДАННЫЕ ЗДЕСЬ ... -> внутри HTML-комментария
<div ... НИКОГДА УСТАНОВИТЬ НЕДОПУСТИМЫЕ ДАННЫЕ ЗДЕСЬ ... = test /> в имени атрибута
< НИКОГДА НЕ ОСТАВЛЯТЬ НЕДОПУСТИМЫЕ ДАННЫЕ ЗДЕСЬ ... href = "/ test" /> в имени тега
<style>... НИКОГДА НЕ ОСТАВЛЯТЬ НЕДОПУСТИМЫЕ ДАННЫЕ ЗДЕСЬ ... </ style> прямо в CSS

Правило 1.

Это правило для тех случаев, когда необходимо поместить ненадежные данные непосредственно в HTML. Это может быть обычный тег (div, p , span, …). Большинство веб-фреймворков имеют методы экранирования HTML для символов, описанных ниже. Однако, это совершенно недостаточно для других контекстов HTML. <body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>. Используйте следующие символы с кодировкой сущности HTML, чтобы предотвратить переключение в любой контекст выполнения, такой как сценарий, стиль или обработчики событий. Использование шестнадцатеричных сущностей рекомендуется в спецификации. В дополнение к 5 символам, значимым в XML (&, <,>, «, ‘), добавлена косая черта, поскольку она помогает завершить сущность HTML.

&  ->  & amp;
 <  ->  & lt;
 >  ->  & gt;
 "  ->  & quot;
 '  ->  & # x27;" не рекомендуется, поскольку его нет в спецификации HTML
 /  -> & # x2F ; косая черта включена, поскольку она помогает завершить сущность HTML

Правило 2.

Сброс атрибута перед вставкой ненадежных данных в общие атрибуты HTML. Правило предназначено для помещения ненадежных даннх в типичные значения атрибутов (weight, name, value). Не следует использовать для сложных атрибутов, таких как href, src, style или обработчиков событий (mouseover или других). Крайне важно, чтобы атрибуты обработчика событий следовали правилу №3 для значений HTML, JS.

<div attr=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...&gtcontent inside UNquoted attribute
<div attr='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'&gtcontent inside single quoted attribute
<div attr="...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE..."&gtcontent

Правило 3.

Правило относится к динамически-генерируемому JS. Как к блокам сценариев, так и к атрибутам EventEmitter. Единственное надежное место для размещения ненадежных данных в эотм коде — внутри «data value». Включение ненадежных данных в любой другой контекст JS довольно опасно, так как очень легко переключиться в контекст выполнения с символами.

<script>alert('...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...')</script>     inside a quoted string
 <script>x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'</script>          one side of a quoted expression
 <div onmouseover="x='...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...'"</div>  inside quoted event handler *

Правило 3.1. HTML экранирует JSON в контексте HTML и читает при помощи JSON.Parse() В мире Web 2.0 необходимость динамического генерирования данных приложением в контексте javascript является обычной. Решение состоит в том, чтобы сделать AJAX-вызов для получения значений, но это не всегда эффективно. Часто начальный блок JSON загружается на страницу, чтобы действовать как единое место для хранения нескольких значений.

Bad response

HTTP/1.1 200 Date: Wed, 06 Feb 2013 10:28:54 GMT
Server: Microsoft-IIS/7.5....
Content-Type: text/html; charset=utf-8 <-- bad
....
Content-Length: 373
Keep-Alive: timeout=5, max=100
Connection:
Keep-Alive {"Message":"No HTTP resource was found that matches the
request URI 'dev.net.ie/api/pay/.html?HouseNumber=9&AddressLine
=The+Gardens&AddressLine2=foxlodge+woods&TownName=Meath'.","MessageDetail":"No
 type was found that matches the controller named 'pay'."} <-- this
script will pop!!

Good response

HTTP/1.1 200 Date: Wed, 06 Feb 2013 10:28:54 GMT Server: Microsoft-IIS/7.5.... Content-Type: application/json; charset=utf-8 <--good ..... .....

Правило 4.

CSS-код и строгая проверка перед вставкой ненадежных данных в значения свойств стиля HTML

Правило № 4 для случаев, когда вы хотите поместить ненадежные данные в таблицу стилей или тег стиля. CSS на удивление мощный и может использоваться для многочисленных атак. Поэтому важно использовать ненадежные данные только в значении свойства, а не в других местах данных стиля. Вам следует избегать помещения ненадежных данных в сложные свойства, такие как url, поведение и пользовательские (-moz-binding). Вы также не должны помещать ненадежные данные в значение свойства выражения IE, которое допускает JavaScript. Пожалуйста, обратите внимание, что есть некоторые контексты CSS, которые никогда не cмогут безопасно использовать ненадежные данные в качестве входных данных — ДАЖЕ ЕСЛИ CSS ИЗБЕГАТЬ ! Вы должны будете убедиться, что URL начинаются только с «http», а не «javascript», и что свойства никогда не начинаются с «expression».

{ background-url : "javascript:alert(1)"; }  // and all other URLs
{ text-size: "expression(alert('XSS'))"; }   // only in IE

За исключением буквенно-цифровых символов, экранируйте все символы со значениями ASCII менее 256 в формате экранирования HH. НЕ используйте экранирующие ярлыки, такие как «, потому что символ кавычки может совпадать с анализатором атрибутов HTML, который запускается первым. Эти экранирующие ярлыки также подвержены атакам» escape-the-escape «, когда злоумышленник отправляет «, и уязвимому коду. превращает это в \ «, что позволяет цитату.

Если атрибут заключен в кавычки, для раскрытия требуется соответствующая кавычка. Все атрибуты должны быть заключены в кавычки. Атрибуты без кавычек могут быть разбиты множеством символов, включая [пробел]% * +, - /; <=> ^ и |. Кроме того, тег </ style> закроет блок стиля, даже если он находится внутри строки в кавычках, поскольку анализатор HTML запускается перед синтаксическим анализатором JavaScript. Обратите внимание, что мы рекомендуем использовать агрессивную кодировку и проверку CSS, чтобы предотвратить атаки XSS для атрибутов, заключенных в кавычки и без них.

Правило 5.

Удаление URL-адреса перед вставкой ненадежных данных в значеняи HTML-параметра URL

Это правило применимо в случае, когда необходимо вставить ненадежные данные в значение параметра HTTP GET. 

<a href="http://www.somesite.com?test=...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >
  1. За исключением буквенно-цифровых символов, экранируйте все символы со значениями ASCII менее 256 в формате экранировани %HH.
  2. Включение ненадежных данных: нельзя разрешать URL-адреса, так как нет хорошего способа отключить атаки с экранированием, чтобы предотвратить переключение URL-адреса.
  3. Все атрибуты должны быть в кавычках.
  4. Атрибуты без кавычек могут быть разбиты множеством символов, включая [пробел]% * +, — /; <=> ^ и |.
  5. Обратите внимание, что в этом контексте кодирование объектов бесполезно. ВНИМАНИЕ: Не кодируйте полные или относительные URL-адреса с помощью URL-кодировки!
  6. Если ненадежный ввод предназначен для помещения в href, src или другие атрибуты на основе URL, его следует проверить, чтобы убедиться, что он не указывает на непредвиденный протокол, особенно ссылки Javascript. Затем URL должны быть закодированы на основе контекста отображения, как и любой другой фрагмент данных. Например, управляемые пользователем URL-адреса в ссылках HREF должны быть закодированы атрибутом.
String userURL = request.getParameter( "userURL" )
boolean isValidURL = Validator.IsValidURL(userURL, 255);
if (isValidURL) {
<a href="<%=encoder.encodeForHTMLAttribute(userURL)%>">link</a>
}

Правило 6.

Проверка HTML — разметки.
 Если приложение обрабатывает разметку — используйте инструменты, предложенные OWASP: https://github.com/mganss/HtmlSanitizer, https://www.owasp.org/index.php/OWASPJavaHTMLSanitizerProject, https://github.com/ecto/bleach.

Правило 7.

Предотвращение XSS на основе DOM.

OWASP рекомендует ознакомиться со статьей: https://www.owasp.org/index.php/DOMbasedXSSPreventionCheat_Sheet #

Дополнительное правило 1. HttpOnly.

Чтобы помочь смягчить влияние недостатка XSS на ваш сайт, OWASP также рекомендует установить флаг HTTPOnly для файлов cookie сеанса и любых пользовательских файлов cookie, к которым нет доступа ни одним из написанных вами Javascript. Этот флаг cookie обычно включен по умолчанию в приложениях .NET, но на других языках его необходимо установить вручную. OWASP рекомендует ознакомиться со статьей: https://www.owasp.org/index.php/HTTPOnly.

Дополнительное правило 2. Политика безопасности контента.

Существует еще одно хорошее комплексное решение для смягчения воздействия недостатка XSS, которое называется Content Security Policy. Это механизм на стороне браузера, который позволяет создавать исходные белые списки для клиентских ресурсов вашего веб-приложения, например, JavaScript, CSS, изображений и т. Д. CSP через специальный заголовок HTTP указывает браузеру выполнять или отображать ресурсы только из этих источников.

Дополнительное правило 3. используйте заголовок ответа X-XSS-Protection.

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

Полезные ссылки

  • https://www.owasp.org/index.php/OWASPProactiveControls#tab.3DOWASPProactiveControls_2016
  • https://www.owasp.org/index.php/Category:OWASPApplicationSecurityVerificationStandard_Project
  • https://www.owasp.org/index.php/TestingforReflectedCrosssitescripting(OTG-INPVAL-001)
  • https://www.owasp.org/index.php/TestingforStoredCrosssitescripting(OTG-INPVAL-002)
  • https://www.owasp.org/index.php/TestingforDOM-basedCrosssitescripting(OTG-CLIENT-001)

XSS — Cross-Site scripting. Суть уязвимости заключается во внедрении в выдаваемую сервером страницу вредоносного кода.

Существует три типа XSS атак:
— Reflected XSS
— Persistent XSS
— DOM XSS

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

Важная информация для приложений на ASP.NET:

Не все контролы в ASP.NET автоматически производят HTML Encode выходных данных.
MVC Razor View Engine производит HTML Encode всех выходных данных.
Для кодирования данных можно использовать: AntiXssEncode.HtmlEncode(someText);

Валидация входных данных по WhiteList:

ASP.NET автоматически производит валидацию всех входных данных.
Отключить валидаци можно в Web.config. Данную настройку можно менять на уровне страницы, .
<system.web>
<pages validateRequest=»false»>
</system.web>

Начиная с ASP.NET 4.5 возможно валидацию возможно отключить на уровне контрола:
<asp:TextBox runat=»server» ValidationRequestMode=»Disabled» />

Способ получения невалидированных данных на сервере:

Таким способом мы не отключаем валидацию в настройках или на уровне страницы/контрола.
var searchString = Request.Unvalidated.QueryString[«q»];

Пример для MVC. Отключение валидации через атрибут поля:

public class User
{
   public string Name {get;set;}
   [AllowHtml]
   public string Password {get;set;}
}

Защита на уровне браузера:


Большинство браузеров имеют встроенную защиту от XSS атак. За данную функцию отвечает заголовок X-XSS-Protection.
Дополнительная информация о браузерной защите: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection

Пример настройки заголовка:

ASP.NET

<system.webServer>
    <httpProtocol>
        <customHeaders>
            <clear />
            <add name="X-Xss-Protection" value="1; mode=block" />
        </customHeaders>
    </httpProtocol>
</system.webServer>

В ASP.NET Core:

ASP.NET Core

public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory)
{
      app.Use(async (context, next) =>
                {
                    context.Response.Headers.Add("X-Xss-Protection", "1");
                    await next();
                });
     app.UseMvc();
}

В IIS:

Настройка HTTP Response Headers: Name: X-XSS-Protection Value: 1 EntryType Local;

Защита от XSS атаки:

  • Всегда кодировать выходные HTML данные для конкретного контекста;
  • Принимать во внимания что не все контролы в ASP.NET производят автоматическую HTML кодировку выходных данных;
  • Применять «Whitelist», валидировать входные данные по списку доступных значений;
  • Применят Request валидацию;
  • Все данные из БД или другого источника которые выводятся в браузер, должны рассматриваться как untrusted, то есть эти данные могут содержать XSS скрипты;
  • Использовать заголовок «X-Xss-Protection» для браузерной защиты;
  • Проверять обфусцированные и укороченные URL адреса перед использованием.
OWASP
Оцените статью
( Пока оценок нет )
© 2024 IT-Systems.su