Archive for category Software

ColdFusion: XSS Vulnerability in SerializeJSON()

There is a minor vulnerability in ColdFusion’s SerializeJSON() method. ColdFusion fails to escape object keys correctly.

Here is a typical example of the expected way to use SerializeJSON():

The output of this is:

The bug is that object keys are not properly escaped, so if you have an object such as a Struct with a specially designed key, you can inject javascript code where it was not intended:

The result of which is:

As you can see, the generated javascript will be parsed by the browser successfully – except where we only intended to communicate data, we instead executed a function.

So what’s the danger?
The problem is that some users may wish to give easy access to GET and POST (URL/FORM) variables to their client-side javascript – maybe some of these parameters affect how you output data for example. If you just SerializeJSON() the URL or FORM variable, then you may unintentionally be allowing user-supplied data to execute in your page context, which can result in cookie stealing, malicious script injection, and other nasty things like that, by the user including javascript code as the name of a URL argument. Actually exploiting that takes some creativity due to ColdFusion automatically upper-casing URL keys, but that’s a one-time exercise which I’ll leave for the reader (sorry script kiddies).

SerializeJSON() should be safe, it should only create a JavaScript object which represents the data, and should not allow for script injection. The fix for Adobe would be incredibly simple; all they would have to do is escape object keys the same way they already escape output strings.

No Comments

ColdFusion: SerializeJSON() Recursion Error

In ColdFusion 8, Adobe introduced a new function called SerializeJSON(), which takes a single object of just about any type and returns a JSON representation of that object and its properties.  This can include objects which are not native ColdFusion types such as a Java object, and it does a respectable job of figuring out values for this object to include in the JSON by automatically and recursively including the values of any zero-parameter methods which start with ‘get’ such as ‘getName(),’ ‘getAddress(),’ etc.

In theory this works well because for essentially no additional effort, you can send a JavaScript representation of this class down to the browser and interact with it there.

There are a number of shortcomings to this approach though, not the least of which is the inability to filter what properties of a Java object are exposed to the browser when serializing it.  Sometimes objects have sensitive data stored in them which you do not want to expose.  For example if you had a page which details a user’s profile, and you store the properties of this user in a Java bean, you cannot simply pass the same copy of the user object down to the browser through SerializeJSON() as you might be tempted, as this may contain sensitive values such as getPasswordHash() or getAdministrativeNotes() (something I use in  to keep private notes on users especially for when a user has a history of abusive behavior).

However there’s an outright bug in the serialization routine which is essentially unrecoverable if you encounter it.  We first discovered it at work when working with a Java enum data type; having a getter or property whose value was a Java enum will cause you to get a stack overflow exception.  For example:

If you create an instance of this object, you can see the error:

This actually fails on a level that a normal try/catch cannot recover from it. The only way to see the actual error is to handle the error from an Application.cfc onError() method. Here is the error:

The problem is that enums are actually for the most part a java sub-class which have public final static properties for each of the possible enum values. ColdFusion is attempting to serialize the public final static property which is the same class as itself, and this ends up creating a circular reference as far as ColdFusion is concerned. It’s not actually a circular reference in the traditional sense; static class properties are not subject to reference counters and garbage collection – they are part of the permanent generation in Java. The “circular” reference is also created by the compiler and are an endemic aspect of enums.

As already stated, the problem is not limited to java enums, that’s just the first place we noticed it. Common Java design patterns like the Singleton pattern will raise this error as well, if the singleton accessor begins with ‘get’ or the static instance is public:

What can be done to fix it? From an implementation perspective you would have to change your object interface to avoid the problem as it exists today in ColdFusion 8. Essentially you need to be sure that there are no getters or public static properties which may back-reference to the owning class. If you require such, you must put them behind a getter instead of a public static property, and you must also make sure that getter doesn’t start with ‘get’. Essentially you have to kludge the crap out of your Java objects.

From Adobe’s perspective they need to detect a recursion loop and avoid it. Alternately they could provide a way to overload the JSON output for a java object (eg if they test for the existence of a toJSON() method and use its output instead of constructing the object properties themselves). Ideally they would do both, but although this latter approach would offload much of the work to individual developers, it would also give the develoer a way to filter the properties which were output as part of the JSON implementation of an object. The developer could even create flags on the object that allow them to select from several sets of specific properties as necessary (for example, setJSONPrivilege(PUBLIC | PRIVATE) ).

No Comments

One Man’s View is Another Man’s Data

I think it’s common for a developer to get the idea in his or her head that developing under an MVC (Model View Controller) paradigm is ultra cut and dry: There is one Model, one View, and one Controller for a given task. Within a given layer of the software stack this may often (or even always) be true.

However: all software produces something (in its view) which is consumed by the next higher tier of the software stack as data, and thus is only part of the model for that next stack. All software produces something to be consumed by something else. What is to you a view is to someone else data.

So it’s important to avoid thinking that there’s something special about your particular view (no matter where you are in the stack) – as if it’s somehow magical and the view. You’re never the end of the line, it doesn’t matter how far down the line you really are. The end of the line is the brain of the human who will ultimately consume this data. Even then they’re not the end of the line, they process that data, make decisions based on it, and produce some output of their own – whether it’s using it to produce new data for the next action within the application, taking that data elsewhere as an input to a different process, or storing it to memory for later use as data for a future process.

Let’s look at an example from web development. The PHP/ColdFusion/ASP.NET/Ruby/FOTM developers I know tend to think of themselves as the end of the line (and I have too to a substantial extent). They’re producing something to be consumed (as they see it) by the end user. This is the guy who gets to make the HCI (Human-Computer Interaction) interface that either creates a positive experience for the user, or a negative one. Everything past him just follows the instructions he produces. Bold this, outline that, send this data there. What’s harder to see is that he’s just following the instructions he was given by the user and producing data in a format that other software later in the stack requires of him.

What the web developer calls data is actually just a view provided by lower down in the stack (a database typically, which in turn gets a view of stuff from the filesystem which it calls data, etc). A web developer’s view (HTML typically) is just data to the web browser. The web browser’s view (graphical representation) is just data to the display driver. The display driver’s view (bits of light on a computer monitor) is just data to the user.

The software stack starts and ends with the user. If anything is sacrosanct, the ultimate MVC, it’s the user. But as I’ve already said, the user ends up just starting the cycle again, maybe she uses that data to feed the computer again, or maybe she uses that data for another purpose.

So don’t get caught up in “HTML is the view, XML/SOAP is data,” it’s all data to someone, and therefore it’s all a view to you. Don’t think there’s something special about one way to structure data vs another way to structure data. Finally don’t create different channels depending on what consumes your data. Use the same data channels (Model/Controller) and provide a different View. That is after all what the purpose of a View is all about – consumer agnosticism.

, , ,

No Comments

Photoshop Express

Adobe released Photoshop Express.

Looks like a very slick flex application. Similar interface to the share site that Adobe has to share documents.

I have limited photos at work, but I’ll continue to play with this over the weekend. It seems to have improved photo editing capabilities and it can login into Picasa/Facebook/Photobucket and get pics from those apps.

Nice job adobe.

, ,

1 Comment