Thanks Chris, Can you describe the symptoms of a deserialization attack, so I know the problem this is solving? (e.g. how would I know if it affects my app?)
> > On March 1, 2017 at 1:04 AM Christofer Dutz <christofer.d...@c-ware.de> > wrote: > > Hi guys, > > I just wanted to inform you that a few days ago I added some changes to > BlazeDS. > > What I did – besides some cleaning up – was to change some of the > defaults used by an out-of-the-box BlazeDS instance. > > Being the one maintaining BlazeDS I always got a little nervous when > reading about some deserialization problem in other projects. Usually I > checked if BlazeDS would be affected by the same problem. In the past usually > BlazeDS wasn’t, as it has a quite unique way of handling deserialization. But > my continued paranoia on this topic made me realize that we should change > some of the default settings: > > * First off … I disabled the deserialization of XML per default > > * Second I enabled the ClassDeserializationValidator to only allow > the deserialization of well-known classes (Whitelisting) > > The first change was due to the fact, that most of the problems we had in > the past were related to XML deserialization as this uses javas default > implementation and that is very powerful but also a good attack vector in > general. In most projects, I use BlazeDS in I never pass XML objects via AMF. > So, if you need to do this, you need to manually enable XML deserialization > in the channel definition by: > > <channels> > <channel-definition id="amf" class="mx.messaging.channels.AMFChannel"> > <endpoint url="Fehler! Linkverweis > ungültig.<http://%7bserver.name%7d:%7bserver.port%7d/%7bcontext.root%7d/messagebroker/amf>" > class="flex.messaging.endpoints.AMFEndpoint"/> > <properties> > <serialization> > <allow-xml>true</allow-xml> > </serialization> > </properties> > </channel-definition> > </channels> > > Second was my experience that if you setup a BlazeDS server you usually > know which classes are passed over the wire. Therefore per default, all > custom classes will be denied unless you explicitly allow them (patterns > allowed). > > Here I didn’t change anything with the validator, I just enabled it per > default and revised the Whitelist. > > I the services-config.xml you can define the allowed classes like this: > > <validators> > <validator > class="flex.messaging.validators.ClassDeserializationValidator"> > <properties> > <allow-classes> > <class name="org.dukecon.*"/> > <class name="flex.messaging.messages.*"/> > <class name="flex.messaging.io.amf.ASObject"/> > </allow-classes> > </properties> > </validator> > </validators> > > We have defined a whitelist which is used per default and have checked > that with several applications. I would like to ask you to check if this > whitelist is missing important entries. > > Right now, we have these classes listed: > "flex.messaging.io.amf.ASObject", > "flex.messaging.io.amf.SerializedObject", > "flex.messaging.io.ArrayCollection", > "flex.messaging.io.ArrayList", > "flex.messaging.messages.AcknowledgeMessage", > "flex.messaging.messages.AcknowledgeMessageExt", > "flex.messaging.messages.AsyncMessage", > "flex.messaging.messages.AsyncMessageExt", > "flex.messaging.messages.CommandMessage", > "flex.messaging.messages.CommandMessageExt", > "flex.messaging.messages.ErrorMessage", > "flex.messaging.messages.HTTPMessage", > "flex.messaging.messages.RemotingMessage", > "flex.messaging.messages.SOAPMessage", > "java.io.Externalizable", > "java.lang.Boolean", > "java.lang.Byte", > "java.lang.Character", > "java.lang.Double", > "java.lang.Float", > "java.lang.Integer", > "java.lang.Long", > "java.lang.Object", > "java.lang.Short", > "java.lang.String", > "java.util.ArrayList", > "java.util.Date", > "java.util.HashMap", > "org.w3c.dom.Document", > > With these changes, we should be safe against most of the deserialization > attacks now and in the future. > > Feedback highly appreciated. > > Chris >
