Как очищать текст в php?

Question

[Jesse Pinkman]

Привет, помогите разобраться.

На бэк приходит текст который нужно сохранить в базу. Использую pdo, но записи c html тегами все равно попадают туда. Индус советует использовать такую универсальную функцию

function my_trim($var) {
	$var =  trim($var);
	$var =  htmlspecialchars($var);
	$var =  stripcslashes($var);
	$var =  strip_tags($var);
	return $var;	
}	

$trimmed = my_trim($_POST['name']);

А что можете Вы посоветовать, какие есть актуальные способы, что бы не городить, то что предложил Индус.

Спасибо

Answer 1

[Ипатьев]

Никак не очищать.

На самом деле этот вопрос встречается довольно часто. Вот например популярный ответ на Stack Overflow, который подробно разбирает этот распространённое заблуждение: https://stackoverflow.com/a/3126175. И основная мысль там:

Понятие такой генерализованной "очистки данных" изначально бессмысленное и вредное.

Особенно такой вот индусской функцией, которая сама по себе - пример редкого идиотизма: сначала заменяем символы < и > на HTML сущности... а потом бодро пытаемся вырезать HTML теги. Которых к этому моменту в тексте не останется ни одного!
Или функция stripcslashes, которая здесь вообще ни к селу, ни к городу. Если я хочу написать сочетание \n, то с какой стати эта функция будет заменять его на перевод строки?
Всё что можно оставить из этого безумного набора - это trim(). Да и то не всегда. Как правильно заметил Rsa97, могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода. Кстати, этим как раз грешит Хабр. Если запостить код с отступами, то первый будет "съеден"!

Очистка

Любая "очистка" (хотя правильнее говорить про форматирование), имеет смысл только в определённом контексте.
И поэтому "очищать" надо только адресно, строго перед использованием в том или ином конкретном случае.

Например, базе данных ни жарко, ни холодно от наличия HTML тегов.
А проблемы могут начаться только при выводе данных в HTML. Но если мы будем предотвращать эти проблемы заранее, то просто попортим кучу данных. Поэтому форматировать данные для использования в контексте отрисовки HTML следет строго перед этой отрисовкой. То есть при выводе.
Что и делают все популярные РНР шаблонизаторы автоматически.
То есть вручную колупаться с "очисткой" вообще не нужно.

Больше того, "очистка" HTML поможет данным, выводимым в яваскрипт, как мёртвому припарки. То есть опять же - всегда надо понимать, в какой именно контекст мы выводим данные, и форматировать соответствующим образом. В частности любые данные передавать в яваскрипт только через json_encode()

И таких контекстов неисчислимое множество. Например, если мы используем переменную для передачи параметров в консольный скрипт, то надо обязательно обрабатывать её через escapeshellarg(). Если в регулярку - то preg_quote(). Имя файла для инклюда из переменной (хотя так делать вообще не стоит) надо хотя бы обрабатывать через basename(). И так далее.

Валидация

Если же наличие HTML тегов в поступающих данных противоречит техническому заданию, то надо заниматься не "очисткой", а валидацией: проверить регулярным выражением, есть ли в строке HTML теги. И если есть, то вернуть пользователю с сообщением об ошибке.

Защита БД

И кстати, по поводу "использую pdo".
На всякий случай уточню, что само по себе использование PDO не защищает ни от каких проблем
Важно помнить, что защита - это когда в базу данных отправляется строго константная строка запроса, полностью на 100% составленная из значений, прописанных в коде РНР, и в ней не используется ни одно значение, пришедшее в код извне. Причем PDO помогает здесь только наполовину, позволяя использовать в запросе подстановки вместо самих данных.
Но при этом для всех остальных частей запроса - например имен полей - у ПДО нет никакой защиты и её надо организовывать самостоятельно. Либо проверяя по белому списку, лабо, по крайней мере, прогоняя через регулярку.

Comments

[Rsa97]

Всё что можно оставить из этого безумного набора - это trim()

И то не всегда. Могут быть случаи, когда лидирующие пробелы имеют значение, например, при выводе форматированного кода.

[Ипатьев]

Rsa97, кстати да, спасибо. Прямо так сейчас и добавлю в ответ

[Vitsliputsli]

Добавлю, про "использую pdo". PDO с защитой от sql-инъекций не связан от слова совсем. Гарантированную защиту от sql-инъекций дает использование подготовленных выражений (и не важно в каком драйвере, PDO, pg, mysqli, odbc). Причем именно натуральных SQL подготовленных выражений, а не эмуляции. Практически же, и в эмуляциях сейчас достаточно высокая защита. Если же пользовательские данные - число, то достаточно использовать тип число, очевидно, что это тоже вполне эффективно.
И разумеется речь про подстановку пользовательских данных как параметризованных значений. Если вы поля берете из пользовательских данных, вы явно что-то делаете не так.

[Ипатьев]

