Лучшая практика для защиты полезной нагрузки запроса между клиентом / сервером во время узла передачи после запроса / экспресс-JS

Question

Сужая до широкой темы, у меня есть конкретный вопрос (может быть, немного "шляпа из фольги").

Этот вопрос касается наилучшей практики защиты данных, передаваемых в почтовом запросе между клиентом и сервером. Фон - это веб-приложение, которое я разрабатываю, чтобы узнать больше об узлах и выражениях js.

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

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

const resp = await axios.post("http://someurl.com/login", {client:email, pw:pw});

в инструментах разработчика Chrome на вкладке сети я могу видеть полезную нагрузку запроса. В примере это выглядит так:

{client:"some email address", pw:"some password"}

Было бы лучше передать полезную нагрузку, уже зашифрованную / закодированную? Затем он расшифровывается / дешифруется на сервере? Для передачи конфиденциальной информации лучше использовать подписанный файл cookie?

План, если я когда-нибудь выполню все это, это использовать Let'sEncrypt для HTTPS.

Разумно ли полагаться только на HTTPS для защиты этого типа полезной нагрузки?

Для справки, на экспресс-сервере пароль хешируется и сравнивается с хешированной версией из базы данных. Я читал о шлеме и csurf и собираюсь использовать их и в конечном продукте. В этом ответе содержится много полезной информации. Это невероятно удивительно и говорит о важности HTTPS через HTTP.

Любые дополнительные ссылки / мысли / практические соображения приветствуются.

Answer 1

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

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

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

Надеюсь, это поможет.