#web-services #security #rest #jersey #restful-url
#веб-службы #Безопасность #rest #джерси #restful-url
Вопрос:
позвольте мне описать простой сценарий:
Существует ресурс rest, представленный этим URI: /api/messages/{userid} . После входа пользователя в систему отправляется запрос, передающий этот URI «userid» (зарегистрированный пользователь). Таким образом, как только пользователь входит в систему, он получает свои собственные сообщения на основе своего идентификатора.
Если пользователь еще не зарегистрирован, URI не отображается (существует фильтр аутентификации).
Проблема в том, что если уже зарегистрированный пользователь обнаружит этот uri, он может отправить запрос, передающий другой идентификатор, что приведет к проблеме безопасности, поскольку он сможет получать сообщения от другого пользователя (просто передавая любой случайный идентификатор).
Можете ли вы предложить какую-либо модель безопасности для предотвращения этого недостатка безопасности? (я считаю, что это, скорее всего, сквозная проблема).
Заранее спасибо!
Комментарии:
1. тогда не выполняйте авторизацию только на основе URL-адреса. используйте файл cookie для передачи данных аутентификации. без этого файла cookie URL-адрес был бы бесполезен.
Ответ №1:
Просто с моей точки зрения, конечная точка должна либо (а) возвращать только те сообщения, которые видны вошедшему в систему пользователю, либо (б) возвращать сообщения только в том случае, если вошедший в систему пользователь совпадает с идентификатором пользователя в URI. Какой из них зависит от ваших бизнес-правил.
Комментарии:
1. Вы предлагаете получать идентификатор пользователя на стороне сервера при каждом запросе, передающем этот идентификатор на сервисный (бизнес) уровень? Принимая некоторые принципы веб-служб Rest, сервер полностью не имеет состояния, и я хотел бы реализовать это скорее как сквозную концепцию. Мой вопрос в том, как это реализовать таким образом.
2. @MikeH я не понимаю, как мой ответ признан недействительным из-за этой проблемы. В вашем API должен быть какой-то способ отслеживания того, кто делает запрос: заголовок авторизации, ключ API и т. Д. Это сообщит вам, кто является зарегистрированным пользователем. Состояние не требуется. Если вы выполните (b), у вас может быть фильтр, проверяющий входящие URI для идентификатора пользователя и сравнивающий его с именем пользователя. Я думаю, это было бы сквозным.
3. @MikeH Ах, я вижу, у вас нет никакого способа отследить, кто вошел в систему. Это ошибка. Я настоятельно рекомендую вам не писать собственную архитектуру веб-безопасности. Используйте что-то, что уже существует: базовую аутентификацию, OAuth 2 и т. Д.
4. Как вы рекомендуете реализовать это с помощью OAuth 2 для решения упомянутого сценария?
5. lookazis -> porterhead. blogspot.co.uk/2014/05 /…
Ответ №2:
В конечной точке вы можете проверить пользователя, а затем посмотреть, соответствует ли этот идентификатор пользователя параметру pathнахождение идентификатора пользователя по имени пользователя так же просто, как выбор идентификатора с использованием имени пользователя из базы данных
import javax.ws.rs.core.Context;
import javax.ws.rs.core.SecurityContext;
import ... blablabla;
@GET
@Path("messages/{userid}")
public Response getMessages( @PathParam("userid") int userId, @Context SecurityContext context ) {
String username = context.getUserPrincipal().getName();
int id = getIdFromName(username); // define this yourself
if(userId==id) {
// output the message list
List<Message> msgs = getDemMessagesGURL(); // define this yourself
return Response.ok(new GenericEntity<List<T>>(msgs) {}).build();
} else {
// output Forbidden(403)
return Response.status(403).build();
}
}
и с помощью oauth вы можете использовать фильтр сервлетов для установки участника-пользователя на основе подписи oauth