Ну дык речь идет про текст ведь, т.е. про данные в кавычках Без кавычек, разумеется. Если данные должны быть int, тогда intval() в помощь.
дык твой запрос не будет выполнен, т.к. ошибка синтаксиса а если выборку по id делать то можно intval() применить
может лучше вместо stripslashes(); $var = str_replace("\\", "", $var); ? тоха, мне нужны не числовые параметры. а для числовых, конечно, intval() + проверка на знак =)
чтониб вроде.. PHP: function xek($string) { if (get_magic_quotes_gpc()) { $string = stripslashes($string); } if (!is_numeric($string)) { $string = "'" . mysql_real_escape_string($string) . "'"; } return htmlspecialchars($string); } а потом это уже в запрос кидать.. ну еще в довесок можно проверять на a-zA-Z0-9, хотя в идеале хватит только его. если точно знаешь что другого не будет в строке
если не число, то mysql_real_escape_strin и добавляем кавычки чтобы в запрос передать в кавычках уже строку) хотя прав, не обязательно, но почему бы и нет
htmlspecialchars спасёт от XSS PHP: htmlspecialchars('<script>alert("xss")</script>'); , mysql_escape_string спасёт от скули PHP: mysql_query("SELECT test FROM test WHERE test2 = '".mysql_escape_string("1'+order+by+100")."'"); , чтобы проинклудить файл нужно проверять его существование на сервере PHP: if(file_exists('./'.$_GET['file'])) { include($_GET['file']); } (просто примеры), а лучше фильтровать символы. PHP: preg_replace('|[^a-z0-9]|i', NULL, $_GET['test']);
Не надо заморачиваться , все предельно просто . Все передаваемые значения должны быть в ковычках , это сразу спасает от 99 процентов проблем да и mysql проглотит этот запрос быстрее , прежде чем применить PHP: addslashes() надо проверить включены ли magic_quotes_gpc PHP: get_magic_quote_gpc четко выставить кодировку , желательно отфильтровать данные на спецсимволы PHP: $text = trim ( $text );$text = trim ( $text , "\x00..\x1F" ); htmlspecialchars надо использовать с ENT_QUOTES иначе одинарная ковычка не будет фильтроваться PHP: htmlspecialchars( $text , ENT_QUOTES); В случае запроса-поиска надо экранировать %,_ . Главное правило - не доверять всем входящим от юзера данным , точнее всему тому на что может повлиять юзер , но не показывать этому юзеру свое недоверие
Ну и ну, ребята. Столько сообщений, и нет ни одного грамотного ответа. Надо бы подождать nerezus'а, он знает ответ. Если ждать его лень (новый год как никак), бегом искать его статью о защите от "SQL инъекций". Там есть ответ на вопрос, который мучает здесь вас всех, а именно: "Как защитить любое веб приложение от любой атаки, отличной от атаки грубой силой?" Ни много ни мало. Формулировку вам придется натянуть на его "статью" самостоятельно. Кстати, любой (даже низкой степени заинтересованности) студент любого ВУЗа любого IT факультета знает ответ на этот вопрос! Задумайтесь об этом, задумайтесь о том, чему вы научились, столько времени потратив на прочтение этого форума!? Отдельная просьба Зеленому Мишке и всем прочим модераторам, хотя бы в честь Нового Года не трогать это сообщение, тем более, что в действительности, это первый ответ в этой теме, все остальное можно удалить!
как я понял, прочитав http://forum.antichat.ru/thread30641.html при вводе (+заключаем в кавычки). 1. если число, intval(); 2. если строка, mysql_escape_string(); +заключаем в кавычки. 3. при выводе htmlspecialchars(); все? PHP: INSERT INTO table (login, pass) VALUES ('".$_POST["login"]."','".$_POST["pass"]."'); PHP: SELECT pass FROM table WHERE login '".$_POST["login"]."'; если кавычки (') стоят в самом запросе, то можно вообще ничего не экранировать?
Третий пункт выкидываай из своего понимания. Проверка на существование (isset()) и выборка целого числа в первом случае (если кто то пихает херню с -, то можно добавить bcmod()), во втором случае окружение кавычками и экранирование.
почему? а <скрипт> итп при выводе? на существование чего? не понял. что еще нужно экранировать после mysql_escape_string();?
PHP: < > " ' % ; ) ( & + Так же смотри не происходить ли автоматическое преобразование символов. Не забываем про фокус замены символа пробела на PHP: /**/ Надежней пропускать только то что разрешено, чем блокировать "черные списки". По возможности использовать HttpOnly-cookies. Параноикам поможет шифрование cookie. При нападение с помощью TRACE метода претензии к хостеру. PHP: TraceEnable off
Да что вы тут развели дискуссию? Все повторяют сообщения, которые тут уже написаны. Для проверки любых данных на sql инъекцию, xss или инклуд, способов не так уж и много! Для проверки sql строк достаточно mysql_real_escape_string() Все числовые параметры sql стоит писать через intval() Для защиты от xss вполне хватит функции htmlspecialchars() либо htmlentities() Проверка на кириллицу вот - $str=preg_replace('/[^а-я]/i','',$str); Если нужна проверка на инклуд. Во первых, инклудить лучше файлы с префиксом, например include('./inc/inc_'.$_GET['page']); Во вторых, лучше приписывать расширение к файлу и желательно, чтобы это расширение не было '.php' . include('./inc/inc_'.$_GET['page'].'.inc'); В третьих, существование файла надо проверять и фильтровать точки . $_GET['page']=str_replace('.','',$_GET['page']); file_exists('./inc/inc_'.$_GET['page'].'.inc')?include('./inc/inc_'.$_GET['page'].'.inc'):echo('неверный файл'); На все вопросы автора ответили уже
наверное правильнее регуляркой проверять на допустимые символы, чем вырезать все недопустимые, так ведь?
