Archive for the ‘Meetin.gs’ Category

Backbone Patterns JSON preloading XSS vulnerability

Friday, February 10th, 2012

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.

Root domains with Amazon Elastic Load Balancer

Saturday, July 23rd, 2011

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!