Это действительно просто:
- Чтобы избежать внедрения SQL,
mysql_real_escape_string
свои значения перед объединением их в запрос SQL или используйте параметризованные запросы, которые не страдают от искаженных строк.. - Чтобы избежать проблем с XSS и / или испортить HTML, HTML экранирует ваши значения, прежде чем подключать их в контекст HTML.
- JSON экранирует их в контексте JSON, CSV экранирует их в CSVконтекст и т. п.
Все это одна и та же проблема, правда.В качестве очень простого примера, чтобы получить строку "test"
(я хочу, чтобы кавычки были частью строки), я не могу написать строковый литерал $foo = ""test""
.Я должен избежать кавычек внутри кавычек, чтобы прояснить, какие кавычки должны заканчиваться строкой, а какие являются частью строки: $foo = "\"test\""
.
SQL-инъекция, проблемы с XSS и испорченный HTML - все простовариант этого.
Чтобы вставить значение, содержащее кавычки, в запрос, у вас есть та же проблема, что и выше:
$comment = "\"foo\""; // comment is "foo", including quotes
$query = 'INSERT INTO `db` (`comment`) VALUES ("' . $comment . '")';
// INSERT INTO `db` (`comment`) VALUES (""foo"")
В лучшем случае выдает неверный синтаксис, а в худшем - атаки с использованием SQL-инъекций.Использование mysql_real_escape_string
позволяет избежать этого:
$query = 'INSERT INTO `db` (`comment`) VALUES ("' . mysql_real_escape_string($comment) . '")';
// INSERT INTO `db` (`comment`) VALUES ("\"foo\"")
Экранирование HTML в точности такое же, только с различными синтаксическими проблемами.
Вам нужно только экранировать значения в правильном контексте, используя правильный метод.Чтобы экранировать значения для HTML, используйте htmlentities
.Делайте это в то время, когда это необходимо.Не преждевременно и не экранируйте свои значения, только примените соответствующую функцию escape в нужном контексте в нужное время.