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

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


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

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

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

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

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

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

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

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



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

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

chingachgoog

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


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

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

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


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


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

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

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

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

chingachgoog

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


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

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

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



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

chingachgoog

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


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


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


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

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

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


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

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

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

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

Chaos

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

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