Backbone Patterns JSON preloading XSS vulnerability

February 10th, 2012 by Antti Vähäkotamäki

I was skimming through Backbone Patterns by Rico Sta. Cruz to see if I could learn something from the Backbone practices and apply it to our own in house systems that achieve pretty much the same things in a bit different manner.

The following code caught my eye as we at Meetin.gs have been bitten by the same problem in the past:

<script>
 App.photos = new Photos(<?php echo json_encode($photos); ?>);
</script>

The data in $photos is usually pretty arbitrary and it is hard to make sure that it does not contain something like this:

{ "name" : "</script><script>alert(\"xss\")</script>" }

The way we at Meetin.gs have solved this XSS vulnerability is by URI encoding the JSON on the page and then decoding it with decodeURIComponent before passing it to a JSON parser. Here is a quick (completely untested ) example with jQuery:

App.photos = new Photos( jQuery.parseJSON( decodeURIComponent(
    <?php echo rawurlencode( json_encode( $photos ) ); ?>
) ) );

It would be nice to see at least a note of this on the Backbone Patterns page as this vulnerability is not an easy one to catch and might end up in many places.

This vulnerability was at first brought to our attention by Harry Sintonen so huge thanks to him for it.

Taking Template Animation further

December 17th, 2011 by Antti Vähäkotamäki

Iain Dooley of The Working Software blog wrote about an idea he calls “Template Animation“, which seems to me to be in essence the principle of building dynamic sites with HTML snippets which hold no logical constructs. The idea is to create a separate template for each of the logically different view and achieve variable output by selecting the appropriate static template, interpreting it as a HTML DOM tree and using DOM manipulation to insert varying data.

In theory this seems like a very good idea because it would allow the HTML implementer to know nothing of the back end implementation and thus people could be brought in to projects to build HTML implementations with less case-specific introductory training. While the goal is intriguing, the proposed solution is in my current view only a small piece of the overall puzzle.

First of all I think drawing the line of “templates with logic” and “templates with no logic” to include variable substitution and list enumeration on the “no logic” side goes a long way to defeating the actual gains. Your HTML implementer still needs to test the templates with variable inputs (different strings that might be substituted and different sizes of enumerable lists) that are highly specific to your app.

One solution to this would be to categorize the variable inputs in categories that behave in a similar manner in a certain HTML context and then produce a different template for each category permutation. This requires a strict definition for the possible categories in different contexts and a way to convey the possible permutations from the designer to the HTML implementer. An example of a situation where this becomes an issue is when an user’s name is displayed on the page and the preferred display would be different if the name is so long that it does not fit on one line. The HTML implementer should then receive information that both of these cases are possible within this variable input and a different template should be produced for both category variations.

However the above example brings up an issue which is probably not very obvious if you haven’t done a lot of work with dynamic HTML generation with variable inputs: It is really hard for the server side (where the logic presumably lives) to know whether a name is too long to fit on one line or not. Obviously this is not a problem that is specific to Template Animation and does affect also conventional templates that are parsed on the server side. There are a couple of ways to approach solving these issues: Sometimes this can be dealt with by truncating the variable input to a length which supposedly never exceeds the reserved space (no matter what typography is selected). Other times you just instruct the HTML implementer to hide the part of the text that does not fit the provided space. But the most usual situation is that the best way is just to let the containing element grow vertically to make space for an another line of the variable text.

Template Animation should work pretty well on the first two cases where the variable input is always presumed to not alter the layout dimensions on the page. There is only one category of variable input and that can be communicated to the HTML implementer. But the third and very often necessary type of variable input representation presumably leaves us with two options. The first option is to instruct the back end server to know everything about the variable input container dimensions and the typography renderings in possible HTML rendering devices, categorize the variable inputs into separate categories based on how many lines they would span, and ask the HTML implementer to create a different template for each of the categories. And the second option is to tell HTML implementer that “This variable input might contain text that spans multiple lines – could you please test your template also with such longer inputs?”

