flex-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject [BlazeDS] Changed defaults -> increased security
Date Wed, 01 Mar 2017 09:04:57 GMT
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



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message