Когда наиболее рекомендуемое время для использования mysql_real_escape_string ()

Question

Я на самом деле новичок в использовании этой функции ... и использовал preg_replace и добавляет косую черту перед его поиском.

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

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

Ура всем!

Answer 1

В идеале вы должны никогда использовать его, потому что Параметризованные запросы (через PDO или mysqli ) являются правильным предотвратить внедрение SQL.

Answer 2

Вы, вероятно, должны использовать mysqli_real_escape_string или PDO со связанными параметрами вместо этого. Основное использование любого из них - экранировать символы, такие как одинарные и двойные кавычки. Как правило, это предотвращает SQL-инъекцию .

Answer 3

Наиболее рекомендуемое время для использования mysql_real_escape_string (): всякий раз, когда вы помещаете данные в базу данных. Если вы воспринимаете ввод данных из любого места (с веб-страницы, из базы данных, из веб-службы) как враждебную атаку, которую вы должны защищать и фильтровать от проблем, то вы не ошибетесь

Первые несколько раз проделайте трудный путь, затем используйте фреймворк (я использую ZendFramework) или, по крайней мере, его часть, например Zend_DB, чтобы облегчить себе задачу.

Для безошибочного метода безопасности - сервер, который нельзя разбить на:

1. отключить аппарат от сети
2. отключить машину от питания
3. положить машину в сейф
4. брось в Марианский желоб
5. пост охранника.

Примечание: на данный момент его полезность не гарантируется. это очень безопасно, хотя Не на 100%, но настолько хорошо, насколько это возможно.

И продолжайте изучать безопасность и лучшие практики.

Answer 4

mysql_real_escape_string(magic_quotes_gpc() ? strip_slashes($variable) : $variable)

Если вы настаиваете на том, чтобы не использовать mysqli или PDO, то всегда.

Answer 5

Пожалуйста, посмотрите этот ответ на похожие вопросы некоторое время назад.

По сути, безопасность намного шире, чем просто предотвращение SQL-инъекций. Кроме того, всякий раз, когда вы запускаете запрос к базе данных, содержащей какие-либо динамические данные, существует опасность внедрения SQL. Наконец, лучше использовать подготовленные операторы с библиотекой PDO, чем использовать mysql_real_escape_string ().

1) Безопасность strip_tags () и mysqli_real_escape_string ()

Answer 6

Практически в любое время в данных могут присутствовать символы, которые могут испортить запрос, особенно кавычка и одинарная кавычка. Есть некоторые расширенные символы, которые зависят от вашей текущей кодировки символов MySQL, которая могла бы сделать это тоже, поэтому вы хотите использовать один в mysql вместо addlashes ().

Answer 7

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

Answer 8

Лучше всего анализировать содержимое как данные, а не как код (никогда не выполнять код). Например, JSON (Javascript) - это очень простой способ собрать данные с сервера на клиенте, но вы никогда не должны его выполнять. Вы должны проанализировать данные с помощью регулярного выражения, чтобы убедиться, что они верны и содержат только данные.

При этом внедрение SQL обычно происходит, когда вы принимаете данные формы в формате html. Ключ должен был бы проверить зарезервированные слова SQL, которые вызывают проблему, а именно '; (одинарная кавычка, точка с запятой.) Вы можете легко создать список зарезервированных слов и запустить их через выражение RegEx (вероятно, на сервере jQuery есть что-то приятное или C #). Я уверен, что PHP тоже мог бы легко это сделать. Глаголы CRUD (create retrieve update и delete) приятно искать, но не забывайте о хранимых процедурах SQL на стороне сервера, которые уже существуют для того, чтобы что-то делать или, что еще хуже, выполнять операторы SQL (динамический SQL). Вы можете кодировать «escape» символы, если вам не нужно использовать их и за пределами веб-страницы.