Fixed potential path traversal attack and remote code injection

This is a security release. All users MUST upgrade to this release to prevent two potential security issues: path traversal attack remote code injection These two security issues have been reported by Andreas Forsblom. THANKS! Below is the original report Andreas sent me: Hi William, First, thank you for a very useful bundle :) Unfortunately, while investigating if a Symfony project I’m working on was vulnerable to the recent translation-related Symfony security issue (CVE-2014-4931), fixed in Symfony 2.5.2, I discovered that JsTranslationBundle seems to be vulnerable to a unrelated path traversal attack, and potentially also a js injection attack. -– If I try to retrieve the translations using the following url: http://localhost/translations?locales=randomstring/something the file something.js gets created in the subdirectory messages.randomstring of the cache directory: /var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/something.js (this is the actual string that gets passed to the constructor of ConfigCache by the JsTranslationBundle controller) I can now traverse down from the JsTranslationBundle cache directory (without first creating the “messages.randomstring” directory using the previous step, this won’t work): http://localhost/translations?locales=randomstring/../../evil becomes /var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/…/…/evil.js … and depending on the configuration of the server, I could also do http://localhost/translations?locales=randomstring/../../../../../web/evil => /var/www/someproject/app/cache/dev/bazinga-js-translation/messages.randomstring/…/…/…/…/…/web/evil.js thus creating the file evil.js (and evil.js.meta) under the Symfony web root. Depending on file system permissions, this will also overwrite existing files. -– Again depending on the server configuration, it also seems to be possible to inject actual JavaScript code: http://localhost/translations?locales=foo uncommented code; => (function (Translator) { Translator.fallback = ‘en’; Translator.defaultDomain = ‘messages’; // foo uncommented code; })(Translator); This works on some systems I tried, but not others. I suspect it might be related to the character set configuration, but I haven’t investigated it further yet. -– I did my testing using JsTranslationBundle 2.1.0 and Symfony 2.5.2. Since this is a security issue, I didn’t want to submit a pull request or use the GitHub issue tracker. Three commits fixed these issues: df6c0fd, 7accee9, and 6ee06b9. You will find three patch files below in case you can’t easily upgrade to this release. Changelog Fixed: hange test related to path traversal attack Fixed: potential code injection via locale parameter Added: test to prove a path traversal attack Added: HHVM support in travis-ci