Идея насчёт безопасности.

[mahoro]

Базу не ломали, говоришь?

Имхо, на коммерческих хостингах как правило ломают именно скрипты клиента, и чаще всего делая SQL инъекции.

Если у тебя MySQL, то проверь, работают ли в ней конструкции вида select something into outfille 'filename', если есть возможность - выруби (или пожалуйся в саппорт). И еще неплохо бы как-нибудь отключить возможность выполнения UNION запросов, хотя не уверен, что это возможно в принципе.

Можно сделать фильтрацию GET и POST значений как-нибудь централизованно. Ну, пройтись по всем параметрам и отшить юзера, если встречаются какие-нибудь сигнатуры sql инъекции, вроде тех же outfile, union, char(. Или вырезать их незаметно Могу заверить, жизнь хакерам это осложнит, если, конечно, нет багов в формах аутентификации..
Может быть, на сайте GET переменные используются только для передачи каких-нибудь ID и проч, тогда можно ограничить длину переменных.
На одном сайте я за ненадобность отключил возможность закачивать файлы в конфигурации PHP, это тоже хакерам не подарок..

И, конечно, надо проверить права доступа и пассворды..

 

[kruglov]

применение [m]mysql_real_escape_string[/m] делает ненужным отмену unionов, ограничение длины GET-переменных и прочую ерунду.

 

[mahoro]

ну, это само собой, но это не панацея.

Если переменная, полученная от пользователя в SQL запросе не заключена в кавычки, то даже после mysql_real_escape_string простор для творчества очень широк. Есть возможность сделать тот же UNION или простейшее "or 1=1". А если ограничить длину переменной, скажем, 10 символами, то особо не разбежишься. С $_POST сложнее, конечно..

-~{}~ 04.10.05 04:12:

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

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

 

[Фанат]

Хехе, kruglov, к вопросу о формулировках =)
написал вместо "составление корректных с точки зрения синтаксиса запросов" просто ссылку на описание mysql_real_escape_string - и получил ещё порцию гениальных рассуждений от великого сыщика.
вот, теперь будешь знать, что случится, если кавычки не поставить, хи-хи =)

 

[kruglov]

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

Чтобы не попасть под машину, можно передвигаться только по собственной квартире (отрезать первые 10 символов), а можно все время смотреть по сторонам и выбирать для перехода хорошо просматриваемые места (escape_string и кавычки)

Чужой мутный форум может состоять из полусотни файлов, использовать сотни передаваемых переменных. Как вы собираетесь защитить его, не разбираясь в логике работы?

Вот в одном популярном форуме (IPB, кажется) была уязвимость, что injection поступал из подмененного номера сессии, хранящейся в куке. Разработчик подумал - ну уж куку я контролирую, я знаю, что пишу туда. И не зафильтровал. И кирдык.

 

[Фанат]

что интересно - по дефолтной ссылке на mysql_real_escape_string действительно вываливается мизерный текстик, в отличие от оригинала - http://php.rinet.ru/manual/en/function.mysql-real-escape-string.php после которого уже никто не сможет вякнуть, что не панацея.

 

[mahoro]

Смишно-смишно Yahoo находит сотни сайтов с выводом sql ошибок на странице. Кто-то же делает эти ошибки, верно? Значит, все, что было здесь сказано имеет какую-либо ценность.

Чужой мутный форум может состоять из полусотни файлов, использовать сотни передаваемых переменных. Как вы собираетесь защитить его, не разбираясь в логике работы?

Централизованная фильтрация пользовательских данных.. GET переменных, которые могут быть длинней 10..16..N символов мало, для них можно создать отдельные правила. POST проверить на сигнатуры инъекций, в COOKIES скорей всего хранится максимум 5 переменных, проверить их валидность не проблема. Можно попробовать включить magic_quotes_gpc. Это все очень просто сделать, а безопасность чужих мутных скриптов этим можно повысить значительно, не разбираясь в них и не сильно усложняя процедуру их обновления.

Например, это решило бы недавние проблемы в phpBB, когда там не фильтровались переменные search_id или highlight. Достаточно было просто скобки порезать..

Хотя, при наличии времени, я бы переписал по-своему все "чужие мутные скрипты"

 

[Steamroller]

