Безопасность данных

[Crenth]

Сообщение от Партизан

Что помешает мне взять SessionID у "правильного" плеера и отдать "неправильному"? Я так понимаю "неправильный" сразу "поправится", а "правильный" соответственно "поплохеет"...

правильный Swf грузится с правильного сервера. на правильном же сервере БД генерится sessid (чонить типа nextval()). вы только увидите строку типа

src="/app/rightplayer.swf?sessid=327cdf609bee0ad2cf200"

которую отдает PHP.
как только правильный swf загрузится, этот Sessid перестанет быть актуальным. И если FMS через NetConnection получит этот sessid снова, то он его не найдет в своей БД и отдавать никому ничего не будет, т.к. у него уже есть такой активный коннект

чтобы неправильный плеер работал, надо хватать все ответы сервера и загружать неправильные плееры раньше правильных
как это можно реализовать ?

[bti]

Crenth, URLLoader, ссылка на страничку плеера, дальше думаю объяснять не нужно.
kackbip, поведение плеера тоже раскалывается просто (достаточно вспомнить не так уж давние события с icq)

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

[Crenth]

Сообщение от bti

Crenth, URLLoader, ссылка на страничку плеера, дальше думаю объяснять не нужно.

А я не в курсе. Объясните подробнее, плиз...

[bti]

Crenth, скачиваем страничку, выковыриваем ключик, идем к серверу с видео и прикидываемся правильным плеером

[Crenth]

bti, ssid то одноразовый. вы только одно видео получите по нему. а чтобы качать без ограничений, надо стыривать все сиды с правильного сервера

[bti]

Crenth, и в чем собственно проблема?

захотели видео?
1) скачать страничку с плеером
2) выковырять из нее сид
3) обратится к серверу с видео и прикинутся правильным
4) захотели еще? повторить с п.1

[gloomyBrain]

@Crenth
Смысл в том, что скачивая страничку через URLLoader, вы не скачиваете сам плеер. Только ssid, который вписан в тэгах <Object> и <Embed>. Так как вы не скачиваете плеер, то обращения с данным ssid в базу не поступает => есть вариант притвориться "правильным", как и сказал bti

@Taner
Как вариант - компилировать swf на лету и отдавать его с вписанным внутри адресом видео. Тогда злоумышленник должен скачать Ваш плеер, распарсить байткод, вынуть адрес и только тогда он получит видео. Если компилировать со случайным именем переменной, содержащей адрес - фиг чего получится автоматизировать. Если же по тому же алгоритму еще и ssid прикрутить, то вариантов станет вообще немного.

[Crenth]

да, bti, я понял замысел.

однако, компиляция на лету увеличит время отклика.
если клиентов у этого плеера не много - никто этого не почувствует. а если тыщи - то компиляция загрузит мозги сервера по самые помидоры...

что если компилить не при каждом запросе на загрузку, а раз в T секунд, например.
а в теле плеера использовать функцию преобразования resp=F(ssid)
и на сервер слать не ssid, а resp.
например, сейчас мы скопилили плеер со встроенным механизмом resp=MD5(ssid)
через минуту функция будет уже resp=MD5(ssid+ssid)
еще через минуту функция resp=MD5(MD5(ssid))
а интервал перекомпилиции Т выбрать такой, чтобы он был меньше, чем теоретическое время на парсинг кода

[ageent]

Можно в зависимости от даты + (любой код) генерить уникальный md, при запросе проверять пришедший идентификатор. Если кто и сопрет идентификатор, проработает он не больше установленного Вами времени. как пример

[Psycho Tiger]

Но ведь можно вскрыть флешку и увидеть, как идентификатор составляется.

Защиты нет - если ваше приложение станет НАСТОЛЬКО популярным, что к нему будут писать палёные клиенты - я лично вам только позавидую.