Хранимая, фрагментированная XSS на ustream.tv

XSS (Сross-site scripting) уязвимости увы далеко не редкость и встречаются куда чаще остальных, но интересные случаи связанные с ними можно пересчитать на пальцах двух рук. Я хочу рассказать об одном случае с фрагментированной XSS в теге meta у ресурса ustream.tv ^[1] и искренне убежден, что это как раз тот самый интересный и далеко не частый случай. Всех кому интересно, прошу под кат;)
И так, все как и всегда случилось в один из тех самых вечеров, когда придя домой понимаешь что на работу у тебя уже «не стоит», но запал не утих и ты идешь на кухню ставить чайник, обдумывая очередной хитрый план:) Вспомнился мне пост на Хабре о DDoS атаке на достаточно популярный ресурс ustream.tv ^[2]на который я, как ни странно, ни разу не заходил, его то я и решил посмотреть. Сказано — сделано и вот я уже зарегистрировался и вводил стандартное имя и описание канала: lalala"'>&# x27;
В исходном коде страницы канала красовалась следующая строчка:

<meta property="og:description" content="lalala"'>' @ USTREAM: lalala"'>'. " />

* This source code was highlighted with Source Code Highlighter [3].

Хм, типичная скучная хранимая XSSина подумал я и был в корне не прав — все теги из полей намертво вырезались, поэтому использовать скучное "><script>prompt('А вот она и я...XSSина');</script не представлялось возможным. Что ж, не беда, у нас же инъекция в очень удачном теге meta, а значит мы может встроить JS код благодаря, например, следующему вектору:

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

* This source code was highlighted with Source Code Highlighter [3].

Но и тут подстерегала «заковыка», была включена проверка первого символа, запрещающая использование цифры:

Увы беспечность разработчиков сыграла в который раз на руку, дело в том что достаточно часто разработчики при проверке символов строки забывают предварительно удалить «пробелы» — что и произошло в данном случае (это может стать роковой ошибкой, например, при проверке расширений файлов по блэклисту на Win платформах). Т.е. все что оставалось проделать для эксплуатации уязвимости — поставить tab в самом начале строки. Так и поступил, конечный вариант выглядел таким образом:

Фрагментация в данном участке была необходима в виду ограничения длинны имени канала в 50 символов, чего явно не хватило бы для полноценной хранимой XSS. На выходе мы получим следующую строку в исходном коде страницы канала:

<meta property="og:description" content="0;url=javascript:prompt(/* @ USTREAM: *//Hi/);" http-equiv="refresh" . " />

* This source code was highlighted with Source Code Highlighter [3].

После перехода на которую, можно было любоваться добрым приветствием:

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

• Не забывайте про html теги и двойные кавычки
• Если это JS событие описанное в атрибуте html тега, помните что нужно фильтровать не только кавычки, но и их html сущности & #x27; & #39; & apos; и т.д.
• Если это JS код в атрибуте href тега a, то не забывайте что при клике браузер их декодирует, а следовательно эта с виду безобидная строка тоже уязвимость:
  <a href="javascript:alert('%27%29%3Bprompt%28%2FXSS%2F%29%3B%2F%2F');">lalala</a>
  Но лучше конечно же не хранить JS код в href, для этого есть OnClick:)
• Не забывайте что экраниварония кавычек при выводе в теге script не достаточно

и т.д список может быть достаточно длинным да и тема уже достаточно освещена.
Безопасных вам всем проектов и хорошего дня!

Автор: