IMHO this check is actually necessary, as we do call the function with an empty argument. So we need a guard there, but we could simplify it a bit, by making the argument an empty array by default. I still kept the check for undefined (line 3249, first check) in case the caller passes us an undefined variable.
See: https://github.com/PrivateBin/PrivateBin/security/quality/rules/js%2Funneeded-defensive-code - Copilot suggested to simply remove the if-condition and its else block, which I think is wrong.
- added missing exception doc blocks
- introduced exception type that translates message during construction
- catch explicit exception types where possible
- avoid translating JSON error messages twice
- separation of concerns, JSON response preparation should not mix handling errors and results, provide two functions instead of one
- callers of JSON error method are responsible for translation of errors
Fixes#1712
Disclosure: Coded with help of Copiot. (description wrtten by me)
So this does indeed loosen the encoding a bit. However, IMHO, it was neither better before though. You could always bypass the encoding for `args{0]` when you just include `<a` (or the other tag) somewhere or so.
**One important notice:** This was (due to the exceptions before and afterwards) valid before and also now: Translators **could** (and can) if they have malicious intent, inject/do "XSS attacks".
Thus, translations PRs (also from Crowdin) should be reviewed for wild HTML code inside translations. I suppose this is easy to fix, but anyway a valid risk.
But IMHO, we should teat the JSON files being part of our source code as a "trusted source". In the end, such an attak is basicaly just ends up being injecting malicious code. I hope such contributors would be detected.
References I explicitly checked again to not introduce an XSS here: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html and the PHP doc for he HTML encoding.
I feel the safter way obviously would be encoding the _whole_ string _after_ translation (just like you should apply DOMPurify after everything), but as explained it was not done before and would break compatibility. Also, I looked through the sources and I see no risk described by doing it only for the "dangerous" "untrusted" inputs.
Only here is a notice that `%s` shall not be used in some contexts, for example to define a tag: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html#dangerous-contexts (obviously in such a case, attacks may be possible even with encoding; but again; this is nothing new)
The basic "problem" of it all is: We want HTML to be translated/be usable in our translation. If we'd get rid of that, we would get for sure rid of all such XSS attack possibilities. But that woud be a bigger refactoring, so IMHO, this here is fine for a fix for the issue at hand.
Ah another point: I think the `is_int` check is harmless, but it's also kinda useless. Maybe it is some kind of obscure performance optimisation. (Yeah ints have nothing to encode as they have nothing that could be used for XSS, but they could also just be passed through that function.)
function was only used in one place and only indirectly tested, so it could be inlined, which also makes the test for null and the extra variable allocation unnecessary
Instead of automatically adding custom templates, we log an error if
that template is missing in the available templates. Still mitigates
arbitrary file inclusion, as the string is now checked against a fixed
allow list.
