Как обнаружить скрытое полевое вмешательство?
На форме моего веб-приложения у меня есть скрытое поле, которое я должен защитить от вмешательства из соображений безопасности. Я пытаюсь предложить решение, посредством чего я могу обнаружить, если значение скрытого поля было изменено и реагирует соответственно (т.е. с дженериком, "Что-то пошло не так, как надо, попробуйте еще раз" сообщение об ошибке). Решение должно быть достаточно безопасным, что атаки перебором неосуществимы. У меня есть основное решение, что я думаю, будет работать, но я не специалист по безопасности, и я могу быть полностью пропавшим что-то здесь.
Моя идея состоит в том, чтобы представить два скрытых исходных данные: один именованный "important_value", содержа значение, которое я должен защитить, и один названный "important_value_hash", содержащий хеш SHA важного значения, связанного с постоянной долгой случайной строкой (т.е. та же строка будет использоваться каждый раз). Когда форма будет отправлена, сервер повторно вычислит хеш SHA и выдержит сравнение с отправленным значением important_value_hash. Если они не то же, в important_value вмешались.
Я мог также связать дополнительные значения с входной строкой SHA (возможно, IP-адрес пользователя?), но я не знаю, получает ли это действительно меня что-нибудь.
Это будет безопасно? У кого-либо есть понимание, как оно могло бы быть повреждено, и что могло быть сделано для улучшения его?
Спасибо!
6 ответов
Лучше хранить хеш на стороне сервера. Вполне возможно, что злоумышленник может изменить значение и сгенерировать свой собственный хэш SHA-1 и добавить случайную строку (они могут легко выяснить это, повторно обращаясь к странице). Если хеш находится на стороне сервера (возможно, в каком-то кэше), вы можете пересчитать хеш и проверить его, чтобы убедиться, что значение не было изменено каким-либо образом.
РЕДАКТИРОВАТЬ
Я неправильно прочитал вопрос относительно случайной строки (постоянная соль). Но я предполагаю, что исходная точка зрения все еще остается в силе. Злоумышленник может создать список хеш-значений, соответствующих скрытому значению.
То, что вы описываете, похоже на часть реализации, которая требуется для так называемых канареек и используется для смягчения атак с подделкой межсайтовых запросов.
Вообще говоря, скрытый ввод внутри HTML-формы содержит зашифрованное значение, которое отправляется обратно с HTTP-запросом. Файл cookie браузера или строка, содержащаяся в сеансе, содержит одно и то же зашифрованное значение, так что, когда скрытое входное значение расшифровывается и значение cookie / сеанса расшифровывается, незашифрованные значения сравниваются друг с другом - если они не идентичны, HTTP-запрос нельзя доверять.
Зашифрованное значение может быть объектом, содержащим свойства. Например, в ASP.NET MVC канареечная реализация использует класс, который содержит свойства для аутентифицированного имени пользователя, криптографически псевдослучайное значение, сгенерированное с использованием класса RNGCryptoServiceProvider , DateTime (формат UTC), в котором объект была создана и необязательная строка соли. Затем объект зашифровывается с использованием алгоритма шифрования AES с 256-битным ключом и расшифровывается тем же ключом при поступлении запроса.
Если вы не можете обработать сеанс на сервере, рассмотрите возможность шифрования данных с помощью вашего закрытого ключа и создания для него HMAC, отправьте результаты в виде скрытых полей. Затем вы можете убедиться, что то, что возвращается, совпадает с тем, что было отправлено, потому что, поскольку никто другой не знает ваш закрытый ключ, никто другой не может сгенерировать действительную информацию. Но было бы гораздо лучше обрабатывать данные, запрещающие изменение, на стороне сервера.
Вы должны понимать, что любой достаточно решительный человек может отправить вам HTTP-запрос (ваша форма), содержащий нужную им информацию, которая может иметь или не иметь никакого отношения к тому, что вы отправляли им в последний раз.
Пока вы охраняете «постоянную длинную случайную строку» своей жизнью, ваш метод относительно силен.
Чтобы пойти дальше, вы можете сгенерировать одноразовые / уникальные "постоянные длинные случайные строки".
Если вы не можете/не хотите хранить хэш на стороне сервера, вам нужно иметь возможность повторно генерировать его на стороне сервера, чтобы проверить его.
Если уж на то пошло, вам также следует солить ваши хэши. Возможно, это то, что вы имели в виду, когда сказали:
конкатенированный с постоянной длинной случайной строкой (т.е. одна и та же строка будет использоваться каждый раз)
Знайте, что если это значение не отличается для каждого пользователя/логина/сезона, то это не совсем соль.
Цифровая подпись
Возможно, это перебор, но это звучит не иначе, чем когда вы подписываете исходящее электронное письмо цифровой подписью, чтобы получатель мог проверить его происхождение и содержание. аутентичный. Подпись поля, чувствительного к несанкционированному вмешательству, может быть опубликована с помощью вашего чувствительного к вмешательству поля, не опасаясь необнаружимого несанкционированного доступа, если вы защищаете закрытый ключ и проверяете данные и подпись с помощью открытого ключа. по возвращении.
Эта схема даже имеет изящное свойство, заключающееся в том, что вы можете ограничить «подписывание» очень защищенным набором серверов / процессов с доступом к закрытому ключу, но использовать более широкий набор серверов / процессов, снабженных открытым ключом, для обработки отправленных форм. .
Если у вас есть действительно чувствительное поле «не вмешиваться» и вы не можете поддерживать его хэш-подпись на сервере, то я бы рассмотрел этот метод.
Хотя я подозреваю, что большинство знакомо с цифровой подписью, вот некоторая Википедия для всех непосвященных:
Криптография с открытым ключом - Безопасность
... Другой тип приложения в криптографии с открытым ключом является схемой цифровой подписи . Схемы цифровой подписи могут использоваться для аутентификации отправителя и предотвращения отказа от авторства. В такой схеме пользователь , который хочет отправить сообщение , вычисляет цифровую подпись этого сообщения и затем отправляет эту цифровую подпись вместе с сообщением в предполагаемый получатель.Схемы цифровой подписи обладают тем свойством , что подписи могут быть вычислены только со знанием закрытого ключа. Чтобы проверить, что сообщение было {{1} }} подписан пользователем и не был изменен, получателю необходимо только знать соответствующий открытый ключ. В некоторых случаях (например, RSA) существуют схемы цифровой подписи, которые во многом похожи на схемы шифрования. В других случаях (например, DSA) алгоритм не похож ни на одну схему шифрования . ...