Skip to main content

Compiling your own byte array Trojan with JAXB 2.0

Posted by felipegaucho on September 17, 2008 at 7:16 AM PDT

When I started using href='http://fgaucho.dyndns.org:8080/hudson/'>continuous
integration against my own code, the very first results were buggy as
expected, a lot of warnings, bugs and minor mistakes. Step by step, I am
tailoring my source code in order to satisfy the href='http://weblogs.java.net/blog/felipegaucho/archive/2008/08/findbugs_and_pm.html'>quality
criteria of PMD and Findbugs, but some warnings persist and some of
them make me worry about the code quality I am delivering to my
customers.

From the controversial analysis results, one specific issue
remains unanswered: the exposition of internal representation of mutable
objects.

The risks of exposing internal representation of mutable
objects

Problem description: imagine you have a class member of type
array of bytes, and imagine the public getter method of this field
returns a reference to the array. It allows any external code to
manipulate the contents of this field without the control of its owner
instance (goodbye encapsulation). From the href='http://findbugs.sourceforge.net/bugDescriptions.html#EI_EXPOSE_REP2'>Findbugs'
bug descriptions:

EI2: May expose internal
representation by incorporating reference to mutable object
(EI_EXPOSE_REP2)
- This code stores a reference to an externally mutable
object into the internal representation of the object. If instances are
accessed by untrusted code, and unchecked changes to the mutable object
would compromise security or other important properties, you will need
to do something different. Storing a copy of the object is better
approach in many situations.

If such exposition comes from a hand crafted code, you can blame
the developer or even use some code quality metric to avoid that kind of
risk comes out to the release. But what to do when it comes from an
automatic process? Well, that's what happens when you href='http://java.sun.com/webservices/docs/2.0/tutorial/doc/JAXBUsing3.html'>unmarshal
base64Binary schema elements with JAXB 2.0.

Compiling your own byte array Trojan

Ok, it can be excess of paranoia, but if you compile a schema
containing elements defined as base64Binary, JAXB will compile it as byte[]
and give it public access methods, like the example below:

XSD fragment:

    <xsd:complexType name="ImageAttachment">
      <xsd:sequence>
        <xsd:element name="name" type="xsd:string" />
        <xsd:element name="flash" type="xsd:base64Binary"
          mime:expectedContentTypes="application/x-shockwave-flash" />
      </xsd:sequence>
    </xsd:complexType>

JAXB 2.0 generated class fragment:
    public class ImageAttachment
    {
        protected byte[] flash;
        public byte[] getFlash() {
            return flash;
        }
        public void setFlash(byte[] value) {
            this.flash = ((byte[]) value);
        }
    }

Workaround

Here are the few workarounds I assume reasonable to adopt in such
situation:

  1. To ignore or to disable this specific Findbugs warning, assuming
    getters and setters or any other generated code don't need to be
    checked anyway.
  2. Create your own type wrapping the byte array. Humm :(
    eventually useful, but if you are not following any standards like
    MIME-types.
  3. Use a JAXb customization to change the way the element is
    marshaled and un-marshaled, forcing the copy of the array contents.
    It forces you to create custom code, quite boring if you have several
    mutable objects around, but it seems to be the correct way to go.

So far this is the only one bug pointed by Findbugs over my
project, so I prefer to keep the warning alive in in my quality reports,
in the hope to find an elegant solution for that. Perhaps you know how to
fix that :)

Related Topics >>