защищать код в расширении google chrome

Question

Я хочу написать расширение google chrome, которое должно отправить запрос на мой сайт, чтобы отправить и получить некоторые данные, поэтому на самом деле я должен сделать запрос ajax, как это написано здесь https://developer.chrome.com/extensions/xhr.html

var xhr = new XMLHttpRequest(); 
xhr.open("GET", "http://api.example.com/data.json", true); 

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

EDIT:

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

Thanks

Answer 1

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

Ваше расширение Google просто требует, чтобы вы ввели пароль, прежде чем пытаться использовать AJAX для связи с вашим сервером.

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

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

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

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

Во время этого внеполосного процесса вы также можете предоставить пользователю уникальный URI (точка доступа API), которая действительна только для аутентифицированного сеанса (например, https://api.totally-cool-extension.com/api/ijyeDvB5dYvSiWG97OLuTAoNWwbhuZ0/). Любые запросы на ваш сервер на ДРУГИХ URI просто не будут работать. Однако это не теоретически сильно отличается от использования той же точки доступа API и наличия хорошего пароля. Он просто изменяет количество мест в вашей архитектуре, которые будут выполнять проверки подлинности и/или авторизации.

<aside> Мое голосование будет заключаться в том, чтобы уменьшить количество точек авторизации/аутентификации как можно меньше, чтобы вы могли потратить больше времени на то, чтобы получить одно место, а не иметь несколько мест и, возможно, несколько логических недостатков или других вещей, которые может привести к уязвимости. </aside>

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

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

Я знаю, что вы искали здесь серебряную пулю, но ее не существует.

Answer 2

Я думаю, что вы делаете это неправильно. Вы никогда не должны доверять тому, что происходит на ПК пользователей Интернета. Никогда!

Переместите линию доверия на один шаг внутрь, сделайте свой API общедоступным, а затем создайте безопасность, где у вас есть идеальный контроль - серверная сторона.

Answer 3

я не мог получить правильный аспект вашего случая использования

Немного Очки:

• Ваш код расширение always прослеживаемость (Любой, кто установил расширение может просматривать код)
• Если вы ищете безопасность через complicated or obfuscated coding patterns, вы в конечном итоге замедляете понимание процесса не в целом.
• Если ваша цель заключается в том, чтобы пользователи, установившие расширение, имели доступ к инертным всем другим пользователям (кто приобрел незаконный доступ или загруженный и отредактированный код) имеют сеанс общего доступа за установку.

Пожалуйста, объясните дальнейший прецедент, чтобы я мог помочь вам лучше.