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