Ограничение доступа к веб-сервису для публичного приложения Flex Flex

Question

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

Существует брандмауэр XML для предотвращения определенных искаженных запросов, DoS-атак и т. Д., И веб-служба проверяет все данные, полученные от клиента.

Если бы я должен был подписывать контент, я мог бы использовать брандмауэр XML для проверки подписи, но я предполагаю, что любые данные типа сертификата, которые я внедряю в клиенте, могут быть извлечены из приложения flex через некоторые средства декомпиляции ,

Мой вопрос в том, есть ли способ ограничить вызовы веб-службы только тем из моего клиента flex? Я понимаю, что пользователь может вводить плохую информацию, но я действительно пытаюсь предотвратить другой клиент или «бот».

Если бы я должен был представить учетные записи пользователей, чтобы воспользоваться решением, основанным на сеансе, то, по-видимому, я по-прежнему сталкиваюсь с той же проблемой, когда я пытаюсь настроить учетную запись в первую очередь (ее еще нужно будет сделать приложение flex)?

Answer 1

Как упоминается в TheBrain, файл crossdomain.xml - это то, где вам нужно запускать, но это только удерживает другие приложения на основе flash. Его идея о случайном id также хорошая, но я мог видеть, что это довольно сложно реализовать. Вы можете внедрять учетные записи пользователей только с теми учетными записями, которые были установлены с помощью других средств, кроме приложения flex (что-то, предположительно, более безопасное).

Другим способом было бы иметь общий пароль между приложением и сайтом webservice и шифровать этот пароль с обеих сторон, используя какую-то соль, которую могут знать обе стороны. Мой первый инстинкт - подумать о соли, основанной на времени. Вы можете передать временную метку из приложения flex вместе с остальной частью запроса, а затем взять свой пароль и одну и ту же метку времени, объединенную вместе, хеш-код и передать это вместе. В веб-сервисе, когда вы получаете запрос, вы берете тот же пароль (не переданный с запросом в ясности) и метку времени, которая была передана, и хеш-код с использованием того же алгоритма. Тогда сравните. Если они совпадают, это аутентифицированный запрос. Вы даже можете хранить словарь паролей и использовать другой для каждого дня недели или что-то в этом роде. Однако, как бы вы это ни делали, убедитесь, что ваши два метода определения хэшированного пароля идентичны. Это должно обеспечить достаточную безопасность для большинства приложений. Дайте мне знать, если какое-либо из этих вопросов нуждается в разъяснении или если я неправильно понял вопрос.

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

Answer 2

вы можете добавить crossdomain.xml на свой сервер, чтобы только ваше приложение flex могло получить доступ к вашей службе домена и ... вы можете сгенерировать некоторый случайный идентификатор, когда вы показываете веб-страницу и передаете ее в приложение flex в качестве параметра , поэтому, когда приложение flex делает первый вызов службы, идентификатор должен быть там. с ответом службы, сгенерировать другой идентификатор и отправить его обратно в flex, чтобы использовать его с будущим вызовом и так далее.