Защита моего веб-сайта с помощью ключей API в локальном хранилище
Я намеревался выпустить общедоступный веб-сайт, который хранит конфиденциальную информацию на стороне клиента с использованием локального хранилища, такого как ключи API. Переменные, хранящиеся в локальном хранилище, используются в моих сценариях PHP.
Я подумал, поскольку у него был сертификат SSL, этого было бы достаточно для хранения конфиденциальной информации, такой как ключ API и секрет.
На моем сайте не будет рекламы. На сайте также есть база данных MySQL.
Я собираюсь настроить обычного пользователя для чтения данных, поскольку пользователю не нужны права записи (это сайт только для чтения). Проблема в том, что если они позже перейдут на вредоносный веб-сайт, они могут извлечь эти ключи локального хранилища (возможно, с помощью сценария) и потенциально взломать моего потребителя.
При создании и использовании ключей на моем веб-сайте имена очень общие, поэтому было бы сложно определить происхождение ключей или их назначение.
Это неправильно - поступать так с моим потребителем?
@ hbennet3, здесь определенно проблема, но я думаю, что здесь отсутствует часть, которая действительно позволяет использовать ключи API и какова их область действия? Это ключи к API ваш и привязаны ли они к конкретному пользователю?
Нет, это ключи API для различных веб-сайтов. Я перезваниваю на их api, используя ключи api этих веб-сайтов.
Ответы 1
Да, это неправильно. Это означает огромную утечку безопасности. Представьте себе случай, когда любой вредоносный Javascript запускается в браузере по любой причине. Он сможет прочитать содержимое localStorage и отправить его хакеру.
Это может быть вызвано проблемой веб-сайта, например, возможностью XSS-инъекции, но расширение браузера с вредоносным содержимым может добиться того же. Хотя XSS-инъекция может быть защищена, если разработчики сайта будут осторожны, то какие расширения браузера будут устанавливать пользователи, не зависит от вас. Избегайте этого подхода. Безопасно храните конфиденциальные данные на сервере.
Итак, мой сайт построен на ajax. После получения ключей api от пользователя они просто нажимают кнопку включения на веб-странице, и все обрабатывается за них. Они получают изменения, внесенные на веб-страницу. Будет ли плохой практикой после загрузки страницы, что они будут оставаться включенными на время своего пребывания, чтобы хранить эти переменные, даже переменные сеанса? Или мне нужно каждый раз делать запрос на получение ключей api из базы данных?
@ hbennet3 - крайне плохо хранить секретные данные в переменных Javascript, но вы можете хранить часто запрашиваемые данные в сеансе на стороне сервера. Конфиденциальные данные не должны отправляться в браузер, так как браузер может быть небезопасным. Если вы храните конфиденциальные данные на стороне сервера, то в случае взлома браузера хакер сможет выдать себя за пользователя на вашем сайте, но не сможет получить любую другую конфиденциальную информацию, и когда сеанс будет разрушен, пользователь сохранит его или ее пользователя, даже если сеанс был разрушен.
@ hbennet3 также, когда пользователь меняет свой пароль, вам нужно будет попросить его или ее ввести старый пароль, чтобы избежать исключения ваших пользователей из их собственных учетных записей даже в случае взлома их браузера. Однако нет ничего плохого в том, чтобы хранить часто загружаемые данные в переменных сеанса на стороне сервера (а не на клиенте), однако я советую вам не делать этого, пока это не станет необходимостью.
так что на практике было бы что-то более безопасным, чтобы сделать следующее ... Может ли мой пользователь войти на веб-сайт и после успешного входа в хранилище в переменных SESSION их ключи api в моем сценарии PHP и поддерживать этот сеанс на протяжении всего сеанса?
@ hbennet3 это намного безопаснее, чем хранение этих значений в localStorage, но не так безопасно, как запросы к базе данных. Однако это разумный компромисс, если он вам нужен. Если мой ответ решил вашу проблему, вы можете принять его.
"поскольку у него был сертификат SSL" Многие люди думают, что SSL защитит от хакерских атак. Но SSL только шифрует / дешифрует данные между сервером и клиентом (-ами). Это означает, что такие атаки, как SQL-инъекция, кросс-сторонние сценарии и другие, все равно будут работать .