Куки и SQL-injection

Статус
В этой теме нельзя размещать новые ответы.

zeta

Новичок
Куки и SQL-injection

Используется вот такая функция для защиты от SQL-injection

function secure($str)
{
if(!is_numeric($str)) {
$str=mysql_real_escape_string($str);
}
return $str;
}

Вроде она все нормально фильтрует, кроме вот такого момента:


setcookie("auth",$m[id]);

вот именно на auth появляется возможность SQL-injection (сканнер показывает)

Как здесь отфильтровать?
Варианты

$id=(intval($id));

$id=(secure($id));

$m[id]=(intval($m[id]));

$m[id]=(secure($m[id]));

не помогают - все равно сканнер показывает уязвимость... Пишет что-то вроде

The Cookie variable PHPSESSID=10ce1790d624d22c15412fed3cf95517; auth has been set to %00' - в общем по-разному и всегда задействованы PHPSESSID и auth


Прошу сильно не пинать, я в этом полный чайник, просто скрипт (самопис) по функциям мне полностью подходит, там где всякие select и insert в базу данных - это я отфильтровала, а вот с куками чего-то не соображу что делать....
 

zeta

Новичок
Автор оригинала: fixxxer
>сканнер показывает

ухты!
И? Что такого? Никто не пользуется сканнерами для обнаружения уязвимостей? Все исключительно только ручками?
 

Alexandre

PHPПенсионер
просто скрипт (самопис) по функциям мне полностью подходит,
раз скрипт подходит, то и используй его.
SQL-injection отфильтровываются перед использованием обращения к БД, так что куки здесь не причем.

-~{}~ 20.11.07 15:42:

а что за сканер - можно ссылку?
 

AmdY

Пью пиво
Команда форума
Кстати, сначала воспользовался бы error_reporting(E_ALL), затем почитать про PDO или воспользоваться готовым классом для работы с БД.
 

Pigmeich

Новичок
И? Что такого? Никто не пользуется сканнерами для обнаружения уязвимостей? Все исключительно только ручками?
Обычно глазами (визуальная отладка кода - есть такая фича).
А что за сканер такой навороченный?

The Cookie variable PHPSESSID=10ce1790d624d22c15412fed3cf95517; auth has been set to %00' - в общем по-разному и всегда задействованы PHPSESSID и auth
Вот только сегодня посоветовал одному парню сменить сообщение "No answer" на "No output" - последнее и соответсвует истинному выводу.
Это я все к тому, что понять логику работы скрипта бывает очень сложно.

Куки через PHPSESSID - это стандартный механизм сессий в PHP и сам по себе возможностей для SQL Injection предостовлять не должен - он вообще, в норме с SQL не общается.
 

Фанат

oncle terrible
Команда форума
zeta
мне кажется, что в этой функции нет смысла.
я бы понял, если бы она возвращала
"'".mysql_real_escape_string($str)."'"
тогда она могла бы использоваться для автоматического отделенияч строк от чисел.
а в таком виде получается, что она либо не нужна, и её легко можно заменить на mysql_real_escape_string($str), если кавычки ставятся в запросе.

если же кавычки не ставятся, то это не защита, а дыра.
 

zeta

Новичок
Автор оригинала: Pigmeich
он вообще, в норме с SQL не общается.
В строке setcookie("auth",$m[id])
$m[id]) - это же значение из базы, через select получается. Но не могу я его отфильтровать почему-то :(

Во всех других случаях нормально фильтрация проходит, по крайней мере сканнер перестал показывать уязвимость (хотя раньше были и другие уязвимости). Теперь осталась только эта и с ней я ничего не могу сделать. Ведь id у меня используется и в других местах - фильтрую - и там оно уязвимости не дает, а вот именно в том месте, где куки устанавливаются - показывает уязвимость, хоть убей.

насчет "'".mysql_real_escape_string($str)."'" - я вообще-то и так делала и эдак, все равно в куках уязвимость показывает и все. Я уж думала плюнуть на этот сканер и на все, что он показывает, но с другой стороны - другие-то уязвимости, которые он показывал, я закрыла и он перестал их показывать, значит реально есть уязвимость, раз он так уж на ней настаивает :)


PS: сканнер Acunetix Web Vulnerability Scanner

PS: я понимаю, что очень сложно вот так вот помочь, практически наугад, но все-таки... Может кто сталкивался с таким
 

cDLEON

