Как зашифровать АПИ токен на стороне клиента?

Question

[Mishcake]

Привет! В предыдущем вопросе спросил, можно ли непосредственно со страницы с формой отправлять АПИ-запросы и проверять какие-то условия.

Оказалось, что можно, но в запросе нужно обязательно передавать токен партнёра, без которого не будет ответа. Но с этим токеном можно сделать кучу всего в сервисе, с которым я связываюсь по АПИ и вставлять этот токен прям в код страницы мне как-то боязно.

Обращаюсь к АПИ посредством js и fetch.

P.S. Как альтернативу вижу хранить значение токена на внешнем хосте в php-скрипте, который будет проверять, с какого адреса будет приходить запрос и если он соответствует моему, то после отправит его в АПИ, потом вернёт обратно на страницу, где JS на основе ответа сделает что-то.

Или юзать base64_encode() и base64_decode() на сервере с php.

Как лучше поступить, подскажите, пожалуйста.

Answer 1

[Иван Шумов]

Не надо так делать. Стоит выбрать правильную авторизацию в API. Не знаю что у вас за система, но что мешает сделать обертку, в которую пускать пользователей по из персональным токенам или сессиям?

Comments

[Mishcake]

Кивач?..

Про обёртку и пускать пользователей не совсем понял.

Цель обращения к АПИ при оформлении заказа пользователем — если в поле ввода имейла есть значение, то его надо проверить на сервисе и если такой имейл там есть, сделать какие-то действия в форме (убрать какие-то поля, установить значения по умолчанию и т.д.)

[Иван Шумов]

Mishcake, опечалился, исправил. Основная логика в том что креды от стороннего сервиса действительно нельзя выставлять на фронт и поэтому проблема решается давно и легко - пишем собственный бэкэнд, а на фронт выставляем свой API с лимитированным функционалом и пускаем туда только пользователей своего ресурса

[Mishcake]

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

[Иван Шумов]

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

[Mishcake]

Иван Шумов, ну а если без отдельного своего АПИ вариант с php-прослойкой, которая будет проверять источник запроса (адрес формы заказа) + какие-то скрытые данные и после отправлять запрос к АПИ стороннего сервиса - это нормально?

[Иван Шумов]

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

[Mishcake]

Иван Шумов, я не до конца понимаю весь алгоритм действий...

Регистрировать пользователей - имеется в виду регать их через Auth0 (допустим) и хранить где-то инфу о пользователях?

Просто либо я неправильно сформулировал вопрос, либо не до конца понимаю масштаб проблемы.

Мне ведь просто надо реализовать сценарий, когда "если при загрузке страницы в поле email есть value (там где лежит форма оформления заказа, работает автологин - это конструктор и СРМ в 1 лице), то взять value, отправить запрос в базу по АПИ, и если есть совпадение, то скрыть поле с выбором типа услуги".

Для реализации этого нужно делать обёртку в виде своего кастомного АПИ или юзать Auth0?..

[Иван Шумов]

Mishcake, Auth0 это просто как вариант. Этот Identity Provider полностью снимает с вас все управление пользователями и вы получаете только JWT токен, который нужно будет проверить. Уникально для каждого пользователя.

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

[Mishcake]

Иван Шумов, мне не плевать на безопасность, поэтому как только я понял, что токен будет висеть в открытом доступе у всех на виду, сразу начал копать, как его защитить)

Т.е. по глобальной логике, каждый заходящий на страницу пользователь или гость будет получать свой уникальный токен для дальнейшей работы с одним глобальным токеном, который даёт доступ к сервисному АПИ, верно?

[Иван Шумов]

Mishcake, почти. Пользователи будут получать свои временные токены для работы с вашим сервисом, который в свою очередь будет безопасно работать с тем самым секретным. Разумеется пользователи не будут знать про эти все токены, это будут делать скрипты.

[Mishcake]

Иван Шумов, спасибо, покопаю завтра Auth0, надеюсь, разберусь :D

Answer 2

[Ninazu]

Ничего шифровать не нужно. Алгоритм такой
1. Берете https://github.com/Valve/fingerprintjs2
2. Отправляете результат его работы c каждым запросом
3. Авторизируетесь и получаете токен который на сервере привязан к fingerprint и IP
4. При получении запроса с токеном и fingerprint, проверяете наличие токена в своем хранилище, и соответсвие токена IP и fingerprint которые пришли с клиента
5. Если не прошла проверка, заставляйте авторизироваться снова.

P.S. IP часто динамический. Так что учитывайте это. Например много людей используют мобильный интернет. Плюс нужно понимать что может быть несколько устройств. Пользователь может зайти с планшета, телефона и ПК

Comments

[Mishcake]

Ох, мозги так и скрипят)

Подскажите, пожалуйста, что значит "отправляете результат его работы с каждым запросом"? Каким запросом? Куда отправлять результат?

Что значит "3. Авторизуетесь и получаете токен на сервере", если мне сервис выдал фиксированный токен, который не меняется?

P.S. Вопросы, наверное, сильно обобщённые... Где можно почитать детальнее про общую логику такой безопасности? Как составить гугл-запрос?)

[Ninazu]

Так бы и сказали что сервер не ваш)

Тогда правильней всего будет организовать свой прокси сервер. Который будет общаться со сторонним, получать его токен. И передавать в клиент его как Cookie с Secure и HTTP флагом, чтоб ваш и другие скрипты не имели к нему доступа. А браузер сам отправлял запросы на ваш прокси с куками, который в свою очередь вытягивал его из кук, и отправлял запрос на удалённый сервер, и отдавал ответ стороннего сервера как свой

Client -> ProxyServer(Cookie -> Token) -> APIServer -> ProxyServer(Token -> Cookie) -> Client

Всё остальное от лукавого

Можно еще больше упоротся, и не передавать токен в виде кук на клиент. А хранить его на ProxyServer допустим в сессиях, а куку использовать только для восстановления сессии. Таким образом. Даже если хацкеры завладеют физическим доступом к компьютеру жертвы, и смогут вытащить защищенные куки руками или еще как, они не получат сам токен. Но смогут при этом и без него выполнять все действия от имени пользователя через Proxy

Answer 3

[Владимир Коротенко]

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

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

Comments

[Mishcake]

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

[Владимир Коротенко]

Mishcake, Всю логику не нужно, просто тот код который использует этот ключ реализуйте на php.

Answer 4

[⚡ Kotobotov ⚡]

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

Comments

[Mishcake]

Ну просто меня беспокоит то, что это форма заказа, внутри которой будет лежать видный для всех код:
const token = 'asdjhgczvbxcvmnbxcvmxcv';

При желании вы сможете посмотреть, какой я делаю запрос к АПИ (не указал сразу, но я делаю запрос к АПИ через js и fetch) и сделать его самостоятельно. Вот это и пугает.

Обновлять токен тоже не вариант, на стороне сервиса его генерируют 1 раз и дают мне :(

[⚡ Kotobotov ⚡]

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

[Mishcake]

⚡ Kotobotov ⚡, мне не надо каждому пользователю давать токен, я на своей стороне просто хочу проверять введённую почту и на основании ответа менять страницу)