2010-02-01 2 views
2

У меня есть простое текстовое поле в форме, и я хочу безопасно хранить специальные символы в базе данных после POST или GET, и я использую приведенный ниже код. $ text = mysql_real_escape_string (htmlspecialchars_decode (stripslashes (trim ($ _ GET ["text"])), ENT_QUOTES));Текст ввода и специальные символы и MySQL

Когда я прочитал текст из базы данных и поместил его в текстовое значение, я использую приведенный выше код.

$text=htmlspecialchars($text_from_DB,ENT_QUOTES,'UTF-8',false); 
<input type="text" value="<?=$text?>" /> 

Я пытаюсь сохранить в базе данных без каких-либо специальных символов (то есть я не хочу писать в поле базы данных " или ')

На самом деле при записи в базу данных делать htmlspecialchars_decode к тексту ,

При написании текстового поля формы введите htmlspecialchars в текст.

Это лучший подход для безопасного написания специальных символов в базе данных?

ответ

3

У вас есть правильная идея сохранить текст в базе данных как необработанный. Не уверен, для чего предназначен весь объект сущности HTML; вам не нужно делать это для вставки базы данных.

[Единственная причина, по которой я могу думать о том, почему вы можете попытаться сущ.-Декодировать входящий вход для базы данных, будет, если вы обнаружите, что вы получаете ссылки на символы, например &#352;, в свой ввод формы. Если это происходит, это происходит потому, что пользователь вводит символы, которые не существуют в кодировке, используемой страницей с формой. Эта форма кодирования является полностью фиктивной, потому что тогда вы не можете различать пользователя, набрав Š и буквально набрав &#352;! Вам следует избегать этого, используя кодировку UTF-8 для всех ваших страниц и контента, так как все возможные символы соответствуют этой кодировке.]

Строки в вашем скрипте всегда должны быть сырым текстом без экранирования.Это означает, что вы ничего не делаете с ними до тех пор, пока вы не выведете их в контекст, который не является текстовым. Таким образом, для ввода их в SQL строку:

$category= trim($_POST['category']); 
mysql_query("SELECT * FROM things WHERE category='".mysql_real_escape_string($category)."'"); 

(или использовать параметризацию запросов, чтобы избежать необходимости вручную избежать его.) При вводе контента в HTML:

<input type="text" name="category" value="<?php echo htmlspecialchars($category); ?>" /> 

(вы можете определить вспомогательную функцию с более коротким именем, например function h($s) { echo htmlspecialchars($s, ENT_QUOTES); }, если вы хотите сократить количество ввода, которое вы должны делать в шаблонах.)

И ... это в значительной степени. Вам не нужно обрабатывать строки, которые выходят из базы данных, поскольку они уже являются исходными строками. Вам не нужно обрабатывать входные строки (*), кроме какой-либо конкретной проверки поля приложения, которую вы хотите сделать.

*: ну, за исключением, если magic_quotes_gpc включен, в этом случае вы либо должны stripslashes() все, что приходит в от GET/записи/печенье, или, мой привилегированного вариант, просто сразу не в состоянии:

if (get_magic_quotes_gpc()) 
    die(
     'Magic quotes are turned on. They are utterly bogus and no-one should use them. '. 
     'Turn them off, you idiot, or I refuse to run. So there!' 
    ); 
+0

Я думаю, что пример категории y, написанный выше, в первый раз, когда пользовательские критерии теста будут записаны в базу данных как raw.When отредактируйте категорию (потому что htmlspecialchars ($ category)) будут записаны как теги ' s, но я предпочитаю писать как raw.Correct me if worng.Thanks для вашего ответа – ntan

+1

'htmlspecialchars ($ category)' будет * записан * в HTML как 'test ' s categories', yes. Но это всего лишь кодировка для чтения браузером; фактическое значение полученного поля формы в DOM является «категориями тестов», и именно эта незакодированная строка вы вернетесь в свою '$ _POST ['category']' при отправке формы. – bobince

+0

Итак, когда я хочу выполнить поиск по таблицам, я должен преобразовать пользовательский ввод с помощью htmlspecialchars или нет. Я имею в виду, что политика написания в DB должна быть ONE. Я не могу записать 10 записей с необработанным форматом и 10 других с htmlspecialchars.I предпочитают необработанный формат – ntan

1

Когда вы пишете в БД, используйте htmlentities но когда вы читаете назад, используйте html_entity_decode функцию.

Как Замечание, если вы ищете какую-то безопасность, то для строки использовать mysql_real_escape_string и для чисел используют intval.

0

Лучший подход к безопасной записи в БД заключается в использовании уровня абстракции PDO и использовании подготовленных операторов.

http://www.php.net/manual/en/intro.pdo.php

Хороший учебник (я узнал из этого) является

http://www.phpro.org/tutorials/Introduction-to-PHP-PDO.html

Однако, вы, возможно, придется переписать много вашего сайта только для осуществления этого. Но это, без сомнения, самый элегантный способ, чем использовать все эти функции. Кроме того, подготовленные заявления становятся де-факто сейчас. Другим преимуществом этого является то, что вам не нужно переписывать свои запросы, если вы переключаетесь на другую базу данных (например, от MySQL до PostgreSQL). Но я бы сказал, подумайте об этом, если вы планируете масштабировать свой сайт.

+0

Я знаком с PDO, но наш сервер не поддерживает его. – ntan

1

Я хотел бы отметить несколько вещей:

  1. нет ничего плохого в экономии символов, как ' и " в базе данных, SQL инъекции только вопрос манипуляций со строками, они actuall y не имеет ничего общего с SQL или базами данных - проблема только полагается на то, как построена строка запроса. Если вы хотите написать свои собственные запросы (не рекомендуется), вам не нужно кодировать каждый апостроф или двойную цитату: просто откройте их один раз, чтобы создать безопасную строку и сохранить их в базе данных. Лучший подход использует PDO, как указан, или с помощью mysqli extension, которая позволяет запросы с подготовленными операторами

  2. htmlentities() и аналогичные функции должны быть использованы при передаче данных в качестве вывода в браузер, а не для кодирования данных, которые будут храниться в базе данных по крайней мере по двум причинам: во-первых, это бесполезно, DB не заботится о html-сущностях, он просто содержит данные; во-вторых, вы должны всегда обрабатывать данные, поступающие из базы данных, как потенциально небезопасные, поэтому вы должны сохранить его в «сыром» формате и закодировать его при использовании его.

+0

Полностью согласен с вами, но наш сервер не поддерживает PDO – ntan

+0

Вот почему я упомянул также mysqli. Остальные пункты все еще стоят. –

Смежные вопросы