Как обнаружить скрытое поле взлома?

Question

В форме моего веб-приложения у меня есть скрытое поле, которое необходимо защитить от несанкционированного доступа по соображениям безопасности. Я пытаюсь найти решение, с помощью которого я могу определить, было ли изменено значение скрытого поля, и отреагировать соответствующим образом (т. Е. С общим сообщением об ошибке «Что-то пошло не так, попробуйте еще раз»). Решение должно быть достаточно безопасным, чтобы атаки методом перебора были невозможны. У меня есть базовое решение, которое, я думаю, сработает, но я не эксперт по безопасности, и я могу что-то здесь упустить.

Моя идея состоит в том, чтобы визуализировать два скрытых ввода: одно с именем "Important_value", содержащее значение, которое я должен защитить, и одно с именем "Important_value_hash", содержащее хэш SHA важного значения, объединенного с постоянной длинной случайной строкой (т.е. одна и та же строка будет использоваться каждый раз). Когда форма будет отправлена, сервер пересчитает хэш SHA и сравнит его с переданным значением Important_value_hash. Если они не совпадают, значение важный_ было изменено.

Я мог бы также объединить дополнительные значения со строкой ввода SHA (может быть, IP-адрес пользователя?), Но я не знаю, действительно ли это мне что-то дает.

Будет ли это безопасно? Кто-нибудь знает, как это может быть сломано, и что можно / нужно сделать, чтобы улучшить его?

Спасибо!

Answer 1

Было бы лучше хранить хэш на стороне сервера. Вполне возможно, что злоумышленник может изменить значение и сгенерировать свой собственный хэш SHA-1 и добавить случайную строку (он может легко выяснить это при повторном доступе к странице). Если хеш включен на стороне сервера (возможно, в каком-то кеше) вы можете пересчитать хеш и проверить его, чтобы убедиться, что значение не было подделано каким-либо образом.

EDIT

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

Answer 2

Если вы не можете обработать сеанс на сервере, рассмотрите возможность шифрования данных с помощью закрытого ключа и создания для него HMAC, отправьте результаты в виде скрытых полей. Затем вы можете проверить, что возвращаемое соответствует отправленному, потому что, поскольку никто другой не знает ваш закрытый ключ, никто не может сгенерировать действительную информацию. Но было бы намного лучше обрабатывать данные «не должны быть изменены» на стороне сервера.

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

Answer 3

Цифровая подпись

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

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

Если у вас действительно чувствительное поле «не вмешиваться» и вы не можете сохранить его хэш-сигнатуру на сервере, то этот метод я бы рассмотрел.

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

Криптография с открытым ключом - Безопасность

... Другой тип приложения в криптография с открытым ключом схемы цифровой подписи. цифровой схемы подписи могут быть использованы для аутентификация отправителя и безотказности. По такой схеме пользователь, который хочет отправить сообщение вычисляет цифровую подпись этого сообщение, а затем отправляет этот цифровой подпись вместе с сообщением предполагаемый получатель. цифровой Схемы подписи имеют свойство что подписи могут быть вычислены только со знанием личного ключа. Чтобы убедиться, что сообщение было подписано пользователем и не было модифицированный приемник нужно только знать соответствующий открытый ключ. В в некоторых случаях (например, RSA) схемы цифровой подписи со многими сходство со схемами шифрования. В другие случаи (например, DSA) алгоритм не напоминает шифрование схема. ...

Answer 4

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

Вообще говоря, скрытый ввод внутри HTML-формы содержит зашифрованное значение, которое отправляется обратно с HTTP-запросом. Файл cookie браузера или строка, содержащаяся в сеансе, содержит одно и то же зашифрованное значение, так что когда скрытое входное значение расшифровывается, а значение cookie / сеанса дешифруется, незашифрованные значения сравниваются друг с другом - если они не идентичны, запрос HTTP нельзя доверять.

Зашифрованное значение может быть объектом, содержащим свойства. Например, в ASP.NET MVC канарская реализация использует класс, который содержит свойства для аутентифицированного имени пользователя, криптографически псевдослучайное значение, сгенерированное с использованием класса RNGCryptoServiceProvider, DateTime (формат UTC), в котором был создан объект, и необязательный солонка. Затем объект шифруется с использованием алгоритма шифрования AES с 256-битным ключом и дешифруется тем же ключом при поступлении запроса.

Answer 5

Пока вы сохраняете «постоянную длинную случайную строку» в своей жизни, ваш метод относительно силен.

Чтобы пойти дальше, вы можете генерировать одноразовую / уникальную «постоянную длинную случайную строку».

Answer 6

Если вы не можете / не хотите хранить хеш-версию на стороне сервера, вам необходимо иметь возможность заново сгенерировать ее на стороне сервера, чтобы проверить это.

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

сцеплено с постоянной длиной случайная строка (то есть та же строка будет использоваться каждый раз)

Знайте, что если это значение не отличается для каждого пользователя / логина / сессии, на самом деле это не солт-значение.