I personally think that the server side font rendering path would be pretty tedious to get right but at least with a limited set of supported client side renderers, this could be doable. This would make it possible to reduce the variable inputs to categories and while this would sometimes exponentially grow the number of needed static HTML implementations, we could still remain sure that no additional testing is needed if all of the static HTML templates are checked to render correctly.

But what about the second option? Surely we can expect the HTML implementer to be able to do this tiny piece of testing in order to rid us of exponentially growing static template batches and the need to render fonts on the server side. This sounds very innocent, but actually opens up a very dangerous path where the templates do not only contain logic, but actually contains hidden logic that can not be read by just looking at the template. In effect the template is thus saying “If there is only one line of text, render a box of this size. Else if there is two lines of text, render a box of this other size. Else…” which is a form of logic that can easily conflict with the display of other elements on the page and must be taken into account on each iteration of the template.

So if we hold true to the goal of separating the application logic from the templates, we need to specify a separate logical branch for each of the permutations of the different variable input categories. In the same spirit we can also forget about letting the HTML implementer use any fragmentation methods that would get passed back to the application developers, and just provide full DOM implementations of each possible logical permutation of the system.

I think it is needless to say that in the case of dynamically created listings of user inputted variable data, this logic tree might grow to be really really big. With literally hundreds of logically different views it would not very feasible to think that a simple file name would suffice to map the logically different situations to their appropriate templates – or that anyone in their right mind would actually create each of these branches and map them to code individually by hand.

So basically we are left with either an option to use Template Animation only on a very limited set of use cases where the fully expanded logic tree stays very small, or the option to manage this complexity somehow. The tree-size related complexity would be present at least in a) formulating the logic tree in it’s fullest, b) communicating this logic tree to the HTML implementer in the context of the visual guidelines, c) removing the duplicate efforts on the HTML implementation process, d) verifying the correct output of the static HTML implementations and e) mapping the resulting HTML implementations to the logical branches of the application code.

Although this all seems like such a big hurdle that it seems to invalidate the Template Animation approach on bigger projects, I would like to argue that the awful state of the software projects today is greatly caused by the fact that the projects itself are (and grow to be) much more complex than most people can humanely envision. We take upon the tasks of software specification, implementation and validation as if they were trivial matters, employ inadequate or nonexistent tools and practices to carry them on and are usually left with poor results that grow even poorer when the project needs to be extended by an another team.

In my opinion Template Animation has huge promise in forcing us to standardize some ways in which product designers, visual designers, back end developers, front end developers and software testers communicate with each other. Using the full page DOM as the medium of exchange is a natural path which allows us to use many of our existing tools when interacting in the process. It also forces us to face the real complexity of the problem as each state of the program has to be explicitly recognized to communicate it using a static DOM implementation. And having a tangible representation of each visual state of the program makes it possible to employ easier ways to do visual regression testing.

There are still a couple of small things I envision to be a bit problematic with Template Animation, like how to coordinate on variable names and prevent DOM id clashes in projects that are developed in a distributed manner. Also partial page loads and other highly dynamic “AJAX” content might pose challenges that will make using full page Template Animation hard for some parts of the system. But as a new tool in my toolbox for the right situations, I would gladly welcome an easy way to outsource most of my HTML related implementation and testing tasks while still maintaining the possibility to hook the results into the dynamic back end of my choice.

As a closing note I would like to point out that I have noticed a faint trend in moving the HTML template processing partly or even completely to the client side (at Meetin.gs we have most of our templates on the client side). Parsing the templates on the client side is actually very beneficial for the Template Animation approach as it makes detecting rendered text dimensions a lot easier. It also makes partial content updates less of an issue as the renderer can render the whole page again without transferring the full state of the current page back to the server.

Root domains with Amazon Elastic Load Balancer

July 23rd, 2011 by Antti Vähäkotamäki

Root domain, also know as top level domain, naked domain or DNS zone apex, is your domain name without any subdomains. In our case our product web site and blog can be found at the www subdomain http://www.meetin.gs/ but our web application is being hosted at the root domain, namely just “meetin.gs”.

