Статья про защиту от SQL-inj Статья про защиту от SQL-inj Что такое SQL-inj? Сам знаешь. Иначе бы не читал. Так что сиди и читай дальше Как проводятся SQL-inj? Вбивай в гугл и ищи статьи всяких разных хакеров. Если искать не умеешь - то дальше не читай, все равно не поймешь. Как защититься? Что, нагуглил статей? Может и про защиту написано? Какие-нибудь леменги вроде Михуила Фленова. фильтровать советуют? Шли нах. Ничего, повторяю еще раз для альтернативно-одаренных: НИЧЕГО фильтровать не надо. СУБД - на то она и СУБД, а не херня какая-то, чтобы нормально любые данные принимать. Наша задача - просто правильно эти данные преподнести. Защищаться надо так(применительно к PHP и mysql): 1) Если поле в базе числовое, то: (int) (ну или intval()). Можно по модулю взять при использовании в LIMIT, но это не секурити-дырка. 2) Если текстовое, то просто mysql_real_escape_string() 3) Всякие magic quotes и подобные затычки отключены. Кто не отключил - ССЗБ(что это означает - смотрите на LOR'е) И ВСЕ! Больше ничего не надо. Ибо запрос испортить левыми данными нельзя. Повторю еще раз: НИКАКИХ ФИЛЬТРАЦИЙ. LIKE/RLIKE/AGAINST/etc - это частный случай, и рассматривается отдельно. Примера не будет. Если не понял - значит это тебе не надо. ORM Что это такое, написано здесь: http://ru.wikipedia.org/wiki/ORM Защита от SQL-inj - это побочный результат применения данной технологии. Что касательно защиты от XSS, то никаким образом к БД это не относится. Так что те, кто хотел это все объединить в 1 функцию(да к тому же и с проверкой) - идите лесом. Это кардинально разные вещи и они друг к другу не относятся. И да пребудет с вами сила(не со всеми)! nerezus, 5.01.07-2.01.08
хм довольно странный, даже не статья, а пост. В защиту magic quotes скажу что если ставишь двиг, не собственно ручно написаный, смысла отключать не вижу, больше риск.
Я сначала хотел что-то из строчек восьми написать ) Но написал больше. Причина - тема http://forum.antichat.ru/thread30506.html Ну а чтьо касается magic quotes - то нефиг юзать кривые движки
intval() например при -12 выводит -12. Это не дырка? А вот насчет mysql_real_escape_string() это ты в точку! Нхрена писать невпупенные функции когда можно одной строчкой обойтись.
Это все ясно, только ты не раскрыл тему=) Например при Selectе с Like надо экранировать еще пару символов, хотя логика очень здравая и самому ни раз мысль такая приходила при прочтении описаний разного рода фильтраций =)
Чтобы защитится от SQL Injection надо, прежде всего надо распределять по его видам. К примеру, если мы хотим получить целое число (int) надо чтобы шла проверка что это число и правда целое. Это можно осуществить с помощью функнии IsNumeric в таком виде: Так же надо чтобы не показывались ошибки, которые приводят к взлому сайта. Есть полно путей сделать это, но помойму лучше всего это осуществить с помощью того, что есть ошибка работа не прекратилась.
error_reporing(0); magic_quotes on и числа передаваемые базе тоже обрамляем ковычками типо и хакеры прутся полем
Мой метод защиты: Если вы передаете только текст и числа в скрипты к примеру: index.php?modules=news&id=1 то вполне подойдет данный код: PHP: function var_chek($var,$col){ $var = substr($var, 0, $col); $var = preg_replace("/[^\w\x7F-\xFF\s]/", "", $var); $good = ereg_replace(" +", " ", $var); $good = strip_tags($good); return $good; } $modules=var_chek($modules,10); $id=var_chek($id,5); Данный код не только удалит все спец символы из передаваемых строк но и обрезает по длинне, ни один XSS или SQL inj... не пройдет через этот фильтр.
так действительно делать не надо. Лучшим средством будет типизирование параметров - явно прописать в скрипте имена параметров и их типы и соответствующе их парсить. Если int - делать intval(), если string - делать mysql_escape_string. При выводе всех значений на экран обрамлять в htmlspecialchars, а резать это при передаче в БД - маразм. Тут я на 100% согласен с nerezus'ом
Обязательно off. Т.к. иначе будет двойное экранирование. И вообще magic_quotes, register_globals и т.д. отменили в PHP6, чтобы криворукие недокодеры не юзали их ) Зачем?