Онанист РНРСlub
Во первых. Нужно не куку ескейпить, а вставлять в запрос заискейпенную строку.
Во вторых. Сколько куку не ескейпь, всё равно найдётся тот, кто зискейпит её так, как надо ему 8)
 

kruglov

Новичок
Может кто сталкивался с таким
Вы не понимаете, функция mysql_real_escape_string вкупе с кавычками вокруг гарантирует от SQL-инъекций. Все.

Вам глупый сканер удовлетворять надо или сайт делать защищенный, я что-то не пойму?

Знаете, чем хороший программист отличается от нехорошего? Хороший знает внутренние механизмы и может сам делать выводы о работоспособности решения. А нехороший полагается на сканеры, готовые решения и прочие штучки, надеясь, что они за него думать будут.
 

zeta

Новичок
Во вторых. Сколько куку не ескейпь, всё равно найдётся тот, кто зискейпит её так, как надо ему 8)
Это я понимаю, как говорится, было бы желание. Но все ж таки хочется тому, кому это надо, затруднить исполнение его желания :)


Во первых. Нужно не куку ескейпить, а вставлять в запрос заискейпенную строку.
Вот в этом месте можно поподробнее? Примерчик какой-нибудь аналогичный, ссылку поконкретнее (не вообще про setcookie, а поближе к делу) а может строчку кода - вообще было бы замеЧтательно. Потому что я ж перед запросом ставлю фильтрацию и через функцию пыталась и через intval а не помогает...

Еще я пыталась вставить фильтрацию в саму строчку setcookie("auth",$m[id]) - но тогда у меня куки перестают работать :(.

В общем ясно понимаю, что делаю что-то не то и не так - но что конкретно...

-~{}~ 20.11.07 19:04:

А нехороший полагается на сканеры, готовые решения и прочие штучки, надеясь, что они за него думать будут.
Я, видимо, нехороший, да и честно говоря, вообще не программист :), в общем, не волшебник, а только учусь...

Но игнорировать сканнер я не могу :(. Меня наоборот учили - если даже сканнер говорит, что все хорошо, это не повод радоваться - надо еще ручками проверить. А уж если даже сканнер говорит, что есть уязвимость... Я бы, конечно, хотела рукой махнуть, сказать, ладно мол, пусть себе болтает...но...
 

kruglov

Новичок
Ну, у вас есть 2 пути: продолжать волноваться или разобраться в сути.
 

AmdY

Пью пиво
Команда форума
Я бы, конечно, хотела рукой махнуть, сказать, ладно мол, пусть себе болтает...
Ну если такой порядочный программист, то включи нотисы, а то $m[id] - режет глаз.
 

Фанат

oncle terrible
Команда форума
а можно узнать - что конкнретно пишет сканнер?
конкретно, а не "что-то вроде".
 

zeta

Новичок
Ну если такой порядочный программист
А порядочный-непорядочный тут вообще при чем?

А вот еще такой вопрос: если смотреть через сканер - то сканер показывает страницу с кучей ошибок, которые в общем-то и ведут, насколько я понимаю к уязвимости.

А если подставлять запрос, который предлагает сканер непосредственно в адресную строку со всеми его вариантами уязвимости - сайт регирует адекватно вроде бы, то есть показывает - нет таких данных.

Ну, то есть он показывает - например, запрос, где auth=%00'
и показывает реакцию сайта -
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in и так далее...

Но если я сама в работающий сайт подставляю тот же запрос - то, в общем, все нормально вроде на сайте, никаких ошибок он не выдает, а дает нормальный ответ, что мол нет таких данных, как и был запрограммирован...

Может этот сканер горячится малость, говоря, что это уязвимости? Там, где уязвимость, насколько я понимаю, сайт должен реагировать неадекватно... Хотя я в этих уязвимостях НИЧЕГО не понимаю...

-~{}~ 21.11.07 00:01:

а можно узнать - что конкнретно пишет сканнер?
конкретно, а не "что-то вроде".
Много чего пишет :)

Например

Attack details
The Cookie variable PHPSESSID=10ce1790d624d22c15412fed3cf95517; auth has been set to %2527.

и показывает

HTML response


Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in и так далее

И так куча всяких вариантов:

The Cookie variable PHPSESSID=10ce1790d624d22c15412fed3cf95517; auth=deleted

и соответственно html response показывает.
 

dimagolov

Новичок
Автор оригинала: zeta
... Хотя я в этих уязвимостях НИЧЕГО не понимаю...
У Вас есть 3 пути.
1. Таки понять что происходит
2. Нанять человека который понимает
3. Оставить все как есть и не брать дурного в голову

