Как хранить зашифрованные данные в плагине?

Question

[maksam07]

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

Comments

[Надим]

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

[maksam07]

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

[Надим]

Максим Компаниец, разбей данные на небольшие части и запакуй эти части в zip-архив с паролем, его потом и храни в браузере. Когда понадобится достать данные из какого-либо архива, есть 2 решения:
1. Запросить со своего сервера пароль для конкретного архива и потом в самом браузере распаковать архив, разумеется у каждого архива свой пароль
2. Отправить сам архив на сервер, чтобы сервер распаковал его и вернул результат, в этом варианте не придется передавать пароль в браузер

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

[maksam07]

Надим Закиров, так в любом же случае клиент увидит запросы и сможет сам их подменить, чтобы получать данные вне зависимости от плагина

[Надим]

Максим Компаниец, от такого не существует защиты, шифрование поможет только в том случае, если кто-то банально угнал профиль браузера. Даже если злоумышленник этот профиль потом будет ковырять, сессионный токен к тому времени уже истечет и расшифровать данные он не сможет.

Answer 1

[Николай Савельев]

Это невозможно. Всё, что на клиенте, доступно всем.
Можно лишь усложнить декодирование скрипта через обфусцирование, но это ненадолго.

Comments

[maksam07]

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

[Николай Савельев]

Максим Компаниец, Если использовать авторизацию, то тогда можно сделать асимметричное шифрование, только надо придумать где и как хранить закрытый ключ, чтобы плагин мог иметь к нему доступ, а злоумышленник не мог

[maksam07]

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

[Николай Савельев]

Максим Компаниец, защита от нагрузки - это однозначно задача бэкенда. Только там её надо ставить.
Все критичные задачи ВСЕГДА делаются на бэкенде. Задачи фронта всегда попроще

[maksam07]

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

Answer 2

[rPman]

Да, если этот ключ - ключ шифрования, которым будет зашифрована вся критичная информация, которая хранится в браузере расширением.

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

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

Расшифрованные данные и сам ключ шифрования не должны никуда записываться и должны храниться только в оперативной памяти.