Как защитить ajax-данные?

Question

[обычный чел]

Клиент отправляет на сервер ajax-запрос и получает в ответ json-данные.

При использовании HTTPS будут ли защищены (зашифрованы) эти данные, и если да то насколько надежно?

У меня нет задачи делать приложения для банков или магазинов, я делаю например сайты-визитки, лендинги, соцсети типа жж - то есть такие приложения которые вобщем-то нет смысла взламывать и взлом не смертельно опасен...

Мне нужен нормальный уровень защиты при минимальных затратах и попроще.

Поясните пожалуйста какие недостатки такого решения и для каких проектов годится такая защита.

Answer 1

[AUser0]

При использовании HTTPS будут ли защищены (зашифрованы) эти данные, и если да то насколько надежно?

На столько-же надёжно, на сколь надёжно защищены клиенты банковских онлайн-сайтов и банковских же приложений на смартфонах.

Одним словом, это лучший способ защиты, особенно когда

нужен нормальный уровень защиты при минимальных затратах и попроще

Поясните пожалуйста какие недостатки такого решения и для каких проектов годится такая защита.

В недостатках чуть большая математическая нагрузка на сервер/браузер (шифровка/дешефровка), зато годится для любых, АБСОЛЮТНО ЛЮБЫХ проектов ценой выше 0 долларов. Кроме АНБ-шных, там потребуют полтора-два слоя защиты.

Answer 2

[xmoonlight]

и если да то насколько надежно?

Ни на сколько.

Есть 2 простых правила:
1. Используйте всегда свой алгоритм шифрования.
2. Никогда не доверяйте каналу передачи данных.

Как защитить?
1. При регистрации, внутри ссылки на e-mail, передайте временный токен клиенту.
2. По клику по ссылке (подтверждение почты) - обменяйте этот токен на приватный пользовательский "ключ" и сохраните "ключ" в LocalStorage и в БД на сервере.
3. При отправке/приёме важных данных - шифруйте/расшифровывайте всё этим "ключом" как на клиенте, так и на сервере. (периодически - обновляйте "ключ")
4. Всегда добавляйте два дополнительных параметра: "соль" в виде случайного набора символов (для изменения шифрованного сообщения с одинаковыми данными) и метку времени (для контроля давности запроса и предотвращения попытки применения прошлых запросов).

Comments

[Владимир Дубровин]

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

[xmoonlight]

Владимир Дубровин, никто не говорит о ЗАМЕНЕ! Я говорю ИМЕННО ПРО ДОБАВЛЕНИЕ!

[обычный чел]

Владимир Дубровин, для каких целей годится AJAX+HTTPS ?

[Владимир Дубровин]

datarmatan, это неправильный вопрос, на него невозможно ответить, можно ответить на вопрос годится ли он для ваших целей. В целом, вы можете считать, что стоимость непосредственной атаки на "классический" https это порядка 100000 долларов, т.е. они доступны всем крупным игрокам и правительственным агентствам + https не защищен на MitM к серверу, т.е. вас может атаковать ваш хостер или провайдер или канальный оператор. В большинстве случаев это достаточный уровень защиты, т.к. хостер может вам что-то внедрить непосредственно на сервер, и наверняка имеются более "дешевые" способы атак для других сторон, например вынести ваш сервер по поддельным документам.

А если вы реализуете свой клиент с самоподписанным сертификатом и пиннингом (или сделаете соответствующую конфигурацию, например, Firefox убрав в ней доверие ко всем сертификатам кроме вашего) и уберете на серверной стороне все лишние cyphersuit'ы (оставите, например, ECDHE-ECDSA-AES256-GCM-SHA384 или ECDHE-ECDSA-CHACHA20-POLY1305 если не верите правительственным агентствам), то получите весьма надежную в плане криптографии конфигурацию.