Не существует «одного-единственного» способа фильтрации ввода, как вы описали, так как ни один ввод не является недействительным или даже обязательно вредоносным. Это полностью то, что вы делаете с помощью ввода.
Например, предположим, у вас есть текст в $_GET['field']
, и вы собираетесь составить SQL-запрос. Вам нужно экранировать значение, используя mysql_real_escape_string()
(для MySQL, конечно), например:
$sql = "INSERT INTO some_table (some_field) VALUES ('" . mysql_real_escape_string($_GET['field']) . "')";
Это экранирование абсолютно необходимо для ввода, которое вы используете в запросе SQL. После применения, как вы видите здесь, даже злонамеренный ввод данных от хакера не окажет вредного воздействия на вашу базу данных.
Однако эта функция бесполезна и прямолинейна. Неправильно использовать, если вы включаете $_GET['field]
в некоторые выходные данные HTML со своей страницы. В этом случае функция htmlspecialchars()
полезна. Вы можете сделать что-то вроде:
echo "<p>Your comments were: " . htmlspecialchars($_GET['field']) . "</p>";
Оба эти примера довольно безопасны от "хакерских вводов". Вы не будете вставлять вредоносные данные в вашу базу данных или в ваш HTML. Тем не менее, обратите внимание, что две формы выхода - это совершенно разные функции, каждая из которых подходит для своего использования.
Напротив, представьте, что вы пытались «проверить» входные данные для этих двух применений одновременно. Вы, конечно, не можете разрешить <
или >
символов, так как они могут быть частью вредоносной атаки HTML, такой как межсайтовый скриптинг. Таким образом, посетители, которые хотят написать «Я думаю 1 <3», будут забиты. Точно так же нельзя было допускать кавычки из-за боязни вредоносных атак SQL-инъекций, поэтому бедный «Майлз О'Брайен» никогда не сможет заполнить вашу форму! </p>
Правильный ввод экранирование очень легко сделать, так как вы используете его в разных контекстах (это часто даже проще, чем проверка ввода!), Но результаты намного лучше.