Код (Text): foreach ($_POST as $key => $value) { $_POST[$key] = mysql_real_escape_string($value); } foreach ($_GET as $key => $value) { $_GET[$key] = mysql_real_escape_string($value); } Этот код можно считать универсальным,против SQL-инъекции?
DbSimple +плейсхолдеры. Я полюбил плейсхолдеры в свое время, даже на с++ класс запилил для мускула, чтоб с плейсхолдерами работать =))). Удобно и безопасно
Для обычных SQL Injection, если база данных MySQL, и работать только c $_GET и $_POST - будет достаточно, но существуют ещё и более хитрые методы, под лозунгом Advanced SQL Injection - там уже функция не поможет, там нужна правильная логика обработки данных. Приведу небольшой пример: Пришла строка в 20 символов: 123456789'1234567890 Происходит преобразование функцией mysql_real_escape_string Получаем строку 123456789\'1234567890 Пусть у Вас есть функция обрезание строки до 10 символов. В результате Вы ожидали получить 123456789', а получили 123456789\ - что в дальнейшем может привести ко взлому.
Это редкость, и в основном таким можно воспользоваться имея сорцы, ибо найти такой инъект оч нелегко) Добавлено спустя 14 минут 21 секунду: Тут числа для примера вроде как), суть не в этом)
Тогда получается лучше использовать функции , типа Код (Text): function replacer ($text) { $text=str_replace(" ",' ',$text); $text=str_replace(">",'>',$text); $text=str_replace("<",'<',$text); $text=str_replace("\"",'"',$text); $text=preg_replace("/\n\n/",'<p>',$text); $text=preg_replace("/\n/",'<br>',$text); ... для исключения возможных вариантов инъекций
да суть в том что если общение с бд идет через не utf а толи в винде толи в латин1, то при посылке какого-то там утф символа он проходит через эскепинг, но внутре запроса на стороне сервера превращается в кавычку А где - не помню
проблема кодировок не только в sql inj выражается). Просто если правильная настройка бд + mysql_real_escape_string 100% ограждают от инъектов).
Однозначного лучшего решения видимо не существует.Одни настоятельно советуют эскейпить,в другом месте читаешь Код (Text): Дело в том, что mysql_real_escape_string() не предназначена для защиты от инъекций. Вообще. Это функция, которая нужна для форматирования строк. Причём даже для этой задачи её одной недостаточно - форматирование включает в себя два действия - экранирование и заключение в кавычки.phpfaq.ru .К кому податься - к умным или красивым )
Просто загуглить "мультибайтовые кодировки sql injection" и будет куча инфы) Добавлено спустя 3 минуты: Лучшее решение - везде юзать utf-8+экранирование+фильтрация. Добавлено спустя 51 секунду: хотя экранирование и фильтрацию можно объединить в один термин%).
тут нет противоречия. экранирование строки нужно, чтобы случайно не вывалиться за кавычки. а от инъекций нужна защита от умышленного протыкания дыр в защите. просто обычно у всех столько дыр, что искать недокументированные никому не приходится. т.е. если вы строки экранируете - то вас если будут ломать, то с умом. А если не экранируете, то вы можете сами себе напортить даже случайно. Это как замок на двери. Добавлено спустя 47 секунд: экрация? фильтрирование?
Короч можно сказать что в последнее время оно сливается в один термин), тк фильтрация не актуальна, а самый действенный способ--экранирование, но по привычке все-же иногда вылетает птичко, которое не поймаешь, по крайней мере у меня)
О боже мой! Неужели "экрирование"? Добавлено спустя 46 секунд: Требуется специалист для улучшения экрации. Фильтристов просьба не беспокоить.
Ахахах Я тебя не понимаю xD Добавлено спустя 53 секунды: Просто или я дурак?) Может я не так понимаю что такое экранирование, а что такое фильтрация?)
Вы бы это еще "утрированием" назвали. Надежный способ-это тот способ который будет проверяться на равенство, остальное это mysql_real_escape_string(). nixx, кто такие эти ваши phpfaq.ru. Кому вы верите вообще... Вам источник в помощь php.net. Никаких других. php.net/manual/ru/function.mysql-real-escape-string.php Но-это не значит, что вы должны везде и подрят писать там эту функцию, ибо возможен факт просто на проверку и приведения типа данных... Не нужно при работе с базой использовать как некоторые делают addslashes, очень много где заметил, возможен обход фильтра, ибо не учитывает кодировку. От всяких XSS если есть вхождение html тегов, пользуйтесь htmlspecialchars для их преобразования в html сущности. А увеличивать нагрузку на базу всякими голимыми фильтрами не имеет смысла. Это то, что касается базы данных. Конечно лучше взять отсеять все не безопасные символы. Не изобретайте велосипеды. Если вы новичок и очень сильно далеки (не выставляйте свои сайты в публичный доступ, возможен риск атак и взломов, потому, что зачастую начинающие не понимают, что нужно для защиты, как нагородят, понакопируют, понавставляют функций и разных каких-то скриптов непонятно вообще, что и не зная как работает), используйте готовые фреймворки. Если чисто для себя тренируетесь, то тут лучше конечно взять и когда пишите проверки и фильтры, то нужно смотреть, что проверяется и вводится, чтобы понять как работает.
это хорошая иллюстрация к какая-та фильтрация может убрать из строки результат экранирования, а экранирование - приписать то, что удалила фильтрация