Как не дать настольным приложениям имитировать запросы браузера? - PullRequest
0 голосов
/ 18 января 2020

У меня есть два веб-приложения, написанные на .netcore, App 1 обслуживает контент html и App 2 - это API, который обслуживает запросы Javascript, оба находятся в одном решении, но у каждого свой порт конечно. Мой сценарий - браузер возвращает веб-сайт из App 1, который включает в себя форму регистрации и javascript доступ к функциям регистрации в API по адресу App 2.

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

Поэтому я добавил заголовок Authorization, чтобы все функции API требовались для авторизации доступа к токену JWT bearer.

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

1 - если я добавлю токен доступа в ответ от App 1, чтобы javascript мог использовать его для доступа к App 2 любое другое приложение может легко получить его и скопировать, вставить его в свое приложение и получить доступ к API.

2 - Если я не закодирую токен в ответ App 1 и вместо этого javascript доступ к маршруту, который генерирует токен, тогда любое приложение может сделать то же самое, потому что они могут имитировать одинаковые заголовки запроса браузера. и тогда CORS будут бесполезны.

так что мне делать?

1 Ответ

1 голос
/ 22 января 2020

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

Это правда, некоторые клиенты http (например, curl) могут изменять заголовки Origin при выполнении запроса к серверу. Таким образом, CORS не должен быть вашей только мерой безопасности для защиты вашего приложения 2.

Поэтому я добавил заголовок авторизации, чтобы все функции API требовались для авторизации JWT токен на предъявителя для доступа.

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

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

В общем, ваше приложение 1 (я предполагаю, что это веб-клиент на основе JavaScript) не должно содержать токена при загрузке, вместо этого оно должно сделать вызов для входа в приложение 2 API и получить токен jwt.

Приложение 1 может кэшировать токен и использовать его при вызове защищенных API в приложении 2.

...