Hi,

Maybe someone can confirm this for me... Just had an exploit in a chat
application that used SharedObject.send() for the sending of messages
from the server to the client.

As long as a client is connected to a SharedObject that is initated on
the server, there is no way to prevent/limit a client from issuing the
so.send() command that calls a function on all other clients.

Now what can be done to prevent clients from updating the contents of a
SharedObject that is initalized on the server? Is issuing a simple
so.lock() after creating the SharedObject all that it takes to prevent
updates by any clients?

Lastly, as a quick fix to get around the SharedObject.send() problem. I
instead created a NetStream object on the server, that published an
empty stream. I then had the clients subscribe to that NetStream, and
included the function calls needed as callable from the NetStream.send()
command on the server. The docs I read somewhere said that only the
"publisher" of the stream (in this case, the server app) can issue
NetStream.send() commands. Can anyone confirm that my assumptions are
correct?

What a fun 5 hours figuring out that booger! 

Best Regards,

Mike Weck

 ________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

[ Post a follow-up to this message ]

Hi Michael,
Check out client.writeAccess. You can always put a shared object in a
directory. For example on the server:

so = SharedObject.get("readOnly/testSO", false);

and only allow the client to read it by giving write access somewhere else:

client.writeAccess = "public"

Now the client can only write to Shared Objects in the public directory....

You could have the client use nc.call to send an update to the server.
If the server finds the update is valid it can do the so.send() to all
the clients.

Yours truly,
-Brian

Michael Weck wrote:

> Hi,
>
> Maybe someone can confirm this for me... Just had an exploit in a chat
> application that used SharedObject.send() for the sending of messages
> from the server to the client.
>
> As long as a client is connected to a SharedObject that is initated on
> the server, there is no way to prevent/limit a client from issuing the
> so.send() command that calls a function on all other clients.
>
> Now what can be done to prevent clients from updating the contents of
> a SharedObject that is initalized on the server? Is issuing a simple
> so.lock() after creating the SharedObject all that it takes to prevent
> updates by any clients?
>
> Lastly, as a quick fix to get around the SharedObject.send() problem.
> I instead created a NetStream object on the server, that published an
> empty stream. I then had the clients subscribe to that NetStream, and
> included the function calls needed as callable from the
> NetStream.send() command on the server. The docs I read somewhere said
> that only the "publisher" of the stream (in this case, the server app)
> can issue NetStream.send() commands. Can anyone confirm that my
> assumptions are correct?
>
> What a fun 5 hours figuring out that booger! 
>
> Best Regards,
>
> Mike Weck
>
>  ________________________________________
_______
> FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcomm
>
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com



--
 ________________________________________
______________________________
Brian Lesser
Assistant Director, Teaching and Technology Support
Computing and Communications Services
Ryerson University
350 Victoria St.
Toronto, Ontario                   Phone: (416) 979-5000 ext. 6835
M5B 2K3                            Fax: (416) 979-5220
Office: AB48D                      E-mail: blesser-6s6ziW1YCwCw5LPnMra/2Q@pu
blic.gmane.org
(Enter through LB66)               Web: http://www.ryerson.ca/~blesser
 ________________________________________
______________________________

 ________________________________________
_______
FlashComm-1Ss2GqJETD3yZ38Mhd3e/9ZfFG6BLHNm@public.gmane.org
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcomm

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

[ Post a follow-up to this message ]