Lumosity’s purchase pages rely on I18n to translate the various pieces across the numerous currencies and locales. This is ideal because we can keep all of this in centralized YAML files and keep it consistent as we add new languages and currencies.

Our pages are written using HAML and we use Rails partials to display the pricing for each subscription type across our various subscription options. We use ActiveSupport’s #number_to_currency method to help make the translations between currencies for each locale. This has worked well for us for some time, until we updated to Rails 3.2.17, which altered our purchase page to look like this:

Gross, what went wrong? Well, we found out that escape_unsafe_options is now called from inside of number_to_currency. This change happened due to a XSS security issues per this email from Aaron Patterson. From the post:

One of the parameters to the helper (unit) is not escaped correctly. Application which pass user controlled data as the unit parameter are vulnerable to an XSS attack.

So their fix was to make sure that the values were escaped, and this caused issues on our end as seen above, because now our own internal formatter’s HTML code was being escaped, and output HTML as plaintext to the page.

Since we are not using number_to_currency to receive user data, we were comfortable converting the escaped HTML back to unescaped HTML as so:

CGI.unescapeHTML(String.new(number_to_currency(amount, params)))

We don’t believe this fix is ideal for a few reasons. Having to work around Rails core is usually hairy, and then having to unescape escaped HTML just seems like it will come to bite us in the future. We are exploring other alternatives to how we generate this HTML going forward.

We are open to better solutions and hope this helps you with debugging.