Запутался с кодировкой html

Я путаюсь с кодировкой символов.

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

Итак, если пользователь вводит апостроф, двойную кавычку или амперсанд, меньше, больше, чем знак, они будут записаны в моей базе данных как ' " & ‹ > соответственно.

Теперь, читая данные с помощью php, я запускаю текст через HTMLPurify, чтобы выявить любые проблемы с внедрением.

Должен ли я также htmlencode его? Если я этого не сделаю, все выглядит нормально (в Chrome и Firefox), но я не уверен, правильно ли это и будет ли он правильно отображаться в других браузерах?

Если я использую htmlentities с ENT_QUOTES и htmlspecialchars, я начинаю получать коды, поступающие для этих символов, и я считаю, что это то, что я должен видеть, если смотрю на исходный код страницы, а не на страницу, которую видит пользователь.

Проблема в том, что без кодирования я вижу то, что хочу видеть, но имею в виду эту мелочь, что я делаю это неправильно!


php html-encode
person StripyTiger    schedule 11.07.2017    source источник
comment
Это, вероятно, будет помечено как не относящееся к теме, поскольку оно полностью основано на мнении. Возможно, вы захотите перефразировать более конкретный вопрос с примерами кода.   -  person Difster    schedule 12.07.2017
comment
Сохраняйте пользовательский ввод как есть, но очищайте его перед выводом (например, если вы хотите предотвратить XSS). Вам не нужно ничего кодировать в HTML.   -  person Terry    schedule 12.07.2017
comment
Поместите данные в базу данных как фактические данные - т.е., если это через HTML, удалите его. Тогда его смогут использовать другие приложения.   -  person Ed Heal    schedule 12.07.2017

Ответы (1)


arrow_upward
1
arrow_downward

Это у вас запутано. Кодировка символов является атрибутом ВАШИХ систем. Ваши веб-сайты и ваша база данных отвечают за кодировку символов.

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

На этом этапе все ваши веб-страницы должны быть HTML5, поэтому рекомендуемый раздел HEAD ваших страниц должен быть как минимум следующим:

<!DOCTYPE html>
<html lang="en"> 
<head>
<meta charset="utf-8"/>

Затем у вас есть SQL-инъекция. Вы указали PHP. Если вы используете mysqli или PDO (что, по моему опыту, является лучшим выбором) И вы используете bindParameter для всех ваших переменных, НЕТ ПРОБЛЕМ с SQL-инъекцией. Эта проблема исчезает, и исчезает необходимость экранирования ввода, потому что вам больше не нужно беспокоиться о том, что оператор SQL может запутаться. Это больше невозможно.

Наконец, вы упомянули htmlpurifier. Это существует для того, чтобы люди могли попытаться избежать XSS и других подобных эксплойтов, которые происходят, когда вы принимаете ввод пользователя, и эти люди внедряют html и js.

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

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

person gview    schedule 11.07.2017