Многовато у тебя сообщений для таких высказываний Опасны не данные, опасно не правильное использование этих данных.
А данные виноваты в sql-иньекции? Пользуя prеpared statements не нужно ничего экранировать. повторюсь в который раз, экранировать нужно: 1. служебные символы! в строковых значениях, перед вставкой их в базу данных. 2. служебные символы HTML в строковых значениях, перед выводом их на страницу, и только в том случае, если нужно отобразить код этого HTML, а не его самого. А у ТС спутаны понятия экранирования данных и валидации пользовательского ввода. ЭТо совершенно разные задачи, и это необходимо осознать. Именно осознать.
Vladson я смотрю ты заядлый философ? маловато у тебя сообщений для таких рассуждений. обычно это зовется "буквоедство". реально есть неиспользуемые передаваемые данные? они кому то нужны? нужны настолько, чтобы продолжать язвить тут? все данные, которые используются в скрипте - нужны, все приходящие извне данные используемые в скрипте - опасны. опасны именно тем, что они используются. и для их использования в каких нибудь запросах данные нужно обработать до безопасного уровня. для особых буквоежек уточню - я не указываю где именно нужно их обработать, но при использовании в каком нибудь запросе - это необходимо. будем спорить? Горбунов Олег да. обработаешь - не будут виноваты. не обработаешь - будут виноваты. необработанные данные позволят выполнить неожидаемый запрос. Есть возражения? Господа, если кому то понравилась фраза "Опасных данных не бывает", кто то нашел в ней глубокий философский смысл и его покорила понтовость ее изложения - спешу огорчить, эта фраза будет верной "употребленной в надлежащем месте в надлежащее время". Нет причины повторять ее везде и всюду, напыщено тыкать на ссылку на страничку, где автор попытался выразить свою мысль. Речь идет о приходящих данных, в которых может быть что угодно, и данные эти где то используются. Если мне позволят, несколько слов по той "мега статье". это бред, сенсей. буддисткое нравоучение не удалось. Получается, если вместо ожидаемого цифрового (для буквоежек - целочисленного, безнакового) значение индекса столбца нам пришло буквенное - значит это значение нужно по назначению применить в другом столбце, в котором употребляются буквы? %) Данные фильтровать при вставке в запрос нужно, всегда. Вот так, однозначно и понятно, а не писать ту мудрость востока.
Andrey5555 тебе надо проверить, являются ли переданые данные числом, целочисленным, беззнаковым? я выше дал функцию, она не фильтрует, она проверяет.
Ок, взломай скрипт PHP: <?php $asd = $_GET['asd']; ?> В скрипте приходят данные (и они используются, они хранятся в переменной $asd) вперёд и с песней... Значит их не надо использовать вообще !!! (ибо пришли не данные а бред какой-то)
Vladson Но если же эту переменную передать в базу данных, и изменять переменную в адресной строке, то можно получить все. Поетому перед использованием в бд надо фильтровать.
Мда... и счас будет очередных две страницы пусто-порожних обсуждений. это зовется терминология. И именно для этого она нужна - если бы все это понимали, в этой теме было бы всего два сообщения. А то и вообще, вопроса бы не возникло.
Vladson прочитай пожалуйста полностью мое сообщение: твой скрипт выполняет работу используя приходящие данные? я думаю эту фразу следует написать именно там, касаемо пришедших данных неподходящего типа. если тип подходит (текст), то нужно фильтровать в запросах ВСЕ данные. Всегда. И будет счастье. (PS я сказал "в запросах", если что...) пришли именно данные, а в них бред. Это если уж так захотелось посоревноваться в остроумии Горбунов Олег нет, это именно буквоедство. ты неиcпользуемые в скрипте данные (например отправили еще одно поле через POST, или параметр в GET) используешь? замечу, что я специально указал, что все опасно, что используется. Вот такая глубокая философски мысль %)
Почему я должен если ты не читаешь моих ? Потому что из GET/POST приходит string и в запросы и на экран тоже должен был бы идти string (если бы в РНР была строгая типизация) проверять числа надо is_numeric а тексты в зависимости от того куда идут прогонять соответствующими функциями подробнее в http://phpfaq.ru/slashes второй раз даю уже ссылку, прочти наконец, а не просто пробегись глазами. mysql_real_escape_string и htmlspecialchars НЕ ФИЛЬТРУЕТ ДАННЫЕ они просто приводят их в тот вид котором СУБД/браузер их правильно поймут, сами данные останутся теми-же а опасными они никогда не были, опасно их нелогичное использование (такое-же как есть арбуз целиком не разрезая на кусочки)
Бред Я думаю, мы все понимаем под использованием не простое хранение значения во временной переменной, а употребление для какого-либо вывода (база, файл, скрин). И хотя в общем и целом я согласен с тем, что сами по себе данные опасны быть не могут никак, но если иметь в виду то, что предполагается их использование, то скрытая угроза появляется именно в них, следовательно, они и опасны. Убираешь угрозу (ака фильтруешь данные), и данные становятся безопасными. Хотя, конечно, безопасность ПО заключается в его логике, а, значит, и в применении по назначению... Но на определенных (начальных) этапах (обучения) подобные суждения лишь создают путаницу. Если мыслить более просто (а это часто спасает, ибо чем проще, тем надежнее), то опасны данные. IMHO
Andrey5555 Я кажется понял в чем пробема. Пробема в том, что ты хочешь написать функцию для обработки данных на все случаи жизни Этого делать не надо, после получения данных ничего с ними не делай. Перед отправкой данных в SQL-запросе, обрабатывай mysql_real_escape_string. Перед выводом на экран из БД - htmlspecialchars, сам понимаешь в каком случае.
Вы возможно, а я в свою очередь не думаю а знаю. Значит плохо читал, читал бы хорошо пришёл бы к выводу что ещё до создания этого топика Потому что умный человек учится на чужих ошибках, и только дурак на своих. Я научился на примере WordPress, там сделали такую функцию которая фильтрует просто таки всё что только можно. Итог прост от дыр это не избавило, а вот неудобств просто массу добавило...
Vladson вот и я говорю - буквоедство. советую почитать, что же такое "фильтр". желательно абстрактное определение. адьез.
А мы с Олегом говорим терминология, сейчас ты научишь его фильтровать данные escape-ом, а завтра он будет учить людей вообще strip_tags-ом, а всё потому что ты вбил ему в голову фигуральное выражение которое он воспримет буквально.
Ага, особенно прфесиональная терминология видна в отрывке Браузер не html коды поймет неправильно, так же как СУБД инъекцию не поймет. Это не терминология, это педантичность.
Это опечатка с моей стороны, поймёт он её правильно, но не так как этого хотел создатель скрипта Важная часть в программировании, без неё делаются продукты типа винды (дырявые и противные)
Тему закрываю, пошел откровенный флуд. Жаль, что некоторые участники, силясь доказать свое превосходство над другими, помешали человеку разобратся в немаловажной для дальнейшего изучения проблеме.