Реализация Zend AMF и безопасность протокола AMF - PullRequest
Новая
       32

Реализация Zend AMF и безопасность протокола AMF

1 голос
/ 16 января 2010

У меня есть интерфейс Flex, подключающийся через RemoteObject к Zend Amf Zend Framework. Это мое единственное средство для передачи данных между клиентским уровнем (Flex) и прикладным и постоянным уровнями (LAMP с Zend Framework). Вот несколько способов решить проблему безопасности:

  1. Я могу обратиться к TLS, используя mx.messaging.channels.SecureAMFChannel в моем файле services-config.xml и убедившись, что проигрыватель Flash загружен в оболочку HTTPS и фактически использует HTTPS, поскольку протокол AMF размещен поверх HTTP
  2. RemoteObject имеет метод setCredentials, с помощью которого я могу передавать заголовки аутентификации AMF для защиты данных, связанных с пользователем. Предполагая, что TLS действительно безопасен, я могу предоставить методы на конечной точке после аутентификации пользователя.
  3. Я могу защитить от межсайтовых сценариев и других FLASH уязвимостей с правильно настроенным crossdomain.xml

У меня вопрос: как защитить свою конечную точку от другого потребителя AMF? Например, если бы существовал другой потребитель AMF (не Flash, не связанный через crossdomain.xml и безопасность песочницы Flash), кроме моего клиента Flex, который знал мою конечную точку, что могло бы помешать ему использовать методы, предоставляемые конечной точкой?

Насколько я знаю, мне, по сути, нужен способ аутентификации моего приложения Flex на моей конечной точке Zend Amf. После аутентификации потребителя AMF у меня есть некоторые механизмы безопасности, о которых я упоминал выше, для защиты определенных фрагментов данных (например, аутентификация пользователя). Я не могу встроить какой-то механизм аутентификации в свой Flex SWF, потому что SWF уязвим для декомпиляции (SWF нельзя доверять). Хотя конфиденциальные данные защищены посредством аутентификации пользователя, незащищенные данные вряд ли общедоступны, но, насколько я могу судить, полностью открыты для публичного использования.

Ответы [ 2 ]

0 голосов
/ 20 января 2010

Клиент AMF не может знать, кто их вызвал, если не предусмотрена какая-либо аутентификация. Любой HTTP-запрос, который отправляет Flex, можно эмулировать не-Flex, и, как вы правильно заметили, любой встроенный ключ может быть извлечен. Так что для этого нет универсального решения, хотя, возможно, вы могли бы что-то решить, если бы вы дали клиентские сертификаты для HTTPS-соединения и заставили сервер проверять клиентские сертификаты.

0 голосов
/ 16 января 2010

Вы не можете запретить кому-либо отправлять произвольные HTTP-запросы на вашу конечную точку. Если ваше приложение Flex проверяет подлинность пользователей на сервере, а сервер обслуживает конфиденциальные данные, только если в запросе указаны правильные учетные данные / идентификаторы сеанса, все в порядке. То, что вы не можете сделать, - это аутентифицировать пользователя и хранить в клиенте только то, что пользователь аутентифицирован. Поскольку HTTP является протоколом без сохранения состояния, сервер должен иметь возможность авторизовать каждый запрос индивидуально. То же самое относится и к «обычным» веб-сайтам и AJAX.

...