Provide a warning about xss implications

[chrissrogers]

t('{hasOwnProperty(alert("xss"))}');

demonstrates the translation string as a potential xss vector. It's not hinted anywhere in the API docs that one should stick external vars in the translation string, but it might be helpful to mention that such a thing should be avoided.

In lieu of a disclaimer, it would be possible to remove the vulnerability by splitting tokens by the dot and recursing down obj with string accessors.

[Swatinem]

CC @cristiandouce who wrote that code.

Thanks for pointing this out. I guess we really only need token chaining, and not a whole function wrapper like to-function does for things like property > value. So I’m happy to have this cleaned up.

[cristiandouce]

Point taken!

Although, I'm still trying to imagine a situation where a developer using component/t would auto-inject XSS in its own code by writing such kind of tokens.

[Swatinem]

It’s more likely they will feed user generated things into it.

[cristiandouce]

Yeah, that's what I don't get... how a user generated thing could end into a token definition in a code that has been sent by a server and generated by the developer.

But it's ok. I'll change it as soon as I have time and open a PR.

With the discussion I'm just trying to open my mind and learn something new, no mean to minimize this change at all.

Thanks!

[chrissrogers]

Here's a (somewhat odd) example of how the vector could be mistakenly opened:

var t = require('t');
var querystring = require('querystring');
var page = querystring.parse(window.location.search).page;
t.en = { "home": "Hello {name}, you are on index.html!" };
t(page, { name: 'alexander' });

which would be exploited by visiting index.html?page={hasOwnProperty(alert("xss"))}.

While this is somewhat contrived, and not a suggested usage of the module, it demonstrates the unexpected side-effect.

Hope that's a decent demonstration 🍊

[cristiandouce]

Yeah, it is odd.
Sweet example though!