Блог

Фон

HTML-форма, например, для пользователя, отправляющего свои бизнес-данные, которые позже появятся в юридическом документе — поэтому данные должны быть точными.

Отправляется PHP-скрипту, который проверяет все входные данные.

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

Если какой-либо из входных данных неверен, он повторно отображает форму. Мне кажется, что пользователь ожидает, что эта форма будет заполнена тем, что он первоначально ввел, с некоторой обратной связью о том, что не так с их вводом. Затем они могут изменить свои входные данные и повторно отправить форму. Это означает, что форма должна быть заполнена неочищенными данными (они будут экранированы перед их отображением).

Пока все хорошо.

Проблема

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

Это означает, что данные, записанные в базу данных, могут быть не совсем такими, какие ввел пользователь (например, если очистка удаляет некоторые «опасные» символы).

Мне кажется, что это плохой пользовательский интерфейс.

Я использую PHP, и код выполняется в рамках WordPress. WP имеет свои собственные функции очистки, и они рекомендуют всегда очищать ввод перед его использованием. Они также предлагают использовать функции очистки PHP. Но, похоже, ничто не решает проблему, связанную с тем, что очистка данных перед их сохранением может привести к тому, что сохраненные данные будут отличаться от введенных пользователем.

Вопрос

Я хотел бы получить описание подхода, который использовался в реальном мире для решения этой проблемы? Или некоторые отзывы от тех из вас, у кого больше опыта, чем у меня, о том, что это не проблема в реальном мире, и обычной практикой является просто очистка данных и их хранение без дальнейшего беспокойства или обратной связи с пользователем.

Мои мысли о возможных решениях

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

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

Спасибо за вашу помощь.

Выводы

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

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

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

И, наконец, теперь я понимаю, что все дело в контексте … проблема заключается в обеспечении безопасности данных для конкретного использования. В этом смысле дело не в том, что один метод подходит только для ввода, а другой — только для вывода. Мне нужно подумать о проверке, очистке или экранировании при выполнении каких-либо действий с данными — например, записать их в БД, использовать в вычислениях, распечатать на экране или вставить в документ PDF. И во всех случаях мне просто нужно подумать о том, как я делаю это безопасным для этого конкретного использования. Очистка «ввода» может быть вполне уместной — если это быстро и легко, делает данные безопасными для всего, что мне нужно сделать, и не делает данные неточными. Другим примером является функция WordPress esc_url_raw(), которая, как указано в руководстве, специально предназначена для использования при сохранении URL-адреса в базе данных. Итак, идея о том, что экранирование подходит только для «вывода», вводит в заблуждение.

В итоге я проверил входные данные перед записью их в базу данных. Мне также не нужно было их очищать. Поэтому я, если это неверно, сообщаю пользователю. Если это допустимо, оно записывается в БД в исходном виде. И я избегаю этого, прежде чем отображать его обратно пользователю.

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

Это распространенное заблуждение. Очистка должна выполняться только для данных, которые выводятся, например, для предотвращения XSS, и даже тогда только в крайнем случае. Именно потому, что это может необратимо уничтожить исходные данные.

Проверка — это ваша первая линия защиты. Убедитесь, что данные правильно отформатированы и действительны в своем контексте — только это; не ищите специальные символы, не переусердствуйте. Если это недопустимо — отклоните его, не пытайтесь извлечь из него «хорошие» части.

Тогда при хранении в базе данных вам просто нужно использовать параметризованные запросы — это на 100% эффективно против SQL-инъекций. Если вы не искажали данные на предыдущем шаге, вы сохраняете их в исходном виде.

И, наконец, когда данные выводятся, именно там вы ДОЛЖНЫ экранировать специальные символы в соответствующем контексте, чтобы они были правильно отображены; или очистить их, если у вас нет другого выбора (т. Е. Контекст неясен, и поэтому вы не можете выполнить правильное экранирование).

Похоже, вы беспокоитесь о чувствах пользователя, это хорошо. Есть несколько вещей, которые вы можете сделать.
Используйте html-форму pattern — наверняка ни одно имя не нуждается в знаках типа < > amp; $ " ... — исключите это с помощью pattern , используйте css :invalid и :invalid:focus , чтобы сообщить пользователю перед отправкой, если что-то не так. Это очень легко и просто.
Затем php проходит дальнейшую проверку и очистку WP.
Вы можете использовать промежуточное состояние — после «промывки» — отобразить окончательную версию (без ввода) с помощью 2 кнопок — сохранить или исправить — пусть пользователь решает, большинству из нас не нравятся эти повторения «вы уверены? нажав отправить, вы имеете в виду отправить?» — но, возможно, с таким релевантным контентом пользователи хотели бы иметь последний шанс, и они хотят увидеть окончательную версию (без входных данных, флажков и т.д.).
Теперь вы помещаете принятую версию в базу данных (подготовленную).
Сравнивать необработанные данные с промытыми нецелесообразно, честно говоря, это отстой — пользователи не будут программистами — они просто не смогут правильно понять «мы очистили ваши ответы, и теперь они на 345 символов короче. Извините за неудобства «
Не волнуйтесь слишком сильно
…существует немецкая фамилия ‘Ei’ — всего 2 символа, поэтому шаблон не может требовать больше 2.