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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

1 ответ

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

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

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

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

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

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

Еще одно противоречие - вы явно хотите отправить конфиденциальные данные.

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

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

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

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

Источник
Другие вопросы по тегам