Защита моей службы REST, которую я буду использовать на стороне клиента, для использования другими

Question

Предположим, что я успешно создал свой REST-сервис и возвращаю результаты json.

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

Затем Компания A началаиспользуя мой сервис, и я дал им ключ API.

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

Например, предположим, что мой URL-адрес службы выглядит следующим образом:

www.myservice.com / service? apikey = {key_comes_here}

Компания A использует этот сервис со стороны клиента, как показано ниже:

www.companyA.com / services / service1.ashx

Затем они начинают использовать его на стороне клиента.

Компания A защитила здесь ключ API.Все в порядке.

Но здесь есть другая проблема.Кто-то еще может получить www.companyA.com/services/service1.ashx URL и начать пользоваться моим сервисом.

Как запретить другим делать это?

Для записи я использую веб-API WCF для создания своих служб REST.

ОБНОВЛЕНИЕ:

HttpHandler компании A (вторая ссылка) только смотрит на заголовок хоста, чтобы увидеть, идет он от www.companyA.com или нет.но я могу легко подделать его.

ОБНОВЛЕНИЕ 2:

Есть ли какой-либо известный способ реализации токена для URL.Например, предположим, что www.companyA.com/services/service1.ashx будет содержать параметр строки запроса, представляющий TOKEN, чтобы HttpHandler мог проверить, является ли запрос правильным.

Но здесь есть много вещей, о которых я думаю подумать.

Answer 1

То, что вы описываете, обычно называют «прокси-сервером» - общедоступная страница компании доступна всем, и за кадром она делает правильные звонки в вашу систему. Нередко приложения используют прокси-серверы для обеспечения безопасности - например, политика одного и того же происхождения означает, что ваш javascript не может делать вызовы Ajax, скажем, в Amazon, - но если вы проксируете его в своей собственной системе, вы можно обойти это.

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

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

Answer 2

Вы всегда можете потребовать, чтобы клиент прошел аутентификацию, используя HTTP Basic Auth или какую-либо другую пользовательскую схему. Если ваш клиент требует, чтобы пользователь вошел в систему, вы можете, по крайней мере, запретить пользователям получать URL-адрес www.companyA.com/services/service1.ashx, так как они должны будут войти в систему, чтобы узнать об этом.

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

Что касается идеи токена URL, которую вы упомянули в обновлении 2, она может работать примерно так. Представьте, что каждый месяц для работы URL-адреса www.companyA.com/services/service1.ashx требуется новый токен, например, www.companyA.com/services/service1.ashx?token=January. Когда наступит февраль, «январь» перестанет работать. Сервер должен знать, чтобы принимать только текущий месяц, и клиент должен знать, чтобы отправить токен (определяется в момент загрузки веб-страницы клиента с сервера в браузере)

(Весь псевдокод, так как я не знаю C # и какую среду JS вы будете использовать)

Код на стороне сервера:

if (request.urlVars.token == Date.now.month) then
   render "This is the real data: [2,5,3,5,3]"
else
   render "401 Unauthorized"

Код клиента (динамическая версия, обслуживаемая вашим сервисом) www.companyA.com/client/myajaxcode.js.asp

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= Date.now.month %>
// below is JS code that does ajax call using dataUrl
...

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

if (request.urlVars.token == mySaltedHashMethod(Date.now.month)) then

и

var dataUrl = 'www.companyA.com/services/service1.ashx?token=' + <%= mySaltedHashMethod(Date.now.month) %>

Из-за этого у вас будет URL типа www.companyA.com/services/service1.ashx?token=gy4dc8dgf3f, и каждый месяц будет меняться токен.

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

Мне было бы интересно узнать, решил ли кто-нибудь это с помощью какого-то зашифрованного клиентского кода!

Answer 3

Со второй ссылкой, представленной компанией AI, не думаю, что вы можете многое сделать.Насколько я понимаю, вы можете только проверить, поступает ли входящий запрос от Компании А.

Но каждый запрос, направленный на www.companyA.com/ .., нельзя отличить от исходного запроса от Компании АВсе, кого они впустили, используют своего реферера в качестве маскировки.