Безопасность WCF между клиентом WinForms и веб-сервером Shared Host

Question

Хорошо,

Я разработал этот клиент WinForms, который взаимодействует с сервером (приложение ASPX) посредством вызовов WCF. Теперь я хотел бы развернуть сервер на своем общем веб-хосте, но я немного новичок в WCF и особенно в возможностях обеспечения безопасности.

Цель - обеспечить безопасность службы WCF, чтобы не все, кто знает или узнает адрес конечной точки, могли ее вызвать. Скорее, только мой клиент WinForms должен иметь возможность вызывать службу WCF.

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

Возможно ли это в среде Shared Host (IIS) (HTTPS в распоряжении отсутствует)? Какие привязки и опции я должен использовать? Я полагаю, wsHttpBinding, но как мне настроить параметры безопасности?

Использование .NET 4.0

Спасибо

Answer 1

Насколько я понимаю, у вас есть интернет-сервис, который вы хотите ограничить только своим клиентским приложением, чтобы иметь возможность звонить - правильно? Или вы предполагаете, что другие клиенты (такие как PHP, Ruby и т. Д.) Тоже захотят в какой-то момент позвонить в ваш сервис?

Для защиты вашего сообщения у вас есть два варианта в WCF - защита сообщений или транспорта. По Интернету, с неизвестным количеством переходов между вашим клиентом и вашим сервисом, безопасность транспорта не работает - вы остаетесь с безопасностью сообщений (шифрование сообщения при его перемещении по сети). Чтобы это работало, вы обычно добавляете цифровой сертификат к вашей службе (только на стороне сервера), который клиент может обнаружить и использовать для шифрования сообщений. Только ваша служба сможет их расшифровать, поэтому вы в этом уверены.

Следующий пункт: кто может позвонить в вашу службу? Если вы хотите быть полностью открытым для кого-либо, тогда да, вам нужно wsHttpBinding (или вариант RESTful - webHttpBinding). Если вы хотите разрешить клиенты, не являющиеся .NET, вы обычно ограничены отсутствием аутентификации (любой может позвонить) или схемами имени пользователя и пароля, которые вы будете проверять на стороне сервера в отношении базы данных действительных пользователей.

Если вы хотите разрешить только свой собственный клиент .NET, то вы можете сделать несколько вещей:

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

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

• вам нужно каким-то образом идентифицировать тех вызывающих абонентов, которые разрешены в - одним из возможных способов будет добавление дополнительного заголовка в ваши сообщения WCF, который вы затем проверяете на стороне сервера. Это просто гарантирует, что случайный хакер, который обнаружит ваш сервис и определит двоичную привязку http, все равно будет отклонен (по крайней мере, на некоторое время). Смотрите сообщение в блоге здесь о том, как реализовать такое расширение инспектора сообщений для WCF.

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

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

Answer 2

Первое, что вам нужно спросить себя: «Что кто-то может сделать с вашей службой WCF, если он подключил своего собственного настроенного клиента?» Посмотрите на все функции, предоставляемые через WCF, и предположите, что к ним можно получить доступ по желанию. У вас нет абсолютно никакого контроля над клиентом, и у вас никогда не будет этой способности.

HTTPS - это прекрасно, чертовски жаль, что вы вынуждены быть уязвимыми для OWASP A9: недостаточная защита транспортного уровня . Если бы это было до меня, я бы переехал на другой хост, который заботился о безопасности. Если вы выкидываете имена пользователей и пароли по сети, то вы подвергаете своих пользователей опасности.

Одна из самых больших проблем, с которыми я столкнулся при работе со службой WCF, заключается в том, что у них была выставлена ​​функция executeQuery (). Разработчик, позволяющий клиенту создавать запросы для выполнения сервером. Этот подход в корне ошибочен, поскольку вы просто передаете свою базу данных злоумышленнику. Этот тип уязвимости не является SQL-инъекцией, он подпадает под CWE-602: Обеспечение безопасности на стороне клиента .

В том же ключе, что и CWE-602: OWASP A4: небезопасные прямые ссылки на объекты . Может ли злоумышленник обмануть вашу службу WCF, заставив ее думать, что это другой пользователь, предоставив другой идентификатор пользователя? Вы доверяете клиенту, чтобы сказать правду?

Следующая классификация уязвимостей, которую вы должны принять во внимание, - OWASP A1: Инъекция , также известная как "Taint and Sink". Например, если вы выставляете функцию, в которой один из ее параметров используется в CreateProcess(), который вызывает cmd.exe. Этот параметр может контролироваться злоумышленником, и там для этой переменной «испорчен», вызов CreateProcess() является «стоком». По этим направлениям существует много типов уязвимостей, включая, но не ограничиваясь; SQL-инъекция, LDAP-инъекция, XPATH-инъекция. Эти типы уязвимостей влияют на все веб-приложений.