Vitsliputsli, ну в реальной практике не обойтись без использования имён полей на основе пользовательского ввода.
Самый простой пример - сортировка. Плюс довольно частая задача по обновлению только заполненных пользователем полей, и выбрасыванию пустых - чтобы не затереть пустыми значениями уже имеющуюся информацию.

[Jesse Pinkman]

Роман Юрьевич Ипатьев, огромное Вам спасибо за развернутый ответ

[Jesse Pinkman]

Vitsliputsli Роман Юрьевич Ипатьев , что касается pdo, у меня есть очень много вопросов, просто не хотелось бы спамить их на тостере или в комментах, но один вопрос я все же задам и был бы Вам благодарен, если бы Вы помогли мне.

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

function ls_db_insert($table_name, $data) {
	global $dbpdo;

	$col_names_list = array_keys($data[array_key_first($data)]);
	$col_names_list = implode(",", $col_names_list);
	$toBind = array();
	$valusList = array();
	$sql_val = [];
	foreach($data as $index => $row) {
		$params = array();
		
		foreach($row as $col_name => $value) {
			$params[] = '?';
			$toBind[] = $value;
		}

		$sql_val[] = "(" . implode(", ", $params) .")";
	}

	$sql_values =  implode(", ", $sql_val);

	$query = "INSERT INTO $table_name ($col_names_list) VALUES $sql_values";
	
	$stmt = $dbpdo->prepare($query);
	$stmt->execute($toBind);
}

Одна функция которую я использую в разных местах, где мне нужно вставить записи в бд.

Использую так: первый аргумент это название таблицы, вторая массив с данными которые нужно записать

return ls_db_insert('my_table_name', [
    [
        'тут название столбца' => 'тут что нужно записать',
        'col_name2' => $_POST['name']
    ],
]);

Если нужно вставить несколько записей в базу, то добавляю еще один массив:

return ls_db_insert('my_table_name', [
    [
        'тут название столбца' => 'тут что нужно записать',
        'col_name2' => $_POST['name']
    ],
    [
        'добавим еще одну запись' => 'тут что нужно записать',
        'col_name2' => $_POST['name']
    ],
    [
        'тут только один столбец например' => $_POST['name']
    ],
]);

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

Это норма или индусский менталитет написание когда ?

[Ипатьев]

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

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

function quote_mysql_identifier($ident)
{
    return "`" . str_replace("`", "", $ident) . "`";
}

и прогонять через неё имя таблицы и все имена полей.

так в принципе тоже сохраняется опасность. Например в таблице users есть поле admin. И если со стороны передадут такое поле, то юзера сделают админом. поэтому лучше всего проверять поля по списку разрешенных.

[nokimaro]

Jesse Pinkman, позовите FanatPHP он вам покажет как делать нормальную обёртку для PDO

или выберите что-то из гугла по запросу "php pdo wrapper"
например 648 звёзд на гитхабе - https://github.com/paragonie/easydb

[Ипатьев]

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

easydb хороша, я там даже поучаствовал по мелочи. Но для изучения он уже великоват. а польза от пользования системой, которую не понимаешь, довольно сомнительная.

[Jesse Pinkman]

Роман Юрьевич Ипатьев, Спасибо, вы действительно очень сильно помогли мне.

[Jesse Pinkman]

nokimaro, позвал, но он не пришёл. Спасибо за совет и ссылку, посмотрю!

[Владимир]

Роман Юрьевич Ипатьев, в реальной практике не только можно, но и нужно без этого обходиться: пользовательский ввод обязан в данном быть обработанным, т.к. набор полей в каждом случае ограничен и все сводится к простому множественному ветвлению со значением по умолчанию на случай попаданию в систему кулхацкера. Т.е., в самом забавном варианте, если пользователь желает сортировку по полю value1, value2 или value3, то вы не краснея пишете

switch($userRawInput){
  case 'value1': $sortField='value1'; break;
  case 'value2': $sortField='value2'; break;
  case 'value3': $sortField='value3'; break;
  default:  $sortField='value1';
}

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

[Vitsliputsli]

Роман Юрьевич Ипатьев,

ну в реальной практике не обойтись без использования имён полей на основе пользовательского ввода

Разумеется нужны динамические запросы, и они могут формироваться на основе запросов пользователей. Но поля в таких запросах не берутся из пользовательских данных, выбираются на их основе - да, но не сами пользовательские данные подставляются в запрос. А потому их можно подставлять прямо в запрос и никакие плейсхолдеры prepared statements здесь не нужны. Т.к. это не данные.

Jesse Pinkman, неплохо, как функция в составе обертки для работы с БД. Пока сами разработчики не косячат вполне устойчива к инъекциям (т.е. названия таблиц и полей должны задаваться только внутри). Насчет global правильное замечание, но с этими проблемами столкнетесь тогда, когда будете подменять этот объект (при его расширении или при тестировании).