Felipe Gaúcho works as senior software engineer at Netcetera AG in Switzerland. He is a well known Brazilian JUG leader and open-source evangelist. Felipe works with Java since its early versions and has plans to keep that Java tradition as it is. When he is not coding, he prefers to listen reggae and travel around with his lovely wife Alena and his son Rodrigo. Felipe is a DZone MVB and is not an employee of DZone and has posted 29 posts at DZone. View Full User Profile

Compiling Your Own Byte Array Trojan With JAXB 2.0

09.17.2008
| 7322 views |
  • submit to reddit

When I started to use continuous integration against my own code, the very first results was 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 quality criteria of PMD and Findbugs, but some warnings persists 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 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 guilty the developer or even use some code quality metric to avoid this 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 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 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 a hope to find an elegant solution for that. Perhaps you know how to fix that :)

From http://weblogs.java.net/blog/felipegaucho/ 

Published at DZone with permission of Felipe Gaúcho, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Mario Schwede replied on Wed, 2008/09/17 - 6:59pm

Nice example of bad generated Code. You just have to write a program that replace the defect lines. Just go through your code with a regulare expression and replace that kind of Methods:

public byte[] getFlash() { return flash; } 

with

public byte[] getFlash() { return (byte[])flash.clone(); } 

and

public void setFlash(byte[] value) {  this.flash = ((byte[]) value); } 

with

public void setFlash(byte[] value) {  this.flash = ((byte[]) value.clone()); } 

For all mutable Types you use.

You can run the program during the build process, after the jaxb generation.

This maybe brake the rule: Never edit generated code.

But it is a workaround.

Michael Bien replied on Thu, 2008/09/18 - 9:05am in response to: Mario Schwede

... or simple file a bug(+patch) against jaxb2.0.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.