Защита удаленного вызова метода ajax - PullRequest
2 голосов
/ 02 февраля 2009

Я кодировал некоторый JavaScript для выполнения вызова ajax в приложении asp.net. Это вызывает метод, который вызывает URL, отправляя некоторые параметры в POST.

Получающая страница обрабатывает данные и обновляет нашу базу данных.

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

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

Спасибо за любые указатели.


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

Код, однако, должен выполнять отправку данных на наш сервер, как-нибудь безопасно?

Это невозможный сценарий, или мне нужно было бы выполнить какой-либо аудит после обработки?

Спасибо всем за хорошие предложения.

Ответы [ 7 ]

3 голосов
/ 02 февраля 2009

Вы можете использовать SOAP для передачи имени пользователя / пароля с запросом. SSL должен использоваться для шифрования данных, передаваемых по проводам. Вот код, который мы используем:

Это класс, который будет содержать учетные данные, отправленные с запросом:

Imports System.Web.Services.Protocols
Public Class ServiceCredentials

Inherits SoapHeader

Private _userName As String
Public Property UserName() As String
    Get
        Return _userName
    End Get
    Set(ByVal value As String)
        _userName = value
    End Set
End Property


Private _password As String
Public Property Password() As String
    Get
        Return _password
    End Get
    Set(ByVal value As String)
        _password = value
    End Set
End Property

Public Sub New()

End Sub

Public Sub NewUserInfo(ByVal ServiceUser As String, ByVal ServicePassword As String)
    Me.UserName = ServiceUser
    Me.Password = ServicePassword

End Sub

Добавьте атрибут в определение вашей веб-службы:

    <WebMethod()> _
<SoapHeader("CredentialsHeader")> _
   Function MyWebMethod(ByVal paremetersPassed as String)
   'check permissions here
   If PermissionsValid(CredentialsHeader) then
    'ok!
       .......
   else
       'throw a permission error
  end if
 End Function

А затем просто создайте функцию (в моем примере PermissionsValid) для проверки разрешений:

Function PermissionsValid(byval Credentials as ServiceCredentials) as boolean

    'check Credentials.Username and Credentials.Password here and return a boolean
End Function

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

Более простым способом было бы ограничить IP-адреса, которым разрешено попадать на страницу обслуживания. Но затем возникают проблемы с изменением IP-адресов и т. Д.

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

1 голос
/ 02 февраля 2009

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

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

1 голос
/ 02 февраля 2009

Вы должны защитить свой сервис, используя SSL

Редактировать: я забыл самое "основное": HTTP-аутентификация (используя логин / пароль) Я нашел ссылку, но она с 2003 года: http://www -128.ibm.com / developerworks / webservices / library / ws-sec1.html

Редактировать 2: Как сказано в комментариях, я думаю, что проблема здесь вписывается в назначение веб-сервисов REST ... Я ничего не знаю об asp.net, но вы должны ожидать учебники REST и увидеть альтернативы безопасности от HTTP-аутентификации до полной реализации WS-Security

0 голосов
/ 02 февраля 2009

Предполагая следующее:

Browser <-(1)-> ASP/.NET App (`https://123.com/app`) <-(2)-> Web Service (`https://456.com/ws`)

1) Защита веб-службы с помощью ssl через обмен сертификатами + базовая аутентификация. Таким образом, вы знаете, что единственным разрешенным потребителем является приложение .net.

2) Создайте прокси в приложении .net, скажем, на https://123.com/webservicecall, которое перенаправит ваши запросы в веб-службу.

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

Но на самом деле это звучит так, как будто вы не должны использовать прокси-сервер и вместо этого вызываете приложение .net с помощью ajax, а приложение .net затем напрямую обращается к веб-службе.

0 голосов
/ 02 февраля 2009

Извините, я не могу добавлять комментарии, так как у меня еще недостаточно времени для повторной обработки.

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

Если это так, вы, вероятно, захотите включить какую-либо регистрацию в системе. (На самом деле, вы должны это делать, несмотря ни на что.)

Вы можете записать запись в какой-нибудь журнал (файл, журнал событий, таблица sql и т. Д.) Во время функции PermissionsValid. Это может показать IP-адрес и имя пользователя, переданные вместе с отметкой времени, когда это было сделано. Таким образом, вы можете увидеть, если кто-то пытается взломать.

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

0 голосов
/ 02 февраля 2009

Все ли ваши клиенты в вашем домене?
Если нет, вы не сможете использовать объект XMLHttpRequest для отправки данных с их сайта. XHR подчиняется политике Одинакового происхождения .
Возможно, вы сможете публиковать на странице со своего сервера в iframe. Вам нужно будет попросить своих пользователей ввести их имя пользователя и пароль, чтобы эти детали не раскрыли ваш сценарий, и цель должна быть передана через ssl.

0 голосов
/ 02 февраля 2009

Не могли бы вы проверить на своей странице получения, пользователь вошел в систему, то есть

if User.IsAuthenticated

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