Безопасность в Интернете, там проблемы со скрытыми полями (никакие уязвимые данные)?

Создание "скрытого" поля в значительной степени не имеет никакого отношения к безопасности и должно считаться решением UI. Любой "хакер" считает Ваш источник HTML так или иначе.

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

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

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

Хранить Ваши данные в скрытом поле, с точки зрения безопасности, точно то же как хранение его в строке запроса. На самом деле, если Ваша форма использует ПОЛУЧИТЬ действие, она заканчивается интервал, он запрашивает строку так или иначе.

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

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

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

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

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

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

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

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

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

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

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

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

С этой целью, Вы захотите использовать хеширование, чтобы удостовериться, что значение не вмешалось.

В целом не используйте скрытые поля формы для уязвимых данных. Только для помех не чувствительные данные POST, которые Вы понимаете, не безопасно обработать "как его полученный". Единственное время я использую их, должно сохранить Маркеры Сессии, поскольку они представляются и проверяются после получения POST. Предотвратить нападения на CSRF или по крайней мере сделать их намного тяжелее.

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

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