Отправка веб-формы: шифрование на стороне клиента и исходный код недоступны

Я не очень разбираюсь в веб-сайтах и ​​особенно в безопасности веб-сайтов.

Прежде чем говорить о проблеме, давайте объясним контекст:

Я создал веб-страницу, которая должна быть платформой с формой заказа X, которую должен заполнить какой-то клиент A, с некоторыми критическими полями Y, которые должны быть зашифрованы. Затем веб-сервер отправит письмо с X + Y продавцу B, чтобы он мог обработать заказ.

Что я сделал:

Я создал форму с помощью Spring MVC с контроллером (на Java) и шаблоном представления HTML. Это руководство немного помогло мне: https://spring.io/guides/gs/handling-form-submission/. Когда A отправляет X+Y, я шифрую Y (с симметричным шифрованием TEA) в контроллере (поэтому я предполагаю, что это явно на стороне сервера), а затем отправляю его продавцу по почте. Затем продавец расшифровывает его тем же ключом, который использовался для расшифровки.

Проблема:

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

Является ли клиентская сторона Javascript единственным решением для этого? Я бы предпочел сделать это на Java на стороне клиента, потому что я хочу, чтобы шифрование было на стороне клиента, а также чтобы исходный код, содержащий алгоритм шифрования, был скрыт от всех (что, я думаю, не так в HTML и Javascript).

Итак, для шифрования на стороне клиента и скрытого исходного кода возможно ли это сделать с помощью Spring MVC и Java или с помощью Javascript, или у вас есть какие-либо другие предложения?


java web spring-mvc forms encryption-symmetric
person red.and.black    schedule 21.05.2016    source источник
comment
1. Да, для работы на стороне клиента в значительной степени должен быть JS. 2. Вы беспокоитесь об утечке не алгоритма шифрования (если он хороший, это не имеет значения), а ключей. 3. Если вы беспокоитесь о безопасности при передаче, используйте HTTPS.   -  person jonrsharpe    schedule 21.05.2016
comment
Спасибо за быстрый ответ @jonrsharpe. Тогда зачем мне шифровать с помощью TEA, если я использую HTTPS с незашифрованными полями для первого перехода на веб-сервер? Я не специалист по протоколу HTTPS, поэтому буду рад, если кто-нибудь объяснит мне лучше.   -  person red.and.black    schedule 21.05.2016
comment
Потому что, очевидно, вы хотите отправить его в зашифрованном виде по электронной почте; Я не знаю почему, вы пришли с этим требованием. HTTPS защитит переход от клиента к вашему серверу, тогда TEA защитит электронную почту от сервера к продавцу.   -  person jonrsharpe    schedule 21.05.2016
comment
Использование симметричного шифрования через HTTP или TCP не обеспечивает реальной безопасности, поскольку ключ должен быть отправлен вместе с зашифрованным текстом. Это не более чем запугивание. Злоумышленник, наблюдающий за трафиком, может напрямую расшифровать зашифрованный текст, который вы пытаетесь защитить. Вам необходимо создать безопасный канал между браузером и сервером. Обычный способ сделать это — использовать HTTPS с правильно подписанным открытым ключом (сертификатом).   -  person Artjom B.    schedule 21.05.2016
comment
Привет @Artjob B. На самом деле я не отправляю сам ключ, а подсказку, как найти ключ в общей библиотеке, которая была предоставлена ​​​​на другом носителе. Но проблема в том, что я хочу, чтобы шифрование выполнялось на стороне клиента, а не на стороне сервера (с доступом только к двоичному коду, но без доступа к исходному коду).   -  person red.and.black    schedule 21.05.2016
comment
Любое другое предложение?   -  person red.and.black    schedule 22.05.2016

Ответы (1)


arrow_upward
0
arrow_downward

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

Здесь есть достойное обсуждение криптографии с открытым ключом в JavaScript: варианты асимметричного шифрования для JavaScript?

person EJoshuaS - Reinstate Monica    schedule 20.07.2016