зачем фильтрация? какая фильтрацция..? (int) - твоя фильтрация... http://forum.antichat.ru/thread30641.html
игрался с консолью мускула) может и было где то но я узнал что при иньекции в инсерте можно сделать блинд и выполнять запросы))хочу проверить прав или нет?) имеем таблица users теперь представим регистрацию на сайте) естественно будет больше колонок но не суть важно) смысл: INSERT INTO `users` (U_ID,U_PASSWORD) VALUES ($_GET['id'],$_GET['pass']); допустим как и должно быть мы же можем изменять параметры id и pass но как я понимаю должно быть так INSERT INTO `users` (U_ID,U_PASSWORD) VALUES ('$_POST['id']','$_POST['pass']'); тогда получится так mysql> INSERT INTO `users` (U_ID,U_PASSWORD) VALUES ('1','if(substring(version() ,1,1)=5,1,(select 1 union select 2))'); и выход (наверна): $_GET['id']=1',if(1=1,1,2)/* получится запрос INSERT INTO `users` (U_ID,U_PASSWORD) VALUES ('1',if(1=1,1,2)/*','') и он выполнится) естественно все прокатит при определенных фазах луны, выключенных магик_квотес и т.д.) прав я или нет?)
2jokester знаю я эту статью) но там нет объединиения insert и "Subquery returns more than 1 row" упомянув о срыве запроса ошибкой он не сказал что можно это провести и с другими запросами. не только селект как написано в статье) думаю это дополнение )))) и еще вопрос) в последнем запросе говорит про варнинг но не ерор) неужели нельзя провести провокацию на ошибку?)
j0ker13 Специально для тебя: п 2 (большие жирные зелёные буковки): [2] INSERT и другие п 4 (те-же самые буковки) [4] Альтернатива benchmark'y И вот тут уже твои примеры, только в качестве оператора, для примера взят select. Но это без разницы, оператор любой может быть, в том числе и update Просто прочти её
Хотелось бы заметить, что при update нельзя читать этуже таблицу, другую можно. Например:insert into users values(1,(select ...From users)) будет ошибка. Но это так,замечание.
Вообще-то сессии с помощью XSS угоняются из cookie, если в куках есть сессия - можно угнать, если найти xss
Гет запрос это переменные которые видна в адресной строке. Если ид сессии передается через гет, следовательно сессионид видно в браузере в адресной строке, следовательна надо передать сндферу адресную строку. Снифер.Пхп? +документ.Локатион. По другому нельзя!
Если сессия есть в адресной строке, где есть XSS (если пассивка), то там всегда будет сессия того, кто даёт такую ссылку)) Т.е. таким вычурным методом вы сопрете свою собственную сессию. Так что только +document.cookie было и остается актуальным Ну и совсем другое дело, если активная XSS, тогда достаточно будет перенаправить на свой PHP-снифер и взять рефа, без всяких +document.cookie, но смысла в таком занятии особого нет, т.к. в куках может быть что-то поинтересней чем просто сессиия, например id и прочие параметры, так что опять к нашим баранам: +document.cookie, как неизбежность
Ты наверное не правельно понял, может я чтото не догоняю. Уменя вданном случии, можно перкрепить снифер вместо автарки в профеле, когда юзер будет смотреть профиль, то у него должно передатся на снивер всё что у него в адрисной строке. Т.е. можно за юзать http_referer, адальше записыать в логи
Ты не догоняешь, это - активная XSS, читай мой пост выше про активки, какой смысл тырить только рефа, если можно стырить все куки. Реф и так тырица в нормальных снифах по умолчанию
Тогда да, будет достаточно рефа схватить, тогда вопрос не понятен вообще к чему - еще раз - в любом нормальном снифаке реф тырица и так по умолчанию, например в снифере от того же каника. Просто ставишь перенаправление на свой снифак и всё, только не забудь потом чувака обратно вернуть ЗЫЖ И не называй куки кэшом, это разные вещи