для п.1 надо приложить самостоятельные усилия для того чтобы основательно понять что такое php, как он работает, что есть уязвимости и почему и как делать так, чтобы их не было.

да, еще мне кажется, что шансы что сайт поломают украв пароль ftp трояном гараздо выше, чем что его поломают через уязвимости в скриптах.
 

cDLEON

Онанист РНРСlub
Примерчик какой-нибудь аналогичный, ссылку поконкретнее (не вообще про setcookie, а поближе к делу) а может строчку кода - вообще было бы замеЧтательно. Потому что я ж перед запросом ставлю фильтрацию и через функцию пыталась и через intval а не помогает...
А можно примерчеГ кода по-конкретнее ?
Да так что бы ближе к делу? А то я вижу только setcookie
 

Фанат

oncle terrible
Команда форума
А если подставлять запрос, который предлагает сканер непосредственно в адресную строку со всеми его вариантами уязвимости - сайт регирует адекватно вроде бы, то есть показывает - нет таких данных.

Ну, то есть он показывает - например, запрос, где auth=%00'
и показывает реакцию сайта -
Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in и так далее...
оп-па
девушка. вообще-то, все наоборот.
supplied argument is not a valid MySQL result resource - это не переводится "нет таких данных"! это значит, что этот замечательный прекрасный бесплатный скрипт написан кривыми руками.
Но если я сама в работающий сайт подставляю тот же запрос
о господи. куда подставляешь? В КУКИ?!
 

zeta

Новичок
Я понимаю, что supplied argument is not a valid MySQL result resource не переводится "нет таких данных". С английским у меня слава богу все в порядке :)
Просто эти ошибки вылезают только если при помощи сканера симулировать атаку на сервер. Если подставлять корректные запросы - все работает прекрасно.

о господи. куда подставляешь? В КУКИ?!
Не надо так эмоционально :)
В адресную строку подставляю данные, которые предлагает сканер, чтобы показать уязвимость...

Есть совершенно стандартные способы узнать есть ли на сайте уязвимость или нет и один из этих способов - подставить в адресную строку вместо корректного запроса, ожидаемого программой - некорректный. Если сайт среагирует неадекватно - значит уязвимость есть и можно копать дальше.
Я ничего не выдумываю и не изобретаю. Я пользуюсь известным сканером, который специально под это заточен, который признан одним из лучших и он дает совершенно четкие инструкции, как симулировать атаку на сайт и показывает ее последствия. Просто он показывает эти последствия в окошке программы и в этом окошке эти последствия визуально видны, а на самом сайте, реальном - нет.

этот замечательный прекрасный бесплатный скрипт написан кривыми руками.
увы, скрипт небесплатный, а довольно-таки дорогой и что самое обидное :) - неварезныйи, даже не паблик, как я уже писала, а сделанный на заказ под определенные запросы. Однако сайт поддержки, где его заказывали, перестал работать, email и аська нерабочие. В общем, понятно, что контора, заказавшая этот скрипт, попала, но им этот скрипт нужен, у них на нем база больше 30000 юзеров, статей немерянное количество (но базу-то я бы как-нибудь конвертировала :) ) и много чего другого и функционал, которого я не могу больше нигде найти. Обидно переходить на скрипт с меньшим функционалом, учитывая, что весь он задействован... да и не согласятся они...Пока они сидели тихо-мирно - никому были не нужны их никто и не трогал, опасности того, что кто-то так уж сильно захочет их взломать не было, а теперь ситуация немного изменилась...

А то я вижу только setcookie
Так я и пишу с самого начала, что каким-то образом именно это строка задействована в уязвимости. Если я ее меняю - прописываю, например, не переменную, а конкретное значение - то уязвимости сканер не показывает. То есть уязвимо значение $m[id], которое берется из базы данных, оно почему-то не отфильтровывается. Весь вопрос изначально стоял в том - почему оно не отфильтровывается? В каком меесте его нужно отфильтровать? Перед select? Но не работает...

И сканер пишет именно

The Cookie variable is vulnerable

Раньше, когда я только начала проверять этот скрипт, он выдавал много уязвимостей, и записи были вида: The POST variable is vulnerable также. Я отфильтровала все соединения с базой и теперь записей вида
The POST variable он уже не выдает, а выдает только вот эту одну уязвимость The Cookie variable is vulnerable
 
Статус
В этой теме нельзя размещать новые ответы.
Сверху