Если в параметрах сервера установлена переменная get magic quotes в true., то использовать функцию mysql_real_escape_string не стоит, поскольку появятся в
строке дублирующие слеши.
А чем вредны дублирующие слеши, кроме искажения данных?
и почему приведенная переменную к целочисленному типу не следует обрамлять апострофами
Спустя 20 минут, 27 секунд (21.06.2010 - 13:32) Kuzya написал(а):
Если в параметрах сервера установлена переменная get magic quotes в true., то использовать функцию mysql_real_escape_string не стоитКак раз стоит, Только предварительно очистив данные от результатов действия магических кавычек.
Тут дело как с addslashes - не правильно экранируются символы в разных редких кодировках.
А mysql_real_escape_string сделает всё верно.
А чем вредны дублирующие слеши, кроме искажения данных?
Ничем.
и почему приведенная переменную к целочисленному типу не следует обрамлять апострофами
Не "не следует", а "можно". Тут даже всё наоборот. Вообще все данные рекомендуется обрамлять кавычками, какого бы типа они не были. Просто многие СУБД допускают подстановку числовых данных без кавычек.
Спустя 13 минут, 16 секунд (21.06.2010 - 13:45) артем23 написал(а):
В отношении XSS
При использовании strip_tags возможен обман этой функции и лучше использвать htmlspecialchars все верно?
<title><?php echo strip_tags($pagename?></title>
или
<title><?php echo htmlspecialchars($pagename, ENT_QUOTES); ?></title>
При использовании strip_tags возможен обман этой функции и лучше использвать htmlspecialchars все верно?
Спустя 31 минута, 7 секунд (21.06.2010 - 14:16) Kuzya написал(а):
htmlspecialchars обезвреживает все специальные HTML-символы.
А strip_tags только вырезает теги. Логично что первое предпочтительнее
А strip_tags только вырезает теги. Логично что первое предпочтительнее
Спустя 1 час, 2 минуты, 56 секунд (21.06.2010 - 15:19) артем23 написал(а):
тогда получается, что функцию mysql_real_escape_string следует использовать в любом случае, и в том, когда установлены магические кавычки, и не установлены.
Когда кавычки установлены, и местная локаль одно байтовая, то просто будут лишние слеши и при SELECT это не важно, результат выборки просто не определен. А если локаль многобайтовая, то защита магическими кавычками со строны сервера не справяться, зато подстрахует функция mysql_real_escape_string
Рассуждения верны?
Когда кавычки установлены, и местная локаль одно байтовая, то просто будут лишние слеши и при SELECT это не важно, результат выборки просто не определен. А если локаль многобайтовая, то защита магическими кавычками со строны сервера не справяться, зато подстрахует функция mysql_real_escape_string
Рассуждения верны?
Спустя 3 часа, 51 минута, 23 секунды (21.06.2010 - 19:11) неадекват написал(а):
не не верны. Данные искажаются при включенных кавычках - это минус. Лучше удалять слеши и ставить mysql_real_escape_string.
Можно оставить и авто кавычки, только вопрос в кодировках. Многобайтовыцх или однобаййтовых. Нужно тогда устанавливать локаль на запрос и все ок. Какую локаль я не знаю))
Можно оставить и авто кавычки, только вопрос в кодировках. Многобайтовыцх или однобаййтовых. Нужно тогда устанавливать локаль на запрос и все ок. Какую локаль я не знаю))
Спустя 58 минут, 53 секунды (21.06.2010 - 20:10) Kuzya написал(а):
Как раз стоит, Только предварительно очистив данные от результатов действия магических кавычек.
Спустя 50 минут, 41 секунда (21.06.2010 - 21:00) неадекват написал(а):
теперь мне интересно, а чего там с кодировками? и где почитать?
Спустя 11 часов, 34 минуты, 14 секунд (22.06.2010 - 08:35) Kuzya написал(а):
Можно вот тут:
http://phpforum.ru/index.php?showtopic=29171
Подробнее тут
http://raz0r.name/vulnerabilities/sql-inek...i-i-addslashes/
http://phpforum.ru/index.php?showtopic=29171
Подробнее тут
http://raz0r.name/vulnerabilities/sql-inek...i-i-addslashes/
Спустя 1 час, 11 минут, 5 секунд (22.06.2010 - 09:46) Kuzya написал(а):
Идентификатор соединения с БД не забывайте передавать mysql_r_e_s()