Хм ...
В настоящее время я использую что-то очень похожее (я разрабатываю MMORPG ...) - я решил, что мне нужно предварительно загрузить контент игры, чтобы игроку не пришлось ждатьтак много.К сожалению - эти файлы было бы просто просматривать и даже декомпилировать.
Из-за этого я создал собственную комбинацию сжатия + шифрования, для которой требуется пароль.Этот пароль отправляется сервером при необходимости.
Однако в вашем случае это не лучший способ.С ByteArray нет ничего сложного, по сути, он отправляет необработанные байтовые данные.Если, конечно, вы не зашифруете его (+1).
Еще одна хорошая вещь - сделать токены запросов (+1).Т.е. в PHP вы генерируете «токен» и записываете его в файл списка токенов.Маркер будет что-то вроде 32 буквенных цифр.Этот токен также будет передан запрашиваемому объекту / странице SWF, который немедленно использует его в запросе.Запрос работает ТОЛЬКО с действительным токеном, то есть тем, который был записан в списке токенов.Когда это используется, это удалено немедленно.Кроме того, может быть ограничение по времени для каждого токена.Как 15 или 20 секунд.Если он не используется к тому времени, удалите его.Пользовательская сторона (если загрузка слишком длинная) должна быть перезагружена (хотя и не вручную - может быть какой-либо сценарий или iFrame для перезагрузки только SWF), если превышено ограничение по времени.
EDIT : автор вопроса задал по-другому - его цель, очевидно, состоит в том, чтобы сделать SWF-файл запрошенным доступным / доступным ТОЛЬКО для приложения-загрузчика.Ничего больше.Итак:
Боюсь, это сложно, но ... На самом деле невозможно сделать что-то невозможное, чтобы взломать / взломать.К счастью, это легче сделать в сетях (хотя они чаще подвергаются атакам) или в Интернете.Вы НЕ МОЖЕТЕ сделать что-то, что может быть загружено только вашим приложением.Если вы думаете об этом - это невозможно даже логически - в обоих случаях (по запросу пользователя и по запросу приложения) пользовательский компьютер запрашивает один файл, и этот запрос легко отследить и повторить или просто перехватить.Декомпиляция SWF будет использоваться, если какой-либо из первых двух не сработает.Немного о противодействии всем возможностям:
A) отслеживать и копировать
Это легко сделать с помощью таких инструментов, как Firebug on FF илиодинаково хороший (действительно) инспектор по Safari.С их помощью легко увидеть, что было запрошено, заголовки и ответ (к счастью, невозможно загрузить запрошенный файл - он не записывается, если он не является HTML или MIME в виде обычного текста), а также заголовки ответа.
Бесполезно запутывать URL-адрес запроса в коде, если он в конечном итоге будет отображаться в соответствии с запросом в консоли одного из этих инструментов.Решения могут быть такими:
- сделать запрос только один раз (как показано выше - токенизация)
- использовать специальный заголовок для запроса, такой как «Connection: keep-alive» -это делает его более сложным для обычных злоумышленников, потому что они часто просто копируют URL-адрес и запрашивают его в браузере - но соединение там будет автоматически «Соединение: закрыто», проверьте это в коде на стороне сервера и примите толькоживые (или ваши «особые») запросы
- используют протокол, отличный от HTTP - к сожалению, это включает функции сокетов на стороне сервера для связи через порты, отличные от 80-х HTTP ... большинство поставщиков серверов не позволяют пользователямэто, но если вы можете - и хотите обеспечить безопасность - сделайте это - не используйте какой-либо известный протокол, а скорее то, что соответствует вашим потребностям - в конце концов, вы контролируете как на стороне сервера, так и на стороне клиента, так что связь может бытьсделано в любом случае
B) перехват
Это немного более высокоуровневая атака - но если злоумышленник опытный и имеет НЕКОТОРЫЕ ресурсы, это не так сложно сделать. По сути, это связано с наличием прокси-сервера (отсюда и ресурсы - нужен сервер с включенными сокетами, который у меня сам есть: D), который он будет использовать для подключения через свой браузер. Однако прокси-сервер будет не только пересылать контент, но и записывать его. Противодействие:
- использовать другой протокол
- шифрование этого протокола - потому что, даже если данные записаны, это не имеет значения - это уже не просто HTTP-заголовки, за которыми следуют необработанные данные файла (заголовки легко удаляются и "violá") - только клиент приложение знает, как использовать эти данные
C) декомпиляция
Это даже не так сложно сделать - декомпиляторы SWF теперь не являются чем-то новым, и любой код из вашего приложения свободно доступен злоумышленнику. Даже если вы используете другой протокол, злоумышленник может с меньшими или большими усилиями взломать его. Решения:
НЕТ - вы можете просто усложнить задачу для злоумышленника - запутать свой код, получить его много (если вы действительно ХОТИТЕ безопасность ... хаос может быть просто ваш друг), используйте межклиентские межсерверные запросы для фактического кода - динамически загружаемые вторичные SWF, которые загружают код ...