[osflash] secure my application...

Samuel Agesilas samuel at modulous.net
Tue Nov 6 10:41:54 PST 2007


Marcelo,

If I may chime in this discussion.. what are you trying to protect?  
The actual swf or access to services exposed in the swf?

cheers,
Sam

On Nov 4, 2007, at 6:42 PM, Jonathan Valliere wrote:

> Marcelo,
>
> As far as referrer checking, your going to need to search google or  
> get in touch with a Red5 developer ( put it on the Red5 mailing  
> list ).
>
> Encryption:  You can load in SWF binary via ByteArray and encryption  
> can be done with ByteArray data ( that can be loaded via ..  
> Loader ?? ).  Essentially you encrypt your SWF binary ( and store it  
> encrypted on the server ) and load it in over HTTPs and decrypt it  
> based on a public/private key based on a secondary encryption  
> mechanism located inside the first one and load into a SWFLoader at  
> runtime.  Run the entire application over HTTPs with cache off and  
> it should be pretty dam secure.
>
> http://en.wikipedia.org/wiki/Public-key_cryptography
>
> http://en.wikipedia.org/wiki/Encryption
>
> http://en.wikipedia.org/wiki/Topics_in_cryptography
>
> I bet there are a lot of good books on Cryptography.
>
> -Jon
>
> On Nov 4, 2007, at 7:24 PM, Marcelo de Moraes Serpa wrote:
>
>> Hello Jonathan,
>>
>> You could protect swfs over RTMP via Red5 to make sure of a correct  
>> referrer.
>>
>>
>> You could also load in an encrypted SWF that contains a secondary  
>> encrypted Binary file that self-decrypts ( and runs ) and is  
>> responsible for referrer / self-authentication over HTTPS / RTMP.
>>
>>
>> Any examples or maybe pointers to articles that elaborate on these  
>> techniques?
>>
>> Thanks,
>>
>> Marcelo.
>>
>>
>>
>> On 11/4/07, Jonathan Valliere <sybersnake at gmail.com> wrote:
>> yeah but you can't protect against everything.  you can encrypt  
>> your swfs, decrypt them clientside but that could also ultimately  
>> be faked given enough time and data capture.
>>
>> You could protect swfs over RTMP via Red5 to make sure of a correct  
>> referrer.  You could also load in an encrypted SWF that contains a  
>> secondary encrypted Binary file that self-decrypts ( and runs ) and  
>> is responsible for referrer / self-authentication over HTTPS / RTMP.
>>
>>
>>
>> On Nov 4, 2007, at 12:23 PM, Marcelo de Moraes Serpa wrote:
>>
>>> Red the URL from the browser and see if the domain is valid.  I  
>>> forget how to get it normally but in Flex you get it this way
>>>
>>> Yes, but one could possibly decompile the SWF and remove this code  
>>> (since it is client side).
>>>
>>> On 11/4/07, Jonathan Valliere <sybersnake at gmail.com > wrote:
>>> Red the URL from the browser and see if the domain is valid.  I  
>>> forget how to get it normally but in Flex you get it this way
>>>
>>> Application( Application.application ).url
>>>
>>>
>>> On Nov 3, 2007, at 11:40 AM, Jean-Philippe DELAVALLADE wrote:
>>>
>>>> It's perhaps a solution
>>>> but i prefer using a referer like in Flash Media Server
>>>> I don't find it in RED5
>>>>
>>>> Le 3 nov. 07 à 16:23, Marcelo de Moraes Serpa a écrit :
>>>>
>>>>> Hmm.. yep, haven't though about the domain restrictions of the  
>>>>> player, it might work!
>>>>>
>>>>> @Paul: Afaik, it works like this: When the player downloads a  
>>>>> SWF from a domain, it looks for a crossdomain.xml file that in  
>>>>> turns contains rules on which other domains are allowed to play  
>>>>> your SWF files you are serving through your domain. Please  
>>>>> someone correct-me if I'm wrong.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Marcelo.
>>>>>
>>>>> On 11/3/07, Jean-Philippe DELAVALLADE < jeanphide at orange.fr>  
>>>>> wrote:
>>>>> Thanks Paul :)
>>>>> Add a cross-domain policy, which prevents unauthorized domains  
>>>>> from accessing your assets.
>>>>> but how ??
>>>>>
>>>>> Le 3 nov. 07 à 14:42, paul|LOWRES a écrit :
>>>>>
>>>>>> maybe a cross-domain policy is, what you are looing for?
>>>>>>
>>>>>> http://livedocs.adobe.com/flash/9.0/UsingFlash/help.html?content=WSd60f23110762d6b883b18f10cb1fe1af6-7b35.html
>>>>>>
>>>>>> cheers,
>>>>>> paul
>>>>>>
>>>>>>
>>>>>> Am 03.11.2007 um 14:01 schrieb Marcelo de Moraes Serpa:
>>>>>>
>>>>>>> Hello Jean,
>>>>>>>
>>>>>>> I'm also searching for a way to restrict my flash application  
>>>>>>> in a domain. Actually I thought in serving the SWF through a  
>>>>>>> script instead of letting the webserver serve it so that I  
>>>>>>> could do this referrer check server-side (Using Ruby/Rails or  
>>>>>>> PHP for example). Code to check the referrer in the SWF could  
>>>>>>> work but someone could decompile your SWF and remove this check.
>>>>>>>
>>>>>>> If someone got some ideas regarding that, please share!
>>>>>>>
>>>>>>> Marcelo.
>>>>>>>
>>>>>>> On 10/26/07, Jean-Philippe DELAVALLADE < jeanphide at orange.fr>  
>>>>>>> wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> I would like to protect my application, do a referrer in fact
>>>>>>> I've tried this code but the server never run with that :
>>>>>>>
>>>>>>> public boolean appConnect(IConnection conn, Object[] params) {
>>>>>>>     	String pageUrl =  
>>>>>>> (String)conn.getConnectParams().get( "pageUrl" );
>>>>>>>     	 log.debug( "L'URL de la pages est : " +pageUrl);
>>>>>>>     	 if(pageUrl != "http://mydomain"){
>>>>>>>  	 return false;
>>>>>>>         	 }
>>>>>>> Can you show me the way, in order to my appli just run under  
>>>>>>> my domain ?
>>>>>>>
>>>>>>> Thanks guys
>>>>>>>
>>>>>>> JP
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> osflash mailing list
>>>>>>> osflash at osflash.org
>>>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> osflash mailing list
>>>>>>> osflash at osflash.org
>>>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>>>>
>>>>>> _______________________________________________
>>>>>> osflash mailing list
>>>>>> osflash at osflash.org
>>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> osflash mailing list
>>>>> osflash at osflash.org
>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> osflash mailing list
>>>>> osflash at osflash.org
>>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>>
>>>> _______________________________________________
>>>> osflash mailing list
>>>> osflash at osflash.org
>>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>
>>>
>>> _______________________________________________
>>> osflash mailing list
>>> osflash at osflash.org
>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>>
>>>
>>> _______________________________________________
>>> osflash mailing list
>>> osflash at osflash.org
>>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>
>>
>> _______________________________________________
>> osflash mailing list
>> osflash at osflash.org
>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>>
>>
>> _______________________________________________
>> osflash mailing list
>> osflash at osflash.org
>> http://osflash.org/mailman/listinfo/osflash_osflash.org
>
> _______________________________________________
> osflash mailing list
> osflash at osflash.org
> http://osflash.org/mailman/listinfo/osflash_osflash.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://osflash.org/pipermail/osflash_osflash.org/attachments/20071106/7cbfaeab/attachment-0001.html 


More information about the osflash mailing list