Это подчеркивало меня. У меня есть скрытый ввод:
<input type="hidden" value="North Miami" name="city"> Я заполняю скрытый ввод действительными названиями городов через javascript перед отправкой формы. Предположим, кто-то хочет представить Banana вместо названия города. Преступник может легко изменить входное значение через инспекторов DOM, таких как Firebug.
Как я могу гарантировать, что скрытые входы не подделаны? Я уже проверяю входные данные против атак, но пока я принимаю алфавитные символы, все может быть отправлено, поэтому banana …
Изменить: я имею в виду скрытые входы в целом, а не только названия городов. Любое значение, заполняемое скриптом, и значение, которое должно быть отправлено без изменений.
Некоторые идеи:
Только на стороне сервера. Самый простой способ сделать это – использовать переменные сеанса (например, $_SESSION ), так что все данные, хранящиеся на стороне сервера, но управляющие им и сохраняющие отдельные вкладки, пользователь может иметь открытые отдельные элементы, может немного запутаться. Этот параметр запрещает пользователю просматривать или редактировать информацию.
Сделать клиентом перенос зашифрованного блоба. Возьмите все ваши «временные, но защищенные» данные, соедините их каким-то образом (например, JSON), а затем зашифруйте * все это с помощью секретного ключа, известного только серверу. Результат Base64 и поместите это в значение скрытого поля. (Обратите внимание, что для приложения с высокой степенью защиты вы также захотите задействовать HMAC в этом процессе, который проверяет, что шифрованный текст не был переделан.) Этот параметр также запрещает пользователю просматривать или редактировать информацию, но упрощает обработку случаев, когда один пользователь открывает много вкладок.
По-прежнему используйте не столь секретные скрытые поля ввода, но добавьте механизм защиты от несанкционированного доступа. Поэтому, когда страница сгенерирована, возьмите все существующие «защищенные» переменные, соедините их каким-то образом с секретным значением на стороне сервера и хешем [исправление: HMAC]. Храните хэш в своем скрытом поле. Затем после того, как пользователь отправит, вы повторите процесс и проверьте соответствие хэша. Если это не так, сделайте все с ошибкой на странице нарушения безопасности.
* Как и при всей криптографии, выполнение этого «правильного» способа может быть сложным и во многом зависит от того, как вы шифруете / проверяете. Есть много подводных камней с точки зрения шифров и шифрованных режимов и т. Д.
Наконец, помните, что запрещение людям изменять его не означает, что пользователь не может копировать все и повторно использовать его позже или под другой учетной записью, если вы не предпримете шаги для включения «отметки времени» и т. Д.
Вы не можете. Вы никогда не сможете опираться на пользовательские данные. Даже если вы можете запретить пользователю изменять элементы DOM (чего вы не можете), вы вряд ли сможете помешать им отправлять HTTP-запрос с помощью cURL, wget или другой библиотеки с любыми полями, которые они выбрали. Не доверяйте никаким данным, которые отправляются пользователем.
Если вы хотите, чтобы значение не изменилось, вам нужно будет сохранить его на сервере. PHP имеет отличную функцию, которая позволяет вам делать это – сеансы . Храните данные в сеансе, и пользователь не сможет его модифицировать, поскольку он будет храниться на вашем сервере и никогда не будет передаваться самим пользователю или из него.
Если вы склонны избегать обратной передачи сервера для проверки ввода, вы можете закодировать код base64 на свой скрытый вход и по крайней мере сделать это труднее для людей, чтобы вмешаться в него.
Вы не можете. Правило всегда помнить, что сэкономит вам много времени на размышление и дизайн. Если браузер имеет его, он не защищен.