Защита веб-службы от «XML-инъекции»

Question

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

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

Вопрос в том, каков «лучший способ» предотвратить «XML-инъекцию» (если это так называется), когда кто-то может перехватить отправленный веб-запрос и изменить XML с намерением просмотреть данные конкурентов.

Единственный метод, который я до сих пор придумал, - это поддерживать клиентскую иерархию на стороне сервера (например, клиент A / B / C является частью франшизы A), чтобы мы знали, кто является частью какой франшизы, и явно проверяем перед данные получены.

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

Answer 1

У вас, кажется, две проблемы.

Остановка перехвата HTTP-запроса и использование учетных данных третьей стороной

Вопрос в том, чтоэто «лучший способ» предотвратить «XML-инъекцию» (если это так называется), когда кто-то может перехватить отправленный веб-запрос и изменить XML с целью просмотра данных конкурентов.

Это будет атака «человек посередине».

Решение простое: используйте шифрование, передавая данные по HTTPS вместо простого HTTP.

Остановка одного клиента издоступ к данным другого клиента без разрешения

Единственный метод, который я до сих пор придумал, - это поддерживать клиентскую иерархию на стороне сервера (например, клиент A / B / C является частьюФраншиза А), поэтому мы знаем, кто является частью франшизы, и явно проверяем ее перед извлечением данных.

Это другая проблема, и это правильный подход к ее решению.

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

Answer 2

Не пытайтесь уложить дополнительный уровень сложности поверх «сломанной» проверки учетных данных, которая у вас уже есть.Вместо этого исправьте проверку учетных данных.

В чем проблема?«Идентификационный токен», который вы используете для проверки доступа, является идентификатором компании (его хеш, но это не имеет никакого значения).

Как это исправить?Просто не используйте идентификатор компании - используйте что-то лучше.

Так, например: когда кто-то проходит аутентификацию на вашем веб-сервисе, не давайте ему маркер авторизации, основанный на идентификаторе их компании.Дайте им токен аутентификации (давайте создадим здесь абстрактную сущность) «домен доступа».Пусть каждая компания в вашей базе данных будет отображаться в соотношении один ко многим с любым количеством «доменов доступа».

Всякий раз, когда кто-то запрашивает данные, смотрите, какие домены доступа включают эти данные (например, проверьте, какие доменыКомпания, данные которой запрашиваются в).Если маркер учетных данных разрешает доступ к любому этих доменов, предоставьте данные.

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

Конечно, обратите внимание, что:

• Эта система контроля доступане защищен от атак доверенных пользователей. Если не существует других механизмов, то, что мешает клиенту перебивать маркер аутентификации, который он отправляет вам, пока он не совпадет с хешем другого идентификатора компании (или домена доступа) иони получают доступ к этим данным?
• Как говорит Дэвид, он также не защищен от атак «человек посередине» или даже от пассивного прослушивания. Следуйте его советам и используйте HTTPS длявыставить свои услуги.Это легкая задача.