Запретить кому-либо запускать ваш веб-сервис? - PullRequest
1 голос
/ 03 апреля 2009

У меня есть веб-сервис, который выполняется через javascript (jquery) для извлечения данных из базы данных. Я хотел бы убедиться, что только мои веб-страницы могут выполнять эти веб-методы (то есть я не хочу, чтобы люди выполняли эти веб-методы напрямую - они могли бы узнать URL, посмотрев, например, исходный код javascript).
Я планирую добавить параметр «Ключ» ко всем веб-методам. Ключ будет храниться на веб-страницах в скрытом поле, и его значение будет динамически устанавливаться веб-сервером при запросе веб-страницы. Значение ключа будет действительным, скажем, в течение 5 минут. Таким образом, когда необходимо выполнить веб-метод, javascript передаст ключ веб-методу, и веб-метод проверит, что ключ действителен, прежде чем делать то, что ему нужно.
Если кто-то захочет выполнить веб-методы напрямую, у него не будет ключа, который сделает его неспособным выполнить их.
Что вы думаете об этом? Есть ли лучшее решение? У вас есть проблемы с моим решением?

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: за то, что я делаю, посетители не вошли в систему, поэтому я не могу использовать сеанс. Я понимаю, что если кто-то действительно хочет сломать это, он может проанализировать html-код и получить значение скрытого поля, но ему придется делать это регулярно, так как ключ будет меняться каждые x минут ... что, конечно, возможно, но надеюсь, будет боль для них.

РЕДАКТИРОВАТЬ: то, что я делаю, это веб-приложение (в отличие от веб-сайта). Данные извлекаются через веб-методы (+ jquery). Я хотел бы запретить кому-либо создавать свои собственные веб-приложения, используя мои данные (что они могли бы, если бы они могли выполнять веб-методы). Очевидно, это было бы для них риском, так как я мог изменить веб-методы в любое время.

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

Спасибо.

Ответы [ 5 ]

6 голосов
/ 03 апреля 2009

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

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

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

С учетом вышесказанного, есть больше информации о , почему вы пытаетесь это сделать? Какой контекст? Возможно, есть что-то еще, что могло бы достичь вашей цели, и мы могли бы предложить, если бы знали больше:)

РЕДАКТИРОВАТЬ: Не так много больше информации, но я буду бегать с этим. Ваше решение на самом деле не собирается вообще повышать безопасность и создаст головную боль для вас при обслуживании и ошибках. Это также создаст головную боль для ваших пользователей, поскольку у них будет «невидимое» ограничение по времени для выполнения действий на страницах. С учетом того, что вы нам сказали, я бы сказал, что вам лучше просто ничего не делать.

Какие методы вы пытаетесь защитить здесь? Почему вы пытаетесь защитить их?

ND

3 голосов
/ 03 апреля 2009

ДОПОЛНИТЕЛЬНАЯ ИНФОРМАЦИЯ: из-за того, что я делаю, посетители не входят в систему, поэтому я не могу использовать сеанс.

Если вы отправляете клиенту ключ, который он будет отправлять обратно каждый раз, когда он хочет использовать службу, вы фактически создаете сеанс. Ключ, который вы передаете взад и вперед, функционально ничем не отличается от файла cookie (ожидайте, что он будет передан только при определенных запросах.) Также можно просто сохранить проблему и установить временный файл cookie, срок действия которого истекает через 5 минут. Добавьте небольшую проверку на наличие файлов cookie с истекшим сроком действия на сервере, и вы, вероятно, получите лучшее, что можете получить.

2 голосов
/ 03 апреля 2009

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

0 голосов
/ 03 апреля 2009

Допустим, вы генерируете ключ, действительный с 12.00 до 12.05. В 12.04 я открываю страницу, спокойно читаю ее, а в 12.06 запускаю действие, которое использует ваш веб-сервис. Мне будет запрещено это делать, даже если я законный посетитель.

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

0 голосов
/ 03 апреля 2009

Что мешает кому-то запрашивать веб-страницу, анализировать результаты, чтобы вытащить ключ, и затем вызывать веб-сервис с этим?

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

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

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

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