Как вы очищаете данные в $ _GET -переменных с помощью PHP?
Вы не очищаете данные в $ _GET. Это распространенный подход в сценариях PHP, но он совершенно неверен *.
Все ваши переменные должны оставаться в виде простого текста до момента, когда вы встраиваете их в строку другого типа. Не существует единственной формы экранирования или «очистки», которая охватывала бы все возможные типы строк, в которые вы могли бы встраивать свои значения.
Итак, если вы встраиваете строку в SQL-запрос, вам нужно ее избежать при выходе:
$sql= "SELECT * FROM accounts WHERE username='".pg_escape_string($_GET['username'])."'";
А если вы выплевываете строку в HTML, вам нужно ее избежать:
Cannot log in as <?php echo(htmlspecialchars($_GET['username'], ENT_QUOTES)) ?>.
Если вы выполнили оба эти экранирующих шага в массиве $ _GET в начале, как рекомендуют люди, которые не знают, что они делают:
$_GET['username']= htmlspecialchars(pg_escape_string($_GET['username']));
Тогда, когда у вас в имени пользователя было «&», оно таинственным образом превращалось бы в «& amp;» в вашей базе данных, а если в вашем имени пользователя был апостроф, оно превращалось в два апострофа на странице. Тогда, когда у вас есть форма с этими символами, легко получить двойной экранированный текст при редактировании, поэтому многие плохие PHP CMS заканчивают с испорченными заголовками статей, такими как «Новые книги от O \\\\». \\\\\\\\\\\\\\\ 'Reilly».
Естественно, вспоминать pg_escape_string или mysql_real_escape_string и htmlspecialchars каждый раз, когда вы отправляете переменную, немного утомительно, поэтому каждый хочет сделать это (неправильно) в одном месте в начале скрипта. Для вывода в формате HTML вы можете, по крайней мере, сохранить некоторую типизацию, определив функцию с коротким именем, которая выполняет echo (htmlspecialchars (...)).
Для SQL лучше использовать параметризованные запросы. Для Postgres есть pg_query_params . Или, действительно, подготовленные заявления, как вы упомянули (хотя я лично считаю их менее управляемыми). В любом случае, вы можете забыть о «очистке» или экранировании для SQL, но вы все равно должны уйти, если встраиваете другие типы строк, включая HTML.
strip_tags () не является хорошим способом обработки ввода для отображения HTML. В прошлом у него были проблемы с безопасностью, так как парсеры браузера на самом деле намного сложнее в интерпретации того, чем может быть тег, чем вы думаете. Вместо этого htmlspecialchars () - почти всегда правильная вещь, поэтому, если кто-то введет знак «меньше», он на самом деле получит буквальный знак «меньше» и не обнаружит, что половина его текста загадочно исчезает.
(*: в любом случае, как общий подход к решению проблем внедрения. Естественно, существуют специфичные для домена проверки, которые стоит выполнять в определенных полях, и есть полезные задачи очистки, которые можно выполнять, например, удаление всех управляющих символов из переданных значений. Но это не то, что большинство PHP-кодеров подразумевает под очисткой.)