Алгоритм шифрования для идентификаторов URL - PullRequest
Новая
       59

Алгоритм шифрования для идентификаторов URL

0 голосов
/ 27 апреля 2020

Я работаю над веб-приложением Spring и натолкнулся на сценарий, который требует передачи идентификатора в URI (GET over HTTPS), например: https://www.targetdomain.com/services?id=123. Этот URI отображается в браузере конечного пользователя, и я обеспокоен тем, что любой может подделать этот идентификатор «123», связанный с моей базой данных в качестве первичного ключа в одной из таблиц.

Один из способов решения этой проблемы может быть, чтобы сохранить это в пользовательском сеансе (HTTPSession), другое - зашифровать его и выбросить в браузере как https://www.targetdomain.com/services?id=jk3434jj123jkh23jh213h. Когда конечный пользователь нажимает на ссылку, я могу расшифровать ее на стороне сервера для получения идентификатора.

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

я наткнулся на какой-то пост (например - шифрование и кодирование параметров URL весны mvc), где рабочий код представлен с использованием «AES / CBC / PKCS5Padding» в качестве шифра. Это выглядит хорошим решением для этого варианта использования?

1 Ответ

1 голос
/ 27 апреля 2020

Наиболее безопасным решением будет управление параметром в сеансе, как вы описали, если это вариант. Таким образом, все это на сервере и защищено от злоумышленника, имеющего доступ к сеансу пользователя в браузере (но не к серверу). Если вы можете сделать это, возможно, это правильно.

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

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

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

Обратите внимание, что это два отдельные вещи, зашифрованные сообщения не обязательно аутентифицируются, а аутентифицированные сообщения не шифруются.

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

Или, в зависимости от ваших требований, вы можете выбрать аутентифицированное шифрование (AEAD), которое обеспечивает обе функции в одном. Такой алгоритм, например. AES в режиме GCM. (AES-CB C, упомянутый в вашем вопросе, не является режимом с проверкой подлинности для AES.)

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

Или вы все еще можете просто сделать это через сеанс ...:)

...