Каковы возможные угрозы при вызове веб-сервисов с помощью JQuery и как их избежать?

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

Я планирую забыть о ASP.net UpdatePanel и перейти к использованию ajax через JQuery. Я боюсь, что из-за простого, клиентского характера JavaScript (и, следовательно, кода JQuery) любой, кто смотрит на мой источник веб-страницы, может понять, что представляет собой URL-адрес веб-сервисов, которые я вызываю, а также то, что передается для этих веб-сервисов.

При использовании UpdatePanel для этих типов операций я уверен, что вызывающие веб-службы выполняются на стороне сервера, и я не беспокоюсь о проблемах с информацией о том, что вы вызываете уязвимые веб-сервисы публично, но теперь, m планирует использовать Ajax через JQuery, меня это очень беспокоит.

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

Уточнение: при использовании UpdatePanel, я имею в виду использование цепочки техник, включая ASP.net AJAX, код-код и полагающиеся на серверные Dll для выполнения асинхронных серверных операций вместо jquery Ajax который требует веб-сервисов для работы с сервером.

ОТВЕТЫ

Ответ 1

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

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

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

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

Сообщите мне, если это поможет.

Ответ 2

Я расскажу о проблемах, которые мой ответ надеется решить:

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

  • Атакующие могут писать скрипты/боты, чтобы очистить ваши данные.

  • Атакующие могут сосредоточиться на ваших веб-сервисах и попытаться взломать их/получить доступ к вашей сети.

  • Атакующие могут попытаться выполнить DoS/DDoS на ваших веб-сервисах.

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

Он создает еще один прыжок в сети, но он также имеет следующие преимущества:

  • Он скрывает фактический IP-адрес машины, на которой размещаются ваши услуги.
  • Вы можете легко заблокировать этот один веб-сервер и контролировать необычную активность. Если вы видите всплеск активности, вы можете потенциально закрыть веб-службы. (Если вы используете другую машину, вам нужно будет контролировать два окна. Не большая проблема, но проще контролировать только один.)
  • Вы можете легко разместить распределенный уровень кэширования в прокси. Это защищает вас от атак типа "загрузка/отказ в обслуживании" (DoS) и, очевидно, поддерживает обычный трафик веб-сервисов.
  • Вы можете скрыть аутентификацию на уровне прокси. Общественные вызовы не изменят вашу схему аутентификации. В противном случае злоумышленник может увидеть, какие жетоны или ключи или секреты или что-то еще вы используете. Создание прокси на веб-сервере скрывает эту информацию. Данные все равно будут протекать, но снова вы сможете его контролировать.

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

Ответ 3

Поскольку вы ссылаетесь на ASP.Net, знаете, что его viewstate можно легко расшифровать. Там нет отказоустойчивых способов защитить свой код (не сказать, что URL-адреса называются). Если вы вызываете веб-службы с некоторыми параметрами, которые могут допускать неограниченные и опасные действия, тогда вам лучше начать использовать управление пользователями/ролями/правами.

Если вас беспокоит нападение "человек в середине", вам лучше всего использовать https.