Веб-безопасность, есть ли проблемы со скрытыми полями (без конфиденциальных данных)?

Question

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

Например:

action=goback

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

Answer 1

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

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

Answer 2

Создание поля «скрытым» не имеет ничего общего с безопасностью и должно рассматриваться как решение пользовательского интерфейса. Любой «хакер» все равно прочтет ваш HTML-источник.

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

Answer 3

Это всего лишь дыра в безопасности, если вы предоставляете информацию, которая иначе была бы недоступна для конечного пользователя, и / или не проверяете ее по возвращении.

Вместо этого я хотел бы сохранить указанную информацию в переменной сеанса на стороне сервера ...

Answer 4

Хранение ваших данных в скрытом поле, с точки зрения безопасности, точно так же, как хранение их в строке запроса. Фактически, если ваша форма использует действие GET, она все равно заканчивается строкой запроса.

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

Answer 5

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

1) Если данные являются конфиденциальными, они открываются для клиента (например, с использованием прокси или просто просматривают источник - и пытаться предотвратить это программно бессмысленно)

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

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

Если вы уверены, что не попадете ни в одну из этих ловушек, их можно использовать. Как правило, я бы не использовал скрытые поля, за исключением данных, которые вы были бы рады видеть в строке запроса, или если бы JavaScript требовался для их обработки. В последнем случае вам все же нужно убедиться, что сервер проверяет, хотя не думайте, что клиент запустит ваш javascript.

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

Как правило, не используйте скрытые поля формы для конфиденциальных данных. Только для статических, не конфиденциальных данных POST, которые вы понимаете, небезопасно обрабатывать «по мере их получения» Единственный раз, когда я их использую, это хранить токены сессий, когда они отображаются и проверяются после получения POST. Чтобы предотвратить атаки CSRF или, по крайней мере, сделать их намного сложнее.

Answer 10

Я бы сказал, что это не более или менее безопасно, чем размещение элемента в строке запроса. В конце концов, можно всегда просматривать исходный код на сайте (и нет никакого способа предотвратить это, поскольку всегда можно программно загрузить исходный код).

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

Конечно, поскольку это исходит от клиента, вам все равно нужно проверить достоверность возвращаемых данных, а не просто принимать как должное, что они не были изменены таким образом, который вы не диктовали .

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