macromedia flash flash remoting: Hopefully this hasn't already been hashed out somewhere. I couldn't find it
if it was. A few thoughts and one question regarding security in Flash
Remoting w/ .NET:

(Everthing below is in regards to using Flash Remoting to call class methods
in .NET Assemblies directly.)

1) It seems that a remoting Flash client has access to any class that
provides a default constructor, and is located in an ASP.NET application's
assembly cache. This would seem to be a potential security issue, no?
Imagine a nieve database connection class with a default constructor and the
method "getDbPassword()".

I've seen no mention of this though, except on the Java side. This spells
it out very clearly and represents a working solution for the Java side.
http://carbonfive.sourceforge.net/flashgatekeeper/

Am I missing something on the .NET side, or does the .NET Flash Remoting
gateway implementation have a very similar problem?

2) I did some tests though, and it seems it is NOT possible for Flash
remoting client to instantiate and call methods on any .NET framework
classes. I only did some rudimentary testing though. Does anyone know what
the real restrictions are, or are not?

3) As a potential workaround, I have determined it's possible to intercept
Flash Remoting calls on the server-side by subclassing IHttpModule with a
custom class that brokers calls and events for the GatewayController class
in flashgateway.dll. (The custom HttpModule needs to be configured in place
of the default gateway module in the web.config file as well.)

During the intercept, I can use other available classes and methods from
flashgateway.dll to parse the AMF request and allow or deny the request
based on the class name being loaded. (Specifically, using the
MessageDeserializer class.) However, applying this intercept for security
checks requires two parse operations for each Remoting call. Not exactly
efficient.

Any thoughts?

- josh

We have stumbled on this problem as well when performing a security audiit on
some Flash Remoting application.
Our test's showed that you can only access methods that are defined public
which limit's this vunerability somewhat. Making sure you only have methods
that are meant to be accessable from Flash as public and the rest as internal
or even more resitricted, will provide some security.
We're not quite sure of the underlying resitrictions and therefore have
submitted this as a support incident and are still awaiting an answer from
Macromedia.

Having a custom HttpModule in between seems the recommend approach but indeed
creates some overhead. Would be nice if you could just configure the
flashgateway itself a little more finegrained on this. Otherwise it's again
another argument to stay away from Flash Remoting and just use plain XML or
SOAP interfacing.

We were actually also worried about the 'feature' that you can automatically
access some external webservice via de Flash Remoting gateway (as described in
[L=http://livedocs.macromedia.com/flashremoting/mx/Using_Flash_Remoting_MX/using
FRNET5.htm#1170220]http://livedocs.macromedia.com/flashremoting/mx/Using_Flash_R
emoting_MX/usingFRNET5.htm#1170220[/L]) but it seems that it's disabled by
default now.