возврат каретки после использования mysql_real_escape_string()

Я заканчиваю свой веб-сайт и хочу сделать его очень безопасным для SQL-инъекций. Большая часть этого проходит и использует mysql_real_escape_string() для любого потенциального пользовательского ввода.

Это нормально для большинства вещей, где мне просто нужно использовать «полосные косые черты», чтобы вернуть исходный контент для отображения на странице. Однако я не могу вернуть возврат каретки.

Есть несколько мест, где пользователи могут отправлять части с возвратом каретки (например, сообщения, начинающиеся, например, «Привет, Джон», а затем дважды возвращающиеся к основному сообщению). Как я могу это исправить? Stripslashes просто возвращает сообщение с rnrn, что нехорошо.

В качестве примера (я пытаюсь проверить все возможные входные данные).

Этот текст:

Once upon a time there was a guy named "steve" or 'john' or backslash (\)

Then, two lines later, he left.

Сохраняется так в базе данных SQL:

Once upon a time there was a guy named \"steve\" or \'john\' or backslash (\\)\r\n\r\nThen, two lines later, he left.

И использование полосовых косых черт оставляет это так (обратите внимание, что я делаю следующее, чтобы напечатать его в html - :

Once upon a time there was a guy named "steve" or 'john' or backslash (\)rnrnThen, two lines later, he left.

Я пробовал nl2br, но он почему-то ничего не делает. Буду рад любым мыслям здесь, большое спасибо!


person cschippe    schedule 25.01.2013    source источник
comment
Возможно, вам следует прекратить использовать mysql_ функции.   -  person Kermit    schedule 26.01.2013
comment
Когда база данных сохраняет косые черты, ваш вызов mysql_real_escape_string кажется избыточным.   -  person Philipp    schedule 26.01.2013
comment
@SalmanA, не могли бы вы немного рассказать об этом? Я новичок в кодировании и не совсем уверен, как бы я это сделал, сохраняя при этом защиту от SQL-инъекций.   -  person cschippe    schedule 26.01.2013
comment
@njk: это, вероятно, как-то связано с волшебными кавычками.   -  person Salman A    schedule 26.01.2013
comment
@cschippe: можете ли вы опубликовать пример того, как вы очищаете и храните данные. И проверьте, включено ли magic_quotes.   -  person Salman A    schedule 26.01.2013
comment
Это не проблема с волшебными кавычками, так как косая черта выше заставляет все выглядеть правильно, за исключением возврата каретки. Это что-то о возврате каретки и возможности вывести их до того, как я нанесу косую черту на переднем конце при печати на странице.   -  person cschippe    schedule 26.01.2013
comment
Я делаю mysql_real_escape_string(stripslashes($_POST[userinput])) чтобы поместить его в базу данных. В этом примере база данных содержит: Жил-был парень по имени \steve\ или \'john\' или обратная косая черта (\)\r\n\r\nЗатем, двумя строками позже, он ушел. Это не то, как он сохраняется, если у вас нет лучшего способа, который безопасен от SQL-инъекций, но также поддерживает возврат.   -  person cschippe    schedule 26.01.2013
comment
Ваши данные буквально содержат \", \', \r, \n и т. д.?   -  person Salman A    schedule 26.01.2013
comment
Исходный ввод был таким, как описано выше, без обратной косой черты. Я избежал его, чтобы сделать SQL-запросы безопасными, и при этом оставил его в базе данных SQL с обратной косой чертой, например \", \', \r, \n. Теперь хитрость заключается в том, что когда я печатаю эти данные на странице, чтобы \r and \n были возвратами, для которых они предназначены.   -  person cschippe    schedule 26.01.2013


Ответы (1)


Есть много вещей, перепутанных.

  1. mysql_real_escape_string() не имеет ничего общего ни с sql-инъекциями, ни с пользовательским вводом.
  2. не должно быть безусловных стрипов, а только специально.
  3. При правильном использовании экранирование не попадает в базу данных. НЕТ необходимости в полосках при извлечении.
  4. если у вас есть косые черты в базе данных, у вас чрезмерное экранирование. либо ваш код дважды добавляет косую черту, либо вы используете заполнители, что делает экранирование бесполезным
person Your Common Sense    schedule 25.01.2013
comment
Хорошо, что бы вы посоветовали в таком случае? Как я могу быть уверен, что SQL-инъекций не будет? И как тогда вернуть обратно на страницу? - person cschippe; 26.01.2013