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
