Sunday, July 22, 2012

Code Obfuscation


Languages like C# and Java can be easily be de-compiled and now with more web applications using JavaScript we don’t even need to de-compile the code to see it.

Because of this, code obfuscators are on the rise.  One of the newest kids on the block is JScrambler (https://jscrambler.com/) made by AuditMark (http://auditmark.com/).

Code obfuscator’s work but do they provide any value? Do they add any value, for security, protecting our intellectual property, etc.?

Obfuscated code is modified on purpose to make it harder to read and making it more difficult to analysis what the code really does.  A key point here is this goal is a two way street.  It can be for someone trying to protect their intellectual property or for malware trying to prevent its detection by anti virus/malware scanners.  So our first point is obfuscated code can be used for and against us.

That brings up an excellent point. If your web site uses something like jscrambler should I have the right to inspect the JavaScript used by your web application to make sure it is not doing something evil? Remember the JavaScript is not running on the server it’s running on your box.

Code obfuscated makers say obfuscation provides the following benefits to its users…
  •       Protect Intellectual property (e.g. algorithms) contained in JavaScript.
  •       Prevent code reutilization.
  •       Prevent code modification.
  •      Prevent unauthorized code execution (piracy).
  •       Add another layer of security, by making it harder for attackers to interfere with your Web Application.


This last point is the most discussed point; does obfuscated code really provide a benefit as an added layer of security? Remember code obfuscation is NOT encryption.

Yes, obfuscated code does provide extra security. We know it can be broken/reverse engineered but the time and effort it takes does provide a temporarily determent to the causal hacker. In the long-run it will not protect your code.

Before using code obfuscation I think one of the first things we need to ask ourselves is “What are we trying to accomplish with code obfuscation?” with that question in mind here are a few guidelines.

  •    Never put sensitive information on the client (passwords, 'hidden" URLs, validation routines, encryption routines, etc).
  •    Understand that anything on a client can be compromised because you no longer have control.
  •   Any obfuscation of client-side code has to be un-done in order for the framework to process it... thus only providing only a marginal security improvement.


My personal take on this is JavaScript code obfuscation provides less transparency on the Web. Open transparency creates better privacy in that everyone can see what everyone else is doing in an open environment. The temporary time value of security gained by using obfuscation is not enough to overcome the potential downfall of a less open transparent environment.

A few other resources:
https://developers.google.com/closure/compiler/docs/api-tutorial3  Compression provides obfuscation as a side-effect.