WCF и Silverlight 4.0 в приложении N-Tier: безопасные вызовы службы (без SSL, без защиты сообщений, без x.509) - PullRequest
1 голос
/ 15 августа 2011

Наша архитектура представляет собой простую модель N-уровня, которая состоит из приложения ASP.Net, расположенного в IIS7 (размещенного в DiscountASP), которое предоставляет методы для службы WCF. Эти методы общаются с БД с помощью EF4. Клиенты в Silverlight 4.0.

Три важных момента:

  • Аутентификация и аутентификация не являются проблемой - звонки в анонимные , и мы не заботимся о личности вызывающий абонент.

  • Данные, передаваемые в вызовах методов, в не чувствительны .

  • Мы просто хотим убедиться, что никто не может делать звонки.

Поправьте меня, если ошиблись:
Защита сообщений невозможна, поскольку она не поддерживается в Silverlight.
Безопасность транспорта (сертификаты HTTPS и x.509 / SSL) также нельзя выполнить в Silverlight

Итак, шаги, которые мы предпринимаем для обеспечения некоторого уровня безопасности:

  • Секретный ключ жестко запрограммирован на один из DLL в XAP.

  • Эта DLL-библиотека закодирована, поэтому ее нельзя перепроектировать.

  • Секретный ключ отправляется в качестве параметра всем методам обслуживания. звонки.

  • В начале каждого метода сверяйте секретный ключ с оригинальное сидение в БД.

  • Удалите конечную точку MetaDataExchange из службы.

Учитывая эту минимальную настройку и ее множество недостатков, самым большим недостатком, вероятно, является тот факт, что передача не защищена (HTTP), и секретный ключ открыт. Итак, вопросы:

Если злонамеренный пользователь хочет нанести вред нашей системе, сколько усилий он должен приложить, чтобы извлечь секретный ключ, найти, какие методы раскрыты, и начать их вызывать?

Существуют ли другие WCF-комбинации, которые могут обеспечить базовую защиту учетных данных при каждом вызове (без HTTPS или сертификатов)?

1 Ответ

0 голосов
/ 15 августа 2011

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

  • Аутентификация и аутентификация не являются проблемой - звонки в службу являются анонимными, и мы не заботимся о личностивызывающего абонента.

  • Мы просто хотим убедиться, что никто не может делать вызовы.

То естьпротиворечие.Если вы хотите гарантировать, что вызовы не могут быть выполнены всеми, кого вы ищете для аутентификации.

  • Данные, переданные в вызовах методов, не являются конфиденциальными.

Учитывая эту минимальную настройку и ее множество недостатков, самым большим недостатком, вероятно, является тот факт, что передача не защищена (HTTP), и секретный ключ открыт.

Другое противоречие - вы, очевидно, хотитеотправлять конфиденциальные данные.

Защита сообщений не является опцией для Silverlight - это верно, если мы говорим о шифровании и подписи сообщений, но вы все равно можете передать имя пользователя и пароль в сообщении, если вы используете HTTPS для обеспечения безопасностиchannel = TransportWithMessageCredential

Сколько нужно усилий, чтобы найти секретный ключ?

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

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

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