Amazons Elastic Load Balancer (ELB) has seemed like a very tempting offer for a long time since providing IP level fail-over on the web application front-end is a lot of work to achieve reliantly. Unfortunately it was previously impossible to use ELB to serve root domains because it would have required one to point the root domain to the ELB by a CNAME DNS entry and there is practically no sane way of using CNAMEs for root domains. For us that meant the service was of no use.

As of May 24 2011 Amazon seems to have found a way to fix this problem by adding a special ‘Alias’ entry to their own Route 53 DNS service. This allows you to set your root domain to return the A record associated with the ELB.

Currently it seems like using Amazons Route 53 DNS to serve your domain’s DNS requests is the only off the shelf way for serving root domains with ELB. I believe it would be technically possible for other DNS service providers to achieve almost the same level of service by implementing a similar ‘Alias’ functionality for mirroring the A records returned for an another domain with a small TTL but I’m not sure if it makes business sense. The only other product I know which would benefit from this is Google App Engine as it suffers from the same problem of not being able to serve root domains due to reliance on CNAMEs to point domains. Other cloud load balancing providers (at least Rackspace and GoGrid) seem to be doing load balancing tied to an actual IP address instead of a domain CNAME.

Also as a note for people trying this out: At this date Amazon Route 53 does not seem to have a graphical user interface on the AWS management console. It took me a while to figure out that you really have no other way of controlling it than using the Perl script they provide to send XML to their web service. Ouch. Hopefully a graphical interface will be added in the near future!

Validating Facebook Connect API cookies in perl

July 29th, 2010 by Antti Vähäkotamäki

I didn’t find a sample code for validating the Facebook Connect API cookies in perl from Google so here is one. The CGI::Cookie interface is a bit tricky to use with the Facebook cookie parsing as it wants to split the cookie contents automatically on each ampersand, but here is how we translated the given sample PHP code to perl:

use CGI::Cookie;
use URI;
use Digest::MD5;

my $app_id = "136913766343238";
my $secret = "dbct84ca3d1fbs44428r02bdbag9193e";
my $cookie_header = $ENV{COOKIE};

my %cookies = CGI::Cookie->parse( $cookie_header );
my $cookie_object = $cookies{'fbs_' . $app_id};

die unless $cookie_object;

my $cookie = join "&", $cookie_object->value;
$cookie =~ s/^[\\"]*(.*?)[\\"]*$/$1/;

my $uri = URI->new("", "http");
$uri->query( $cookie );
my %params = $uri->query_form;
my $sig = delete $params{sig};
my $payload = join '', map { $_ .'='. $params{$_} } sort keys %params;

die unless Digest::MD5::md5_hex( $payload . $secret ) eq $sig;

my $valid_facebook_user_id = $params{uid};

Splitting the query parameters would have been pretty easy to do with a regexp but as the sample PHP code uses it’s query parser, I thought using a valid query parser from URI would be a safe and easy bet.

Aggregating online presence

May 31st, 2009 by Antti Vähäkotamäki

As a part of something I just humoristically named “the communications review and growth initiative” at work, I registered into a couple of new services and my online presence should, as of today, be aggregated from my public blogs to FriendFeed, from FriendFeed to Twitter and from Twitter to Facebook.

If I find myself cooking up a presence on del.icio.us, Digg, Flickr or Youtube, they will be added to FriendFeed but for now I don’t feel like I would have much to offer on the Photo / Video / cool link sharing front as they are not part of my daily routine. Starting microblogging in Twitter feels like a big enough step for this week.

Now I just hope the aggregation works as I understood it would icon smile Aggregating online presence

Our media assistant trainee needs to get from 0 to 100 on video production, pronto. Any suggestions?

December 10th, 2008 by Antti Vähäkotamäki

Saija is interested in video production and is planning to film some interviews and short documentaries during her time as a trainee here at Dicole. She has done some amateur filming but considers herself a beginner. She wants to know good resources and helpful people to get started on video production. I’d imagine she will mostly be using our HD cam and iMovie HD on her Mac but good suggestions and learning resources are warmly welcome icon smile Our media assistant trainee needs to get from 0 to 100 on video production, pronto. Any suggestions? (myös suomeksi icon smile Our media assistant trainee needs to get from 0 to 100 on video production, pronto. Any suggestions? )

