Я обсуждал с коллегами. Мы должны внедрить некоторые стандарты безопасности. Мы знаем, что не хранить информацию о секретности, адресах, дате рождения в скрытых полях, но нормально ли использовать скрытые поля для вашего приложения в целом.
Например:
action=goback
Похоже, было бы безопаснее использовать скрытые поля для такого рода информации, а не добавлять их в строку запроса. Это еще одна часть информации, которую хакер может использовать против вашего приложения.
Хакер может получить доступ к скрытым полям так же легко, как значения querystring, используя перехватчик прокси (или любое количество инструментов).
Я не думаю, что с использованием скрытых полей что-то не так, пока они не используются для чего-либо чувствительного, и вы проверяете их так же, как и любое другое значение от клиента.
Создание поля "скрытое" не имеет ничего общего с безопасностью и должно рассматриваться как решение пользовательского интерфейса. Любой "хакер" все равно будет читать ваш HTML-источник.
Лучше либо не показывать конфиденциальную информацию вообще, либо, если необходимо, использовать SSL (чтобы предотвратить перехват данных сетевыми посредниками) и некоторая комбинация задач входа (для предотвращения несанкционированного доступа).
Это только дыра в безопасности, если вы публикуете информацию, которая не была бы доступна для конечного пользователя и/или не подтвердила ее при возврате.
Вместо этого я бы вместо этого сохранил указанную информацию в переменной сеанса на стороне сервера...
Сохранение ваших данных в скрытом поле с точки зрения безопасности точно так же, как сохранение его в строке запроса. Фактически, если ваша форма использует действие GET, она все равно заканчивает строку запроса.
Скрытые поля абсолютно не связаны с безопасностью; это просто метод, с помощью которого данные могут храниться в форме, не заставляя пользователя ее видеть. Они не позволяют предотвратить просмотр пользователем.
Скрытые поля не всегда являются проблемой, но они всегда должны вызывать сигналы тревоги, поскольку у них есть две потенциальные проблемы:
1) Если данные чувствительны, он предоставляет его клиенту (например, используя прокси-сервер или просто просматривать исходный код), и бессмысленно пытаться предотвратить это программно)
2) Если данные интерпретируются сервером, знающий пользователь может его изменить. Чтобы принять глупый пример, если скрытое поле содержит баланс банковского счета пользователя, они могут использовать прокси-сервер или какой-то нестандартный клиент, чтобы сервер считал, что их банковский баланс - это все, что они выбирают.
Второй - большой источник уязвимостей в webapps. Данные, связанные с сеансом, должны храниться на стороне сервера, если у вас нет возможности проверить его на сервере (например, если это поле подписано или зашифровано сервером).
Если вы уверены, что не попадаете ни в одну из этих ловушек, они могут быть в порядке. Как правило, я бы не использовал скрытые поля, кроме данных, которые вы бы с удовольствием увидели в строке запроса, или если javascript нуждается в них для обработки. В последнем случае вам все равно нужно убедиться, что сервер проверяет, но не предполагайте, что клиент запустит ваш javascript.
Как отмечали другие люди, строка запроса и скрытые поля представляют собой общедоступные данные, доступные пользователю.
Одна вещь, о которой следует помнить, если вы размещаете данные в querystring, заключается в том, что люди передают URL-адреса, и из-за этого никогда не должно содержать никакой информации, относящейся к текущему пользователю.
Также, вероятно, хорошая идея не включать информацию о состоянии в URL-адрес, если это состояние не может быть введено напрямую. Или, по крайней мере, вам нужно будет обрабатывать недопустимую информацию о состоянии в запросе.
Рассмотрите возможность шифрования имени и значения вашего скрытого поля для проверки тампера, поскольку хакеры все еще могут захватить ваши скрытые поля и манипулировать ими так, как они хотели.
Я бы сказал, что это не более или менее безопасно, чем размещение элемента в строке запроса. В конце концов, всегда можно было просматривать исходный код на сайте (и не существует способа предотвратить это, поскольку всегда можно программно загрузить исходный код).
Лучшим решением здесь будет шифрование имен полей и значений с ключом, созданным на сервере, и только сервером. Если сервер не был взломан, клиент не будет знать, что такое имя значения или его значение.
Конечно, поскольку это происходит от клиента, вам все равно нужно проверить правильность возвращаемых данных, не просто считайте само собой разумеющимся, что он не был изменен так, как вы не диктовали.
С этой целью вы захотите использовать хеширование, чтобы убедиться, что значение не было изменено.
В общем случае не используйте скрытые поля форм для конфиденциальных данных. Только для статических нечувствительных данных POST, которые вы понимаете, небезопасно обрабатывать "по мере их получения". Единственный раз, когда я их использую, заключается в том, чтобы хранить токены сеанса, когда они отображаются, и проверяется при получении POST. Чтобы предотвратить атаки CSRF или, по крайней мере, сделать их намного сложнее.
В дополнение ко всем другим полезным советам других плакатов, я бы также добавил, что скрытые поля делают ваше приложение не менее уязвимым для атак SQL-инъекций, поскольку значения строки запроса url делают. Как всегда, дезинфицируйте свой вход.