mahoro, это ты так mod_security повторно изобретешь.

 

[mahoro]

4Steamroller, Эхх.. вот так всегда


Да, эти способы от XSS не спасут, а идей как это исправить, вобщем-то, не много..

 

[Steamroller]

Автор оригинала: mahoro
Да, эти способы от XSS не спасут, а идей как это исправить, вобщем-то, не много..

Да принцип тот же, что у XSS, что у других инъекций, так что более-менее стандартный набор правил для mod_security разом всё закрывает. Правда если перестараться, некоторые скрипты могут перестать работать, но это уже довольно просто исправляется.

 

[kruglov]

mahoro

> Не разбираясь в них

>GET переменных, которые могут быть длинней 10..16..N символов мало, для них можно создать отдельные правила.
Для этого надо изучить смысл каждой переменной

>POST проверить на сигнатуры инъекций
На слово union? А это слово в обычной человеческой речи на форуме употребляться не может?

>Можно попробовать включить magic_quotes_gpc.
А потом разбираться, с чего вдруг \"кавычки\" начали записываться в базу и как теперь это бороть.

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

-~{}~ 05.10.05 01:30:

p.s. Вот скажите мне все-таки, какое такое преимущество имеют урезание длины GET-переменных до 10 символов, распознавание "сигнатуры инъекций" перед четким правилом - лезешь в базу - кавычки и escape_string?

p.s. Что-то мы как-то от культуры программирования перешли к латанию чужих "мутных" скриптов...

 

[mahoro]

>Для этого надо изучить смысл каждой переменной

Ну, это громко сказано.. По крайней мере можно не лезть в код и не смотреть, что с ней делается..

>POST проверить на сигнатуры инъекций
На слово union? А это слово в обычной человеческой речи на форуме употребляться не может?

От специфики зависит.. Если это не технический форум, то заменить во фразе "union select" букву "o" на аналогичную русскую допустимо.. то же со встроенными функциями, там достаточно пробела между именем и скобками..

А потом разбираться, с чего вдруг \"кавычки\" начали записываться в базу и как теперь это бороть.

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

p.s. Вот скажите мне все-таки, какое такое преимущество имеют урезание длины GET-переменных до 10 символов, распознавание "сигнатуры инъекций" перед четким правилом - лезешь в базу - кавычки и escape_string?

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

p.s. Что-то мы как-то от культуры программирования перешли к латанию чужих "мутных" скриптов...

Дык.. исходная задача была именно такой.. Жаль только что подробностей никаких нет и мы обсуждаем сферических коней в вакууме..

 

[master_x]

mahoro

Дык.. исходная задача была именно такой.. Жаль только что подробностей никаких нет и мы обсуждаем сферических коней в вакууме..

да тут не сферические кони а галиматья, особенно с твоей стороны.

 

[kruglov]

mahoro

Находим в чужом мутном скрипте все mysql_query - и чик-чик туда все что нужно - тоже проделывается "над чужим скриптом быстро и это принесет ощутимый результат сразу же".

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

 

[Royal Flash]

Yourick

По поводу infobox`a - там в панеле управления можно выставить, сколько времени хранить лог-файл апача, в котором видно все ip, которые посещали сайт, а самое главное, что эти ip делали на этом сайте: какую страницу запрашивали, какие переменные посылали. Этого вполне достаточно, чтобы обнаружить, через что залез злоумышленик. После чего заклеить дыру, и поискать похожие по скриптам.

 

[mahoro]

kruglov
Вобщем, обсуждать это надо применительно к какой-либо конкретной задаче, для которой можно совершенно точно сказать, какое решение лучше и почему.

Мне приходилось работать с phpbb, и конкретно там понадобилось добавить около 15 строк, чтобы из GET и COOKIES переменных вырезать скобки и слово union и проверить длину. Плюс еще cut-paste из какого-то FAQ проверку HTTP_REFERER.
Все, опасную sql/php инъекцию теперь сделать на порядок сложнее.

А просмотреть все запросы там нереально, их очень много, и там почти всегда пишется sql_query($sql).

Я думаю, что-нибудь подобное можно проделать и с многими другими скриптами.

Да, пора здесь точку поставить, кажется..

master_x
Очень ценный комментарий. Иногда лучше жевать, чем говорить.