Как повысить безопасность моего гибридного решения ASP.NET 1.1 / Ajax?

Question

Сценарий

У меня есть веб-сайт HTML / javascript, который использует javascriptSOAPClient для связи с веб-службой ASP.NET 1.1 для чтения / записи в базу данных SQL. (http://www.codeproject.com/KB/ajax/JavaScriptSOAPClient.aspx). База данных содержит анонимную демографическую информацию - без имен, без кредитных карт, без адресов. По сути, данные собираются для целей интеллектуального анализа данных.

Сайт работает, но мы хотим обеспечить более безопасную связь между клиентом javascript / ajax и сервисом wbe как для этого, так и для будущих проектов. Работая в качестве подрядчиков в финансовой индустрии, в какой-то момент мы столкнемся с вопросом: можно ли взломать этот сайт? Если у нас нет решения, мы можем быть на слуху.

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

Вопросы

1. С моим гибридным решением (т. Е. Не сквозным Microsoft), как мне пройти проверку подлинности клиентских запросов в веб-службе?
2. Если я начну передавать имя пользователя / пароль или какой-либо другой идентифицируемый элемент в веб-службу в качестве аутентификации, должен ли я беспокоиться о том, как этот ключ генерируется / хранится на стороне клиента?

Answer 1

Есть несколько простых опций:

1. SSL + Cookie
2. Если веб-приложение также ASP.NET и размещено вместе с вашим веб-сервисом, то у вас должен быть доступ к пользователю / членству / сеансу веб-приложения внутри вашего веб-сервиса (по сути, № 1, но вы получаете его без делать любую работу).
3. Если веб-приложение и веб-служба не находятся в одном домене, файлы cookie отсутствуют из-за проблем с несколькими доменами, поэтому веб-приложение может вставить GUID в скрытое поле формы и использовать этот GUID в качестве своего рода cookie (и его нужно будет передавать в качестве параметра во всех запросах веб-службы).

Answer 2

Несколько предложений для рассмотрения:

• Список угроз и сравнение каждой из них с вашими текущими настройками.
• Использовать SSL / HTTPS . Это облегчает целый класс уязвимостей.
• Используйте имя пользователя / пароль , сгенерированные на стороне сервера и отправленные пользователю (по почте или по телефону). (Надеюсь, что это отвечает на вопрос 2).
• Использовать 2-факторная аутентификация . Для этого вы можете посмотреть токены безопасности , такие как gizmos типа брелка RSA или посмотреть на Perfect Paper Passwords Стива Гибсона

Answer 3

Самым простым решением с точки зрения программирования является использование двухстороннего HTTPS. То есть сервер представляет сертификат клиенту, а клиент представляет сертификат серверу. Тогда могут подключаться только клиенты с соответствующими сертификатами (выданными вами).

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

Answer 4

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