Opening the gates to a new religion

December 4th, 2008 by Antti Vähäkotamäki

I picked up my new shiny MacBook today. I’m also contemplating on building an altar for Steve, so that I could pray for a good user experience.

Connectivism in the grassroots of ITK 07

April 19th, 2007 by Antti Vähäkotamäki

I’m in ITK 07 conference and Karsten Wolf just gave a good keynote presentation. I think it brought together most of the relevant concepts that I would like to see all ITK participants grasping as the common basis for communication in other presentations.

I’m writing this blog entry briefly just to point out that while Wolf mentioned that the answer to the question “What is the role of collaborating and sharing in succesfull online learning?” is still largely unknown and under research, there exists a paradigm called connectivism which in my opinnion tries to answer to this question from a better point of view than could be easily possible using constructivism (or one of its various extensions) as a basis of thinking.

I’d also add on the subject that while Wolf pointed out that changes in the internet enable constructivistic learning to emerge from the grassroots, this has already been true from the beginning of the internet. The social transformation of the web (to which some refer as Web 2.0) does also enhance the possibilities for constructivistic learning but in my opinnion it enhances far more the ways of handling information and knowledge which connectivism touches on.

BTW. As this is a social conference, I’d be very interested if Wolf himself has something to add to this – so please join the conversation Karsten!

A blossoming nugget

March 31st, 2007 by Antti Vähäkotamäki

I haven’t been out in bars much for a long time since I have usually prioritized other activities over the odor of cigarettes, swarms of drunken finns and music so loud that you can’t really make up a good conversation. Yesterday Kim talked me over to spending the evening in Valter Cafe which to my lovely surprise seemed like an enjoyable non-smoking venue and after a couple of GTs I drifted into making acquintance with a friendly couple at a table next to ours.

From our conversation I picked up a golden nugget which seemed to resonate exceptionally well with my own gut feeling but in which I hadn’t put that much thought before and certainly couldn’t put into words as eloquently: In order to achieve the most in life it is not only important to grow as a person but to help others around you to blossom. (translated freely from finnish)

I’d like to believe that the gut feeling I have had about this has led me to help many great and likeminded people achieve more than they would have without me, but putting this feeling in such a concrete form will surely help me put even more attention to empowering others to drive forward worthy goals. And what is even better, I am now more able to encourage others to do the same!

For this and other enlightening insights that you shared with me tonight I would like to hearthly thank you Kalle, and if you read this, please drop me a comment or an e-mail with your blog/website address so that I can properly credit you with a link icon smile A blossoming nugget

Letting loose

March 30th, 2007 by Antti Vähäkotamäki

I am one of those people who like to have the feeling that they are going into the right direction. When somebody makes a decission which affects me and I feel that from my point of view this decission isn’t the right one, I usually engage quite eagerly in to a conversation about the views behind the given decission and why I would have made an another decission.

Sometimes I end up changing the decission and sometimes I end up learning to see the situation from a different perspective which jusfies the decission. To me this kind of a way to debate decisisons sounded at first like a good way to approach decission making in a small company like ours but after some frustrating experiences it has become more clear to me what is probably the cause of the overly hierarchical government model which enterprises of yesterday have drifted to (in my opinnion as a bit overly aggressive countermeasure): Converging different points of view takes a lot of time and effort and doesn’t often lead to a solution which is so much better that it would justify the effort.

As it is an integral part of my nature to question things and delve deeper into subjects it is quite challenging to learn to live with decissions that I don’t understand – even if they are only small ones. However it is a challenge that I feel that I must overcome in time to become a better colleague and also a better leader. This doesn’t mean that I will never again question any decissions but I will try to evaluate the possible outcomes of the process before giving up to my urge to understand, help others understand and ultimately set things right.

In the end it all comes to what we were talking the other day at lunch with Tommi: Maybe managing a company isn’t all that different from managing your personal life – in order to gain the most there are many things that are better to be left unmanaged and just trust that they can’t turn out so bad that the situation couldn’t be fixed anymore.