Шифрование URL перенаправления на внешний сайт

Question

Я занимаюсь разработкой веб-приложения, которое перенаправляет пользователей во внешнее веб-приложение.Я хотел бы зашифровать URL перенаправления, чтобы пользователи не могли напрямую изменять URL.Внешний поставщик хотел бы использовать тройной DES.Вот мои вопросы:

1. Я предполагаю, что разработчики стороннего веб-приложения и мне придется обменяться каким-то «секретным ключом», чтобы мы могли расшифровать и зашифровать URL,что правильно?

2. Является ли этот "секретный ключ" каким-либо файлом или последовательностью символов, которые мы, возможно, можем первоначально обменять по электронной почте?что я пишу свое веб-приложение на Java, а сторонний поставщик пишет свое веб-приложение на .NET?

Answer 1

Похоже, вам нужно подписать параметры запроса, а не зашифровать их. Вы можете попробовать что-то вроде этого;

1) Создайте строку данных, которые вы хотите защитить с помощью цифровой подписи, например, если ваш URL-адрес;

http://www.example.com/doCourse?userid=123&courseid=abc

и вы хотите защитить параметры userid и courseid, которые вы создаете;

courseid = ABC & = 123 идентификатор пользователя

Обратите внимание, что в таких случаях обычно создается строка с параметрами в алфавитном порядке.

2) Используйте код аутентификации сообщения с криптографической хеш-функцией, такой как SHA-1, для генерации хеша вашей строки.

Сделайте это с;

Key key = ..... //You need to agree a key with the other party.
String string = ..... //The data you want to sign eg "courseid=abc&userid=123"
Mac mac = Mac.getInstance("HMAC-SHA1");
mac.init(key);
byte[] result = mac.doFinal(string.getBytes("UTF-8");

MAC обычно использует секретный ключ (который вы заранее согласовываете с другой стороной) для генерации хеша данных.

3) Base64 кодирует, затем URLE кодирует результат и включает его в перенаправление в качестве параметра (назовите его чем-то вроде «signature»).

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

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

Преимущества перед шифрованием

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

Answer 2

Ответы:

1 - да, вы обменяетесь ключом.Поскольку он спрашивает вас об этом шифровании, я бы попросил его предоставить ключ;

2 - да, он может предоставить вам ключ в любом случае, если вы считаете, что он безопасен, будь то электронная почта или любые другие средства;

3 - Неважно, какие языки вы используете.

Насколько я понимаю, пользователи вашей системы нажмут кнопку и будут отправлены на другой сайт.Этот сайт будет иметь адрес и некоторые параметры, верно?как http://some.address.com/some.page&param1=x&param2=2

Таким образом, вы должны зашифровать адрес, чтобы он был похож на http://some.address.com/2183u49823423hj23h, не так ли?

Итак, будьте осторожны, чтобы зашифровать только параметры, а не весь адрес (или ваша система выигралане знаю, куда идти).

И посмотрите, или поговорите с разработчиком другого сайта, если вам нужно каким-то образом закодировать зашифрованную информацию.При шифровании Sometinmes генерируется множество символов, некоторые из которых могут быть трудными / скучными для использования в Интернете и по адресу сайта.Спросите его о кодировке в base64, например.

Answer 3

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

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

Answer 4

1) Да. Вам нужно будет предоставить ключ, который кодирует / декодирует. 2) Это может быть последовательность символов. На самом деле вы можете использовать .NET для проверки прочности в тестовом приложении и генерировать ключ в виде строки таким образом. 3) Да. Я написал интерфейс, в котором шифрование Triple-Des из .NET было расшифровано в Java. Алгоритм Triple-Des одинаков для всех языков, поэтому ключи имеют одинаковую дешифровку / шифрование будет вести себя одинаково.

Вы также хотели бы создать вектор инициализации, который также можно использовать совместно.

Answer 5

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

Почему бы вам просто не настроить сервлет, который отвечает с HTTP 302 и URL-адресом, на который вы хотите перенаправить?

Ни один пользователь не сможет изменить URL-адрес, поскольку он является частью используемого сервлета.

Если вы хотите изменить URL-адрес позже, вы также можете загрузить URL-адрес из свойств Java, чтобы администратор сервера мог изменить URL-адрес.

Сохраняйте это простым и глупым, а также безопасным без какого-либо шифрования.