I think you're misunderstanding my argument Mark. Of course you can spoof any message you want, and you don't have to be an expert either to do it; you could use the amfphp service browser of SabreAMF as a library or a Flash movie to send any message whatsoever to a gateway.
The issue with class mapping is that when developers put something in the service folder, they know that the code can be included and methods run on it. If they care about security, they will take care that the methods defined are not dangerous if remotely executed with other data. But from talking to a very well-known blogger (a Java fan) and seeing some of the new code that is going around in tutorials, I see that while people are taking care of escaping strings before sending them to a database and the like, they don't bother to check the argument type that's received, and while that may not be dangerous if you receive an array instead of a string, it may be if you receive a live object which has code in it which may be executed. The locking mechanisms which apply to amfphp, WebORB or Fluorine are per-method, but class mappings in most implementations is per gateway (at least, that's what it is in amfphp, Fluorine, or OpenAMF). So you could call an unlocked method with a mapped class that you would only expect to receive in a locked method, and if that mapped class has side-effects it could do some damage. Because class mapping and VOs are often used in database scenarios, we're talking about potential data-loss issues here. It's a far-fetched scenario, but the main issue is that it is such an unobvious scenario that you might not actually think about it, and you might not think about securing against it. About the "Our implementation (weborb) does it quite well", I'm not sure what you're referring to by "it". Could you expand? Patrick Mark Piller a écrit : > > Zoli is right. Usage of a specific object type in a method signature > is irrelevant to security. In fact, you do not even need to know AMF > to do it. One could easily use something like ServiceCapture to > understand the structure of the argument type then construct a similar > object and run it a local Flex/Flash movie with unrestricted security. > Essentially it means that a gateway must safeguard against such > malicious attacks. Our implementation (weborb) does it quite well. > > Cheers, > Mark > > --- In [EMAIL PROTECTED] ups.com > <mailto:flexcoders%40yahoogroups.com>, "Zoltan Csibi" <zoltan.csibi@ ...> > wrote: > > > > > > What I mean is: if I can sniff what typed VO an application is > receiving, I > > can "craft" an AMF packet with: > > - call to "deleteUser" > > - the same VO "type" (simplified: as we know that this is just a > string of > > the class name followed by other strings describing property names > and other > > binary data with property values etc etc etc) > > > > The gateway (fluorine, openamf, fds ... anything) will see a "valid" > > object/type. There is no type-coercion error here. > > > > This is an easy task to do with AMF knowledge. > > > > > > Bottom line: I don't think that passing simple types, untyped VOs or > typed > > VOs makes any difference from security point of view. > > > > > > Mit freundlichem Gruß, > > Zoli > > > > > > > > ____________ _________ _________ __ > > > > From: [EMAIL PROTECTED] ups.com > <mailto:flexcoders%40yahoogroups.com> [mailto:[EMAIL PROTECTED] > ups.com <mailto:flexcoders%40yahoogroups.com>] On > > Behalf Of Patrick Mineault > > Sent: Thursday, January 18, 2007 6:29 PM > > To: [EMAIL PROTECTED] ups.com <mailto:flexcoders%40yahoogroups.com> > > Subject: Re: [flexcoders] AMFPHP & Security > > > > > > > > Wouldn't Fluorine and OpenAMF throw a type-coercion error, given that > > the first argument is typed? Of course, the code in the constructor > > would be called anyways. > > > > Patrick > > > >
