Должны ли API иметь пользовательскую информацию? - PullRequest
0 голосов
/ 16 мая 2018

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

Теперь я понял, что мне нужна конечная точка с пользовательской информацией. @GetMapping("/user/{username}")

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

Есть идеи?

Ответы [ 4 ]

0 голосов
/ 16 мая 2018

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

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

Также вы можете использовать что-то вроде Keycloak. Который я рекомендую всем. Это легко реализовать и документация хороша.

Вы должны прочитать это https://auth0.com/blog/angularjs-authentication-with-cookies-vs-token/ и это https://auth0.com/blog/cookies-vs-tokens-definitive-guide/

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

В самом упрощенном виде, когда вы входите в систему с помощью файлов cookie сессий, вы делаете то, что вы создаете cookie на стороне браузера / клиента и сеанс на стороне сервера, у которого есть переменная, для которой они его используют. сравнить, если пользователь вошел в систему или нет. И сервер знает, что сеансы принадлежат пользователю. Это похоже на токены, после входа в систему вы получаете токен, и когда вы отправляете запрос обратно, вы можете отправить свой токен, и именно так сервер узнает, что вы вошли в систему. Сервер знает, что токен принадлежит пользователю.

Сказать, что отправка зашифрованного пароля в методе post или get - это действительно плохая идея. Если вы отправляете и кодируете пароль в методе get например

http://myserver.com/user/myuser?password="#4$%encodedeapassword&/%EFDASF"

Тогда вы, вероятно, получите этот зашифрованный пароль и декодированный на вашем сервере.
Если я рассматриваю это как хакер, я могу сказать, что мне не нужен ваш пароль для входа в систему. Мне просто нужен ваш URL, я думаю, что если кто-то просто просматривает историю вашего браузера, может войти в систему. Итак, вы не делитесь своим компьютером со всеми. Ну, тогда кто-то со сниффером может увидеть этот адрес и может войти в систему, или системный администратор, просто просматривающий прокси-соединения, или ваш провайдер знает ваш логин. Если вы используете метод Post вместо метода GET, вы делаете его немного более безопасным, но любопытный системный администратор или кто-то с прокси-сервером будет знать ваш хэш. В этом случае знание вашего хеша равнозначно знанию вашего пароля.

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

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

В вашем случае, как только вы войдете в систему, вы можете указать в своем файле web.xml (есть и другие способы), что конечная точка / пользователь / * должна быть защищена, поэтому ее может видеть только зарегистрированный пользователь.

Так что теперь только зарегистрированные пользователи могут видеть эту конечную точку. Если вы хотите, чтобы только администраторы видели, что в зависимости от платформы у вас есть обозначения, такие как @RolesAllowed ()

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

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

0 голосов
/ 16 мая 2018

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

0 голосов
/ 16 мая 2018

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

Если вы ограничите доступтолько зарегистрированному пользователю, это все еще плохая идея IMO.

Вы можете скрыть определенные поля довольно просто: https://stackoverflow.com/a/40913991/4813549 показывает, как это сделать для GSON, https://stackoverflow.com/a/14708961/4813549 имеетответ для Джексона

0 голосов
/ 16 мая 2018

Первый вопрос, который вы должны задать: какова цель конечной точки?

Мы можем перечислить множество сценариев, в которых вы можете использовать этот подход.


Представьте, что пользователь A являетсязапрос информации о пользователе B?

Итак, что вам нужно сделать: создать конечную точку /user/<username> или /user/<user id> для возврата информации о пользователе.Но имейте в виду, что только зарегистрированный пользователь может получить доступ к этой конечной точке, и вы ДОЛЖНЫ сделать некоторую политику безопасности.Все пользователи могут видеть всю информацию пользователя?Только администратор может видеть информацию о пользователе?


Представьте, что тот же самый пользователь запрашивает его информацию

Почему, используя /user/username, вы можете справиться с этим простым /user/me и вернутьЗарегистрированная информация о пользователе!


Помните

Никогда не отправляйте пароль в URL !!!Вы ДОЛЖНЫ создать и конечную точку /login отправить username и password в качестве тела сообщения, затем вы можете вернуть JWT или выбрать другую стратегию входа в систему

Я видел, что вы используете Spring, поэтому поищите шаблон аутентификации в Spring и интегрируйте его с вашим Angular.Наилучшим подходом для Angular является использование JWT.

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