Binding and obfuscation

Hi friends,
I’m using ProGuard to
obfuscate
a vaadin application.

In order to get the binding work correctly I have to exclude the pojos member from renaming.
The reason is quite clear: the
binding uses reflection
to access the fields.

Is there a way, to workaround to this ?
We have many ui-pojos and keep all of them unobfuscated leads to a clearer scenario to any malicious attacker.
We deploy our application in remote and ‘untrusted’ locations.
Sadly we are not safe and sound on a secure web server :frowning:

Are you aware of some trick (through annotations or other means) to let the obfuscation process wildly scramble our beloved jars and keep vaadin binding up&working ?

thanks in advance
Simone

[b]

[/b][b]

[/b][b]

[/b][b]

[/b][b]

[/b]

Oh, I’m really going to consider any option :slight_smile:

Obfuscation only slows down the determined attacker a little, it is not effective security on its own. My first recommendation would be not to rely on it too much but rather on sound design of the interfaces from that application onwards and designing them to be secure even against attackers who would have access to the source code (proper use of cryptography, …).

Unfortunately, at least Java 7 and older do not support proper method and field references without using strings to identify them.

If you do obfuscate UI pojo field and accessor names, you probably need to give up automatic bindings and BeanItem(Container) and rather use some other container to which you copy data from the pojos or that you link in some other way to pojos.

A very incomplete list of other points to take into account if you do try to go ahead with obfuscation:

  • Your servlet/UIProvider should skip the use of reflection if the related classes or methods are renamed.
  • State and RPC implementations and their parameters/contents for standard and custom widgets must not be obfuscated.
  • Standard event listener methods and the related event classes used/called by component implementations should not be renamed.
  • You might need to override FieldGroup.findPropertyId() and getFieldsInDeclareOrder().

Hi Henri,
thank you for your answer.

The first concern for us, regarding my question, is to protect the sources.
Our design considerations are not related to the risk from reverse engineering.
We always try to keep the design safe and sound.

I agree with you, Java 7 does not have proper ways to get fields information without using literals.
Are you aware that something is going to change in Java 8?

best regards,
Simone

Java 8 will have
method references
but I am not aware of whether it will have similar field references.

Vaadin will need to stay compatible with older JREs for quite some time to come, so unfortunately the framework cannot really switch to using such new features but you could have your own alternative versions of certain classes to get around name based method references. Note that even method and field references might not help as much as one may think for things like FieldGroups as they still need to be bound to the UI names somewhere if those cannot be generated automatically.