XSS vulnerability in the website translation section

[woswos]

The website translator section has a security flaw. It might seem like a small thing, but it actually allows attackers to run malicious scripts on other people's computers. Let's say my website is known as a hacking website and blocked by antivirus software and/or browsers. Now, I can put my website through the Apertium website translator and bypass these antivirus/browser security features because my malicious code is coming from Apertium website but not from my website itself. Apertium is sort of proxying my activity and the source of the scripts. I could also use this vulnerability to steal people's cookies and passwords because Apertium is a trusted website, and people would open links coming from Apertium.

Example case: https://www.apertium.org/index.eng.html?dir=eng-spa&qP=https%3A%2F%2Fbarkin.io%2Ftrick.html#webpageTranslation

I believe all scripts need to be stripped from translated websites before loading them on the client side to prevent this.

I hope to fix this one and link the PR request as well.

[woswos]

I just realized this might be even related to the backend. Should I move this issue to the backend repository?

[unhammer]

Google also loads the script:

Not loading scripts would unfortunately make the url translator pretty useless for most of the web these days :-/

But what Google does, if I interpret their UI correctly, is that you can't just click an url like https://translate.google.com/translate?sl=ru&tl=en&u=barkin.io%2Ftrick.html
and have it run the script – after loading that url, it first looks like

you have to manually click the blue 🔍 button next to the "url bar", then it will run scripts.

That seems like a good solution. The user who clicked an e-mail link or whatever sees the target url and then has to make a decision to load it all the way.

[woswos]

I tested with Google Translate before creating this issue, as well. Yes, Google runs the scripts, but they say that their Google Translate servers are sandboxed and there is no way attackers can pull data from other Google servers/services like gmail, drive, etc (as mentioned here: https://sites.google.com/site/bughunteruniversity/improve/alert-1-considered-harmful). I don't think that this is the case with the official Apertium server or other Apertium installs on other servers.

That being said, I did the like the solution you have pointed out, and I think we should implement a similar behavior. The scripts shouldn't run unless the user voluntarily requested the website translation.

But still, is this is an issue related to the backend or frontend? I am new to Apertium, and I am not sure how the website translation feature works exactly.

[sushain97]

This is considered a self-XSS vulnerability: https://en.wikipedia.org/wiki/Self-XSS. AFAIK, the standard way to combat these issues is via setting up the correct CSP: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP. This is happens at the web server level and is therefore not in the purview of this repository which only builds static assets that can served by any web server.

Google runs the scripts, but they say that their Google Translate servers are sandboxed and there is no way attackers can pull data from other Google servers/services like gmail, drive, etc

These scripts run client side. It looks like Google uses isolated domains as a second security measure (so that cookies are protected -- also not super relevant for Apertium since we aren't doing any sensitive per-user storage -- there's no true "sandbox" for the scripts). This also isn't really something this repo could help with (aside from maybe improving support for such a setup).

But still, is this is an issue related to the backend or frontend? I am new to Apertium, and I am not sure how the website translation feature works exactly.

We can't strip scripts in the backend, that would render a large portion of sites unusable.

That being said, I did the like the solution you have pointed out, and I think we should implement a similar behavior. The scripts shouldn't run unless the user voluntarily requested the website translation.

Sure, I'm fine with this approach. IMO, it doesn't really add that much security since things can be hidden in URLs without that much effort (see all the punycode URL "hacks").

[sushain97]

I could also use this vulnerability to steal people's cookies and passwords because Apertium is a trusted website

Do you have a POC for this? AFAIK, it requires the victim website to also be misconfigured (e.g. not having HTTP-only cookies).

[woswos]

These scripts run client side. It looks like Google uses isolated domains as a second security measure ... This also isn't really something this repo could help with (aside from maybe improving support for such a setup).

I am aware that these scripts run on the client side, and Apertium doesn't store any sensitive information. I just wanted to point out that Apertium could be used to facilitate such an attack.

Do you have a POC for this? AFAIK, it requires the victim website to also be misconfigured (e.g. not having HTTP-only cookies).

I don't have a working POC at the moment. You are right; the victim website needs to be misconfigured.

You can still do a bunch of other stuff like downloading all sorts of files (example: https://apertium.org/index.eng.html?dir=eng-spa&qP=https%3A%2F%2Fbottomless-pit.barkin.io%2Fdownloader.html#webpageTranslation). The limit is the attacker's imagination.

Sure, I'm fine with this approach. IMO, it doesn't really add that much security since things can be hidden in URLs without that much effort (see all the punycode URL "hacks").

This sounds like saying, "We don't need to have locks on the doors because thieves can easily break the glass and open the door anyways."

If you believe that adding such functionality would slow down the translation process, then it is another important point to consider.

[sushain97]

IMO, that's a non sequitur but feel free to send a PR. I can't imagine there's anything sensible to do here that would negatively impact performance.