Как проверить, является ли вызывающая сторона веб-службы моим веб-сайтом?

Question

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

Answer 1

Подпишите токен (я рекомендую использовать HMAC как минимум с SHA-1). Этот сайт предоставляет пример кода для ASP.NET; Я не использую .NET, поэтому я не могу проверить этот код.

Предоставьте токен вместе с его подписью HMAC клиенту. Попросите клиента передавать его обратно в веб-службу при каждом запросе.

В веб-сервисе просто проверьте подпись HMAC.

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

Рефереров недостаточно для обеспечения безопасности; они могут быть удалены прокси или подделаны вредоносными клиентами.

Answer 2

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

Answer 3

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

Answer 4

Я бы не позволил веб-браузеру позвонить в сервис вообще.

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

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

Answer 5

Вы можете защитить с помощью обратного прокси-сервера - который пропускает трафик только с определенного IP-адреса (или что-то в этом направлении).

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

Можете ли вы защитить веб-сервис с помощью проверки подлинности с помощью форм? Только пропустить известных существ через?

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

Если вам нужно действительно безопасное решение, вы можете поговорить со специалистом по безопасности - при условии, что вы не получите здесь хорошего ответа; заставить вещи работать - это одно, а отстранить плохих парней - это другое дело:)

Answer 6

Как уже отмечалось, вы можете проверить реферер HTTP, но этот метод проверки смехотворно легко подделать с помощью такого инструмента, как Tamper Data: https://addons.mozilla.org/en-US/firefox/addon/966

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

Answer 7

Проверьте строку реферера браузера клиента.

исправлена ​​опечатка, спасибо Носредна