2009-05-06 2 views
13

Я написал простой .NET webservice, который я буду размещать на другом сервере, на разных континентах. Я действительно не знаю. Теперь у меня был только URL-адрес, и я попытался использовать метод webrequest и webresponse для доступа к этой веб-службе vai HTTP POST. Теперь я хочу знать, есть ли способ защитить доступ к веб-сервису, чтобы никто не мог его использовать?Как защитить веб-сервис в .net?

, например:

http://example.com/Verify/Verification.asmx/Verify?AccountNumber=3223&ProductName=876

Теперь, это все параметры, необходимые для вызова этого веб-сервиса. Как будто теперь любой может использовать его. Итак, как я могу сделать это безопасным? Хотя, я планирую получить SSL, и все это происходит от сервера к серверу, а не от клиента к серверу?

+0

СПАСИБО КАЖДЫЙ .. СЧАСТЛИВЫЙ КОДИРОВКА. – Mohit

ответ

9

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

См раздел 14.8 в следующем URL

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

+0

Спасибо, это имеет смысл. Есть ли еще что-нибудь, что я могу сделать, чтобы сделать его более безопасным?Если запрос от клиента выполняется в режиме SSL, этот запрос также будет выполняться в SSL с сервера на сервер, или мне нужно включить его конкретно? Простите меня, задавая столько вопросов. Спасибо. – Mohit

+1

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

1

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

Если бы мне пришлось это сделать, я бы использовал WCF и дал себе некоторые варианты. Если бы я не мог использовать WCF, я бы создал пользовательский HTTP-заголовок для передачи имени пользователя и пароля (через SSL!) И аутентификации на сервере. В качестве альтернативы, я бы использовал сертификаты на клиенте и требовал их отправки на сервер. IIS может даже превращать клиентские сертификаты в идентификаторы Windows на сервере.

+0

WCF ... Думаю, я могу взглянуть на это. Но все же мне нужно получить доступ к этому только через URL, это мое ограничение. Пожалуйста, помогите мне, если сможете. Любая ссылка будет достаточной. спасибо. – Mohit

+0

Центр разработчиков WCF в MSDN находится по адресу http://msdn.microsoft.com/WCF/. WCF следует использовать вместо ASMX для всех новых разработок веб-сервисов. –

1

Как правило, вы использовали для обеспечения веб-служб .NET до того, как WCF был Web Service Extensions (WSE) от Microsoft, теперь в версии 3.0. Я успешно использовал его в коммерчески доступном продукте, и он довольно хорош, так как он основан на стандартах W3C ws- *. Можно успешно взаимодействовать с тем, что из .NET-клиентов (очевидно), но также и с Java-клиентов, если вы используете Apache Axis. Скачать на:

http://www.microsoft.com/downloads/details.aspx?FamilyID=018a09fd-3a74-43c5-8ec1-8d789091255d&displaylang=en

+0

Я настоятельно рекомендую против даже думать о WSE! ВФБ довольно устарела, заменив ее WCF. Не используйте WSE, если у вас нет выбора вообще. –

+3

Вот почему я написал/before/WCF ... Исходный вопрос, похоже, относится к традиционным веб-сервисам .NET. Конечно, я бы рекомендовал WCF, если есть выбор. –

+0

Просто _пожалуйста, будьте осторожны с упоминанием WSE - что, если кто-то читает это, решил _use_ it? Вот почему я так выразился - «только если у вас нет другого выбора». Я не хочу, чтобы кто-то использовал его, потому что «он использует файлы .ASMX» или «WCF слишком продвинут» или что-то в этом роде. ВФБ является устаревшей и ее просто нельзя использовать, по крайней мере, ни в каком проекте. –

0

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

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

+0

Очень приятно .. Спасибо за предложение .. Но, как говорили другие ребята, я также попытаюсь использовать WCF и посмотреть, приносит ли он мне пользу. В противном случае я всегда могу использовать ваше предложение. Благодарю. – Mohit

0

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

Токен необходимо создать при успешном входе в систему. Чтобы создать идентификатор маркера, я рекомендую использовать RNGCryptoServiceProvider.

+0

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

Смежные вопросы