Загрузка swf строго со своего домена, .htaccess домены защита swf Опции

[chingachgoog]

Что есть и что я хочу.

Есть swf-оболочка. Она грузит файл swf-контента. Расположение, например, такое:


cover.swf - оболочка

/content/slide1.swf - файл контента

Хочу, чтобы директория content была недоступна всем сетевым пользователям.
(я правильно понимаю, что это возможно с помощью .htaccess ?)

Хочу, чтобы по запросу cover.swf php-скрипт брал файл из директории content (это же на сервере происходит?) и отправлял его в cover.swf POST-ом, например. Но только в том случае, если сервер будет четко знать, что это его родной cover.swf (как он это узнает?).

[tiHo]

Ну так всеравно ведь эта флешка появится во временных файлах браузера. Разьве нет? от чего защита?

[chingachgoog]

Ну так всеравно ведь эта флешка появится во временных файлах браузера. Разьве нет? от чего защита?

Если и появится (в чем я не уверен, надо посмотреть как POST кэшится), то толку от нее не будет - она предполагается быть зашифрованной.
Тем более всегда можно усложнить - несколько POST-ов получать или даже сокет протянуть. Это не принципиально.

Самое главное, чтобы:
1) Сервер имел возможность пересылать клиенту контент, но сам пользователь к контенту напрямую доступа не имел.
2) Сервер должен быть 100% уверен, что клиент cover.swf - это его родной файл, а не подстава.

[tiHo]

1) Сервер имел возможность пересылать клиенту контент, но сам пользователь к контенту напрямую доступа не имел.

да, наверно либо htaccess либо в бд хранить флешку как бинарные данные и выдавать по запросу сервера.

2) Сервер должен быть 100% уверен, что клиент cover.swf - это его родной файл, а не подстава.

как вариант проверить хэш файла

[chingachgoog]

как вариант проверить хэш файла

Вообще я слабо себе представляю как люди умудряются подменить своей флешкой флешку на удаленном сайте (все эти создатели ботов, в играх, например). Поэтому не понял про хеш файла: кто его будет проверять? Сервер или клиент? Если клиент - то это бесполезно. Если сервер - то как?

[MustLive]

Загрузка swf строго со своего домена

chingachgoog

Задача эта решаемая, на разные этапы этой задачи решаются с разной степенью эффективности (и соотвественно с разной степенью возни для разных этапов задачи).

Хочу, чтобы директория content была недоступна всем сетевым пользователям.

Первый этап решается путём использования .htaccess (только на веб сервере Apache).

Создай в папке content файл .htaccess со следующим содержимым:

Order deny,allow
Deny from all

Это полный запрет доступа ко всем файлам, если захочешь запретить доступ лишь к swf-файлам, то настраивай соответственно. Дальше доступ к swf-файлам будет осуществляться через php-скрипт.

отправлял его в cover.swf POST-ом, например.

Отправлять будет не php-скрипт флешке cover.swf, а он будет отдавать нужный флеш-файл на запрос cover.swf (на POST или GET запрос, это как ты реализуешь, но отдавать в любом случае будет бинарный код флешки).

Но только в том случае, если сервер будет четко знать, что это его родной cover.swf (как он это узнает?).

Если делать по-простому, то это можно обойти. Например если проверять реферер, то это легко обходится. И просто так сервер не проверит со 100% гарантией, что cover.swf находится на нужном домене.

Поэтому здесь можно добавить клиентскую проверку - в самой флешке проверять домен. Как это делается я уже писал на форуме, в №15 нашей рассылки и у себя на сайте. Это тоже обходится путём модификации самой флешки. Чем маньячней эта проверка сделана в самой флешке, тем сложнее её будет обойти.

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

[chingachgoog]

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

[MustLive]

Путем изменения cover.swf пытается добраться до контента напрямую.

chingachgoog

Он и без изменения cover.swf доберётся до контента напрямую - лишь изучит исходник cover.swf (декомпилировав его) и найдя адрес php-скрипта. Усложнение AS-кода с целью запутывания атакующего (чтобы сложнее было выяснить адрес php-скрипта) легко обходится путём более длительного анализа кода, поэтому защищаться нужно другими способами.

Вот сервер и должен отследить, что cover.swf это именно его флешка - серверная.

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

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

[chingachgoog]

Он и без изменения cover.swf доберётся до контента напрямую - лишь изучит исходник cover.swf (декомпилировав его) и найдя адрес php-скрипта.

А что может ему дать адрес php-скрипта? Я думал, что сам скрипт прочитать нельзя. Это разве не так? А исходник спрятан в каталог с заблокированным входом из сети.

сервер не может надёжно это отследить, как я уже говорил, поэтому любые проверки на "источник запроса" флеш контента обходятся.

100% защиту контента отправляемого на клиент сделать, разумеется, невозможно. Но сервер может считать время открытой сессии или что-то в этом духе, что поможет понять, что запрос пришел не с его родной флешки.

[MustLive]

chingachgoog

На твой изначальный вопрос я полностью ответил ранее .

А что может ему дать адрес php-скрипта?

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

Я думал, что сам скрипт прочитать нельзя. Это разве не так? А исходник спрятан в каталог с заблокированным входом из сети.

Ты некорректно понял суть работы .htaccess. Спрятаны флешки (все помимо интерфейсной), а скрипт находится снаружи, например, в папке с интерфейсной флешкой - он доступен из браузера (лишь адрес его "спрятан" во флешке). Что нужно для того, чтобы из флешки можно было к скрипту обращаться (за swf-файлами). Что хорошо видно из моего вышеприведённого примера.

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

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

[chingachgoog]

Ну значит не все так плохо. Я просто испугался, что сам php-файл со скриптом можно прочитать. А так - есть масса уловок и идей

[MustLive]

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

что сам php-файл со скриптом можно прочитать.

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

[Chaos]

Интерфейсную флэшку тоже можно держать в папке под Deny from all и грузить её в <object> как php в котором

Код

$fp = fopen( "chaos/Chaos.swf","r");
$cp = fread($fp, 17462);
echo $cp;

... тем самым позволяя отдать swf только после доп. проверки.
Сам swf должен быть привязан к домену и проверять домен и данные при контакте с сервером.

В случае если флэшка виртуозно подменена - она врядли сможет больше чем родная, если конечно серверные скрипты ей не позволят большее.

[MustLive]

Интерфейсную флэшку тоже можно держать в папке под Deny from all

Chaos

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

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