mysql_real_escape_string и html_special_chars достаточно?

Question

Этот вопрос часто задают, но я до сих пор не нашел прямого ответа на stackoverflow.Достаточно ли этих двух функций или нет?В интернете много противоречивых комментариев: «Да, хорошо?», «Нет, никогда не пользуетесь им». Другие говорят, что используют PDO, чего я не понимаю. Я просто новичок в PHP, поэтому я неЯ не могу полностью понять все тонкости безопасности. Я пытался прочитать и понять следующее, но многие не имеют для меня особого смысла.

http://ha.ckers.org/xss.html
Do htmlspecialcharsи mysql_real_escape_string защищают мой код PHP от инъекций?

Что если я использую preg_replace для удаления нежелательных символов?

Я невероятно запутался и не знаю, с чего начать.

РЕДАКТИРОВАТЬ: Может ли кто-нибудь, пожалуйста, также порекомендовать, как я понимаю понимание подготовленных заявлений (при условии, что это лучший вариант).

Answer 1

Сэм, если вы храните входные данные в базе данных, чтобы избежать внедрения SQL и XSS, тогда этих двух функций достаточно.Если вы храните пароли, вы должны зашифровать пароли с помощью одностороннего шифрования (то есть они не могут быть расшифрованы).

Позвольте мне расширить мой ответ: во-первых, SQL-инъекция - это метод, при котором вредоносный кодПользователь попытается изменить ваш оператор SQL, чтобы он выполнял свою волю.Например, допустим, у вас есть форма для входа.Вставив одно из следующих значений в незащищенную форму, я смогу войти в первую учетную запись, не зная имени пользователя или пароля:

' or 1=1 -- 

Существует много версий вышеупомянутого внедрения.Давайте рассмотрим, что он делает с SQL, выполняемым в базе данных:

PHP: mysql_query ("ВЫБЕРИТЕ * ОТ ПОЛЬЗОВАТЕЛЕЙ, ГДЕ username = '". $ Username. "' AND password = '". $ Password. "'; ");

При выполнении вышеизложенного в базу данных отправляется следующий SQL:

SELECT * FROM users WHERE username='' or 1=1-- ' AND password='' or 1=1--';

Эффективная часть этого SQL: SELECT * FROM users WHERE username= '' или 1 = 1

, поскольку двойная черта (с пробелом после) является комментарием, удаляющим остальную часть утверждения.

Теперь это дает злоумышленнику доступ.Используя экранирующую функцию, такую ​​как mysql_real_escape_string, вы можете экранировать содержимое, чтобы в базу данных отправлялось следующее:

SELECT * FROM users WHERE username='\' or 1=1-- ' AND password='\' or 1=1--';

, которое теперь экранирует кавычки, создавая предполагаемые строки, только эти строки.

Теперь давайте рассмотрим некоторые XSS.Другой злоумышленник хотел бы изменить макет страницы.Хорошо известной атакой XSS была атака Facespace на Facebook еще в 2005 году. Это включает вставку необработанного HTML в формы.База данных сохранит необработанный HTML, а затем будет отображаться пользователям.Злонамеренный пользователь может вставить некоторый javascript с использованием тега script, который может сделать все, что может сделать javascript!

Этого можно избежать путем преобразования <и> в соответственно.Для этого вы используете функцию html_special_chars.

Этого должно быть достаточно для обеспечения нормального содержимого сайта.Однако пароли - это отдельная история.

Для паролей вы также должны зашифровать пароль.Для этого рекомендуется использовать функцию шифрования PHP.

Однако, если пароль зашифрован и сохранен в базе данных в качестве зашифрованного пароля, как вы можете расшифровать его, чтобы убедиться в его правильности?Простой ответ - вы не расшифруете это.СОВЕТ: Пароль всегда шифруется с одним и тем же значением.

Вы думали: «Мы можем зашифровать пароль, когда пользователь входит в систему и сравнить его с паролем в базе данных», вы правы ...

Answer 2

Если вы спрашиваете о безопасности, есть одна проблема с mysql_real_escape_string.

Эта функция абсолютно не связана с безопасностью.

Всякий раз, когда вам нужно сбежать, он вам нужен, несмотря на «безопасность», но только потому, что это требуется синтаксисом SQL. А там, где он вам не нужен, побег не поможет вам даже немного.

Использование этой функции простое: когда вы должны использовать строку в кавычках в запросе, вы должны экранировать ее содержимое. Не из-за мнимых «злонамеренных пользователей», а просто для того, чтобы избежать этих кавычек, которые использовались для разделения строки. Это чрезвычайно простое правило, но все же крайне ошибочное в PHP.

Это просто функция, связанная с синтаксисом, а не связанная с безопасностью.

В зависимости от этой функции в вопросах безопасности, полагая, что она «защитит вашу базу данных от злонамеренных пользователей» БУДЕТ привести вас к инъекции.

Вывод, который вы можете сделать сами:
Нет, этой функции недостаточно .

Подготовленные заявления тоже не серебряная пуля. Он покрывает вашу спину только для половины возможных случаев.

Answer 3

Зависит от того, для чего вы используете ввод и куда он направляется.

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

Следование указанным вами руководствам и другим руководствам - отличное начало. но тогда каждая ваша дезинфекция потребует нетривиального времени и памяти для выполнения.

так что все зависит от того, для чего вы используете ввод и куда он идет.

mysql_real_escape_string и html_special_chars - хорошие утилиты, но вы не должны зависеть только от них, и они также не всегда нужны.

не расстраивайтесь, так как даже зрелые и хорошо запрограммированные сайты должны идти в ногу с последними в xss и другими атаками. веселая игра в кошки-мышки.

Одно место, которое вы можете начать, - это фреймворк, мне нравится codeignitor. пройти их классы безопасности, чтобы увидеть, как они справляются с этим.

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