Forum Webscript.Ru
Программирование => PHP => Тема начата: Alexandr от 28 Августа 2002, 13:53:41
-
Что лучше сделать с данными пришедшими от пользователя для занесения, например в БД?
Ну там, напр.,
$user_data=trim($user_data);
$user_data=str_replace("\\t", " ", $user_data);
$user_data=str_replace("\\r","", $user_data);
$user_data=preg_replace("/ +/"," ", $user_data);//2- пробела => на 1
$user_data=stripslashes($user_data);
А ещё что мона сделать?
Я ещё такое встречал:
// доп. функция для удаления опасных сиволов
function pregtrim($str) {
return preg_replace("/[^\\x20-\\xFF]/","",@strval($str));
}
Что эт ещё за опасные символы.
-
ИМХО самое главное - это addslashes();
А остальное зависит от типа данных и того что с ними будут делать.
С текстом я обычно так поступаю:
$text = addslashes(strip_tags(trim(substr($text,0 , 255))));
По желанию можно еще wordwrap() добавить. Еще в определенных случаях либо preg_replace() удалять символы которые считаешь не нужными.
Еще вариант - делать проверку данных и выводить ошибки пользователю:
if (empty($text)) {
$error = "text is empty";
} elseif (preg_match("/[^A-Za-z0-9_]/",$text)) {
$error = "Bad symbols";
} ....
-
ИМХО самое главное - это addslashes();
А нахрена слэшнутые данные в базе хранить?
-
если пхп автоматом не слешит - то использовать stripslashes, иначе он нафиг не нужен.
Для переменных типа текст неплохо еще trim() использовать.
Для чисел intval()
Переменные желательно принимать непосредственно из нужного массива, например $HTTP_POST_VARS
И вообще лучше обработать директорию через .htaccess со строками
php_flag magic_quotes_gpc on
php_flag register_globals off
-
если пхп автоматом не слешит - то использовать stripslashes
stripslashes - Вродь убирает слэши.php_flag magic_quotes_gpc on
php_flag register_globals off
А эт у мя уж есть.
-
А нахрена слэшнутые данные в базе хранить?
читай про SQL-injections
-
короче, горячие эстонские парни.
if(get_magic_quotes_gpc()) addslashes($data);
Макс, персонально для тебя. Никаких оправданий хранению слешнутых данных нет и быть не может. Хранить надо данные как есть. Поэтому слешить ТОЛЬКО один раз. Больше - портить, меньше - гадить.
-
RomikChef
Хранить надо данные как есть. Поэтому слешить ТОЛЬКО один раз.
Непонял, хранить как есть или все-таки слешить один раз?
Никаких оправданий хранению слешнутых данных нет и быть не может.
Блин, я тут себя начинаю полным идиотом чувствовать. Данные слешить нужно (согласен, один раз - про большее я и не говорил).
-
stripslashes - Вродь убирает слэши
Блин, вернее наоборот, добавлять слеши. Думал одно, а написал другое :)
-
А нахрена слэшнутые данные в базе хранить?
Чтобы тебя не "поломали", а то кто-нибудь впишит в переменную свой код на ПХП и тогда...
-
Tronyx
Только код не на PHP впишет, а на SQL... Не путайте...
-
Чтобы тебя не "поломали", а то кто-нибудь впишит в переменную свой код на ПХП и тогда
И объясни мне, каким образом меня так поломают ?
-
читай про SQL-injections
Да, интересная статейка.
Но мона ведь всё-таки не слэшить данные, а напр. так
$user_data=str_replace("\'", \'"\', $user_data);//1-ную ковычку на 2-ю
-
Alexandr
Ну вот скажем запрос у меня
$name=$HTTP_POST_VARS[\'name\'];
$SQL="SELECT * FROM table WHERE name=\'".$name."\'";
?>
Покажи мне на примере, как меня могут поломать !
-
Во-первых, слово кАвычка пишется через "а".
Я бы не обращал внимания если бы эта ошибка на стала разражающе распростаненной, как "извЕните".
Во-вторых, Саша, тебя никто не учил уважению к чужой информации?
Как будет смотреться фамилия Д"Артаньян?
Или JS код, в котором заменят одинарную на двойную?
Да и вообще - ЗАЧЕМ что-то менять, если есть стандартная функция защиты? ТЕМ БОЛЕЕ, что одинарной кавычкой набор спецсимволов не ограничивается. В общем, дурацкая идея.
Специально для тебя ремарка. Я не наезжаю на тебя лично. Я вообще против тебя ничего не имею. Но не считаю себя обязанным промолчать только потому, что у тебя ко мне неадекватное отношение и скорее всего мой ответ вызовет флейм.
Кстати, а ошибку у меня никто не заметил :-)
Конечно же
if(!get_magic_quotes_gpc()) addslashes($data);
Макс, если сделать addslashes, то данные ХРАНЯТСЯ как есть. ;-)
Троникс, хранить - действительно - совершенно не обязательно, и наоборот - вредно. А вот при составлении SQL запроса экранировать спецсимволы - ОБЯЗАТЕЛЬНО. Иначе может возникнуть как непреднамеренная ошибка, так и эти пресловутые инжекции.
-
Стек, кроме запросов SELECT
есть еще запросы UPDATE и даже DELETE
В селекте действительно - много не наломаешь.
Разве что - инфу, которая тебе не положена, можно поглядеть. Но опять же, дело не только в инжекциях, а в банальной защите от ошибок.
-
Alexandr
Если вернуться к первоначальному вопросу.
собственно, у него три части.
1. Защита SQL запроса - его уже обсосали дочиста.
2. Защита HTML и JS. Во-первых - только, если надо, во-вторых, варианта два - либо стрипать теги, либо заменять.
Лично я обычно кладу в базу как есть, а на выходе заменяю < и > эквивалентами.
htmlspecialchars не помешает - как минимум при выводе данных в поле формы.
3. Свои собственные соображения.
Вот в приведенном тобой примере кто-то вырезает любые символы, которые не буквы, я так думаю. Это его личная идея.
при хранении данных гостевой книги в файле, я, например, заменяю перевод строки на
.
-
Кстати, я только сейчас заметил, что у тебя стоит
$user_data=stripslashes($user_data);
Не забудь убрать.
-
Стек, кроме запросов SELECT
есть еще запросы UPDATE и даже DELETE
В селекте действительно - много не наломаешь.
Ок, хорошо, пускай будет
$SQL="DELETE FROM table WHERE name=\'".$name."\'";
Если у меня $name слашится - то каким образом меня могут поламать ?
-
Никаким.
Об этом и речь.
-
А если не слешится, то и Select\'ом поломать можно.
Конечно сложнее, и знать чего-то надо, но все же:
Допустим запрос:
$query="select from `table` where id=\'$id\' ";
А я пишу id равным:
$id="1\';delete from `table` "...
Все! таблица `table` потеряна...
-
Гмм... ясно, просто запутался спорах о слешировании. Думал что мне доказывают, что данные для базы надо еще раз дополнительно слешить, не обращая внимание на
php_flag magic_quotes_gpc on
Дмитрий Попов
Незнаю как к другим базам, но mysql_query разве научился понимать две sql команды в одном запросе ? Имхо delete from `table` просто не будет выполнятся. Таким образом разве что and id like \'%%\' проталкивать.
Да и то, при таких запросах надо уже четко знать структуру базы.
-
Совершенно верно.
-
Ууупс... сторомозил :-)... бывает.
-
Троникс, хранить - действительно - совершенно не обязательно, и наоборот - вредно.
А я разве такое говорил? Посмотри внимательней мой пост.
-
Помоему все уже просто запутались.
-
[off]
RomikChef
потому, что у тебя ко мне неадекватное отношение
Ромик, боже упаси.
Мне, наоборот, твои посты нравятся. Особенно как ты с новичками. Или там про макароны, ложки и вилки... rulezzzz.
Просто порой начало топика не читаешь и пишешь ответы.
Вобщем всё ок.
[/off]
Вобщем буду делать следующим образом:
function clean_str(&$user_data){
$user_data=trim($user_data);
$user_data=str_replace("\\t", " ", $user_data);
$user_data=str_replace("\\r","", $user_data);
$user_data=preg_replace("/ +/"," ", $user_data);//2- пробела => на 1
$user_data=stripslashes($user_data);
$user_data=preg_replace("/[^\\x20-\\xFF]/","",@strval($str));
//Правда никто ничего про ЭТО не сказал.
}
Если надо вставить в SQL, то так
mysql_query("INSERT INTO _t VALUES (NULL, ".addslashes(clean_str($user_data)).")");
Если на мыло послать, то
маил($address, $subj, clean_str($user_data));
Если на экран, то
echo htmlspecialchars(clean_str($user_data));
Вот собственно мой вывод.
-
Alexandr
Или там про макароны, ложки и вилки... rulezzzz.
:):):):):):):):):):)