проблема с безопасностью

[masted]

помогите ради бога... такая проблема с безопасностью.
Есть мувик. Он посылает данные (Variables или XML не важно) на серверный скрипт.
Так вот. Что мешает кому-нибудь посмотреть исходный ActoinScript swf файла, сделать свой мувик и послать на сервер свои данные. Как этого избежать? :confused:

[Dimonius]

Проверять на сервере откуда поступил запрос

[Crazy]

Оригинал написал(а) masted
Как этого избежать?

Никак. Этого в принципе не нужно хотеть.

[Crazy]

Оригинал написал(а) Dimonius
Проверять на сервере откуда поступил запрос

Что мсье понимает под "откуда" и что это даст?

[Dimonius]

Высказываю предположение и только.

[uri-uri]

Использовать соединение по https

[Crazy]

Повторяю вопрос: чем конкретно это поможет?

[uri-uri]

2 masted

Ты хочешь, что-бы никто не смог послать свои данные НЕ ИЗ ТВОЕГО ФЛЭША? Тогда это должен быть уникальный ЧЕМ-ТО флэш-ролик, не повторяемый ну ни разу. И сервер должен ожидать подтверждение этого.

Решение:
Флэшка должна динамически генериться на сервере и включать в себя рандомные код с неизменяемой рабочей частью (формой ввода данных). При генерации снимок этого кода(контрольных значений) должен сохраняться на сервере. Во флэшке должен быть код перезагрузки (loadMovie на _level 0). Он должен запрашиваться с периодичностью. Этот период должен быть меньше времени взлома этой флэшки и создания приблуды с левыми данными для злоумышленников :о))
При поступлении запроса в серверный скрипт поступают контрольные значения, которые он сравнивает с сохраненным снимком, и если не совпадает - левак!

Вот так легко!

[Crazy]

Оригинал написал(а) uri-uri
Флэшка должна динамически генериться на сервере и включать в себя рандомные код с неизменяемой рабочей частью (формой ввода данных).

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

[masted]

Я понял идею. Но мне кажется, может я и не прав, что она совсем не идеальна.
Например, существует статичный мувик1 "Loader", который подгружает в себя мувик2 "MainMovie + SecureCode", при этом записывается этот же SecureCode на сервере. В дальнейшем мувик не расчитан на ежесекундную перегрузку, хотя должен обновляется довольно часто... около 1 раза в минуту. Тем не менее этого будет достаточно, что бы "выловить" подгруженный "MainMovie + SecureCode" и достать из него SecureCode. Ну а дальше по ходу дела... вот так. Может какие-то можно ещё ухищрения придумать.

[uri-uri]

2 masted

Пока ты будешь вылавливать и доставать SecureCode из пришедшего, вместо него пришлётся другой :-)) с другим SecureCode. Причём в кэше (благодаря http-заголовку) ни один из приходящих не появится.
Здесь только поможет absolutная автоматизация, что достаточно нетривиально... :p

[masted]

Причём в кэше (благодаря http-заголовку) ни один из приходящих не появится.
Ооо. Я вот про это совсем и забыл. Большое спасибо! А его (подгруженный мувик2) точно ниоткуда достать нельзя будет?

[uri-uri]

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

Если у тебя будут по трубам течь не очень большие деньги - это их не заинтересует.

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

Назовём это динамической защитой. Крепость её не в высокой криптостойкости алгоритма ключа, а в скорости смены самого ключа. Какой смысл крякать ключ, если к моменту кряка применяется уже новый ключ? :p

[uri-uri]

Да, еще...
Кто тебе мешает передавать твои данные не одним пакетом, а по кускам, каждый с приходом новой флэшки. Это ещё сильнее усложнит злоумышленнику жизнь :D

[masted]

Пасибо большое. А то я с этой проблемой оченб долго сидел :(