SWF для байтового массива из скрипта PHP - PullRequest
1 голос
/ 07 ноября 2010

Я использую AMFPHP для потоковой передачи содержимого с моего сервера в мое приложение Flex, поскольку Flash - это клиентская технология, и я бы хотел, чтобы людям было труднее получать защищенные файлы, поэтому я создал систему, которая передает потоковый файл SWF другомуFlash Player, я сделал все тестирование потока URL, теперь я хочу передать SWF-файл плееру в виде bytearray ... так как я думаю, что это безопаснее и сложнее взломать, и в будущем я даже мог бы сделать некоторые шифрования моеговладеть, если я стал более знаком с байтами и битами .. в любом случае мой метод лучший?(SWF для ByteArray?) Или есть лучший?Если метод bytearray является лучшим, я столкнулся с проблемой при выводе SWF-файла в правильном формате, я использую очень примитивный метод ..

        $file = file_get_contents($file); 
        $byteArr = str_split($file); 
        $byteArr = array_map('ord', $byteArr);
        $return['fileBin']->data = $byteArr;

, и я возвращаю переменную $ return...

Ваша помощь пользуется большим уважением и признательностью.

Рами

1 Ответ

2 голосов
/ 07 ноября 2010

Хм ...

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

Из-за этого я создал собственную комбинацию сжатия + шифрования, для которой требуется пароль.Этот пароль отправляется сервером при необходимости.

Однако в вашем случае это не лучший способ.С ByteArray нет ничего сложного, по сути, он отправляет необработанные байтовые данные.Если, конечно, вы не зашифруете его (+1).

Еще одна хорошая вещь - сделать токены запросов (+1).Т.е. в PHP вы генерируете «токен» и записываете его в файл списка токенов.Маркер будет что-то вроде 32 буквенных цифр.Этот токен также будет передан запрашиваемому объекту / странице SWF, который немедленно использует его в запросе.Запрос работает ТОЛЬКО с действительным токеном, то есть тем, который был записан в списке токенов.Когда это используется, это удалено немедленно.Кроме того, может быть ограничение по времени для каждого токена.Как 15 или 20 секунд.Если он не используется к тому времени, удалите его.Пользовательская сторона (если загрузка слишком длинная) должна быть перезагружена (хотя и не вручную - может быть какой-либо сценарий или iFrame для перезагрузки только SWF), если превышено ограничение по времени.

EDIT : автор вопроса задал по-другому - его цель, очевидно, состоит в том, чтобы сделать SWF-файл запрошенным доступным / доступным ТОЛЬКО для приложения-загрузчика.Ничего больше.Итак:

Боюсь, это сложно, но ... На самом деле невозможно сделать что-то невозможное, чтобы взломать / взломать.К счастью, это легче сделать в сетях (хотя они чаще подвергаются атакам) или в Интернете.Вы НЕ МОЖЕТЕ сделать что-то, что может быть загружено только вашим приложением.Если вы думаете об этом - это невозможно даже логически - в обоих случаях (по запросу пользователя и по запросу приложения) пользовательский компьютер запрашивает один файл, и этот запрос легко отследить и повторить или просто перехватить.Декомпиляция SWF будет использоваться, если какой-либо из первых двух не сработает.Немного о противодействии всем возможностям:

A) отслеживать и копировать

Это легко сделать с помощью таких инструментов, как Firebug on FF илиодинаково хороший (действительно) инспектор по Safari.С их помощью легко увидеть, что было запрошено, заголовки и ответ (к счастью, невозможно загрузить запрошенный файл - он не записывается, если он не является HTML или MIME в виде обычного текста), а также заголовки ответа.

Бесполезно запутывать URL-адрес запроса в коде, если он в конечном итоге будет отображаться в соответствии с запросом в консоли одного из этих инструментов.Решения могут быть такими:

  1. сделать запрос только один раз (как показано выше - токенизация)
  2. использовать специальный заголовок для запроса, такой как «Connection: keep-alive» -это делает его более сложным для обычных злоумышленников, потому что они часто просто копируют URL-адрес и запрашивают его в браузере - но соединение там будет автоматически «Соединение: закрыто», проверьте это в коде на стороне сервера и примите толькоживые (или ваши «особые») запросы
  3. используют протокол, отличный от HTTP - к сожалению, это включает функции сокетов на стороне сервера для связи через порты, отличные от 80-х HTTP ... большинство поставщиков серверов не позволяют пользователямэто, но если вы можете - и хотите обеспечить безопасность - сделайте это - не используйте какой-либо известный протокол, а скорее то, что соответствует вашим потребностям - в конце концов, вы контролируете как на стороне сервера, так и на стороне клиента, так что связь может бытьсделано в любом случае

B) перехват

Это немного более высокоуровневая атака - но если злоумышленник опытный и имеет НЕКОТОРЫЕ ресурсы, это не так сложно сделать. По сути, это связано с наличием прокси-сервера (отсюда и ресурсы - нужен сервер с включенными сокетами, который у меня сам есть: D), который он будет использовать для подключения через свой браузер. Однако прокси-сервер будет не только пересылать контент, но и записывать его. Противодействие:

  1. использовать другой протокол
  2. шифрование этого протокола - потому что, даже если данные записаны, это не имеет значения - это уже не просто HTTP-заголовки, за которыми следуют необработанные данные файла (заголовки легко удаляются и "violá") - только клиент приложение знает, как использовать эти данные

C) декомпиляция

Это даже не так сложно сделать - декомпиляторы SWF теперь не являются чем-то новым, и любой код из вашего приложения свободно доступен злоумышленнику. Даже если вы используете другой протокол, злоумышленник может с меньшими или большими усилиями взломать его. Решения:

НЕТ - вы можете просто усложнить задачу для злоумышленника - запутать свой код, получить его много (если вы действительно ХОТИТЕ безопасность ... хаос может быть просто ваш друг), используйте межклиентские межсерверные запросы для фактического кода - динамически загружаемые вторичные SWF, которые загружают код ...

...