Sanitization issue with arabic characters

[badr-ghatasheh]

Hi,

There is an issue with applying 'sanitize' strategy while using Arabic characters

for example sanitizing the word 'بدر' will print out the following on the page:

بدر

Can this be fixed?
Thank you

[n00dl3]

same problem with any utf8 character, "éèë..."

[tspaeth]

This is somehow a thing we should discuss. But I'm just myself wondering, why "simple UTF*" conversion fails in the $sanitize-module this way. Needs a bit of investigation I guess as I'm too far away from using that. jqLite - functionality itself is okay.
But as it impacts also the security a bit on sanitizing elements, my first suggestion would be to introduce a "trusthtml" sanitize strategy as an additional option for those really wanting to open that door :-).

Somehow a parallel issue exists also on angular itself to watch: angular/angular.js#4790

@knalli what do you think?

And here is a little playground: http://plnkr.co/edit/w4Erw7yXHQp9d2ndr4HZ?p=preview

[knalli]

I'm a little bit confused.

@badr-ghatasheh: You are writing you are faced with this issue when

applying 'sanitize' strategy

but you are actually not meaning sanitize but escape, do you? Because htmlEscapeValue will not be used when sanitize is activated (it is not required).

Remarking your "fix": That's not a fix, that would make the whole thing ad absurdum: http://plnkr.co/edit/cDCBXlWVgYtny9ciJGV9?p=preview It only works using standard AJS 1.3+ with a $sce running in the background (i.e. ng-bind-html).

@tspaeth I've listed the different kinds of: http://plnkr.co/edit/cDCBXlWVgYtny9ciJGV9?p=preview I'm quite not sure what this does mean for us right now.

[badr-ghatasheh]

Hi @knalli

I Updated the issue, I seem to have mixed the function names.

However, the issue still applies to 'sanitize' strategy and utf8 characters.

[samal-rasmussen]

More people having this issue (including us): http://stackoverflow.com/questions/31002499/angular-translate-sanitisation-fails-with-utf-characters

[knalli]

I've posted an answer: Use sanitizeParameters, escape or escapeParameters.

Sorry for the delay in general, we are short of time. I have no final solution despite the obvious fact that sanitize (not sanitizeParameters) + utf codes breaks. As angular-translate is delegating this to AJS' $sce, I'm quite not sure what the possibilities are.

[bettysteger]

👍

[tspaeth]

Linking in #1131 as a possible duplicate...

[DaAwesomeP]

👍 Happens in for other characters too (such as accents): #1081

[DaAwesomeP]

Would it be possible to make a workaround with a custom filter?

[knalli]

Just to repeat: As this issue is caused by $sanitize internally, the only solution can be so far using not using sanitize or a alternative implemented sanitization. Any suggestions are welcome!

This means: You can still use escape and escapeParameters which aren't unsecure! Both sanitize and sanitizeParameters would be more comfortable in some situations.

[knalli]

I've reworked my previous example and have collected all different kinds of flows. Please notify me if something is still missing!

http://plnkr.co/edit/8BHONOjhsxBxxO9oVYOK?p=preview

So far, I'm seeing that usage of filter is always being somehow affected with issues. As I'm already mentioned, the strategies escape (formely escaped) and the newer ones escapeParameters won't harm the texts, but the sanitize and sanitizeParams will do (when using ng-bind or the filter, AFAIK technically the same).

As we cannot change the result of $sanitize(), I would recommend currently to use escape.

[000panther]

I would recommend posting this issue somewhere in the security manual, where there is currently no strategy recommended - highlighting the current bug and also the solution (using escape for now). It took me three days to notice that this is a known bug! While this time I tried different versions, I thought my sanitation was not gripping correctly.

TL:DR: IMHO this bug + intermediate solution should be in the security docs!
http://angular-translate.github.io/docs/#/guide/19_security

I will make a pull request.

BTW: In my case Ö Ü Ä ü ö ä & are also double escaped.

[knalli]

Just released 2.12.0 containing the new strategies sce and sceParameters.

[knalli]

Current demo running with 2.12.1: http://plnkr.co/edit/rJ0R6GzHGbMVxhSa237C?p=preview

[danielbolivia]

Hi everyone.

Well I have the same problem here, but I think the problem could be when we use $translateProvider.useSanitizeValueStrategy('sanitize');...someone says when we do this its ocurre a double sanitize, could be because we Injected the script for sanitize and we do this $translateProvider.useSanitizeValueStrategy('sanitize'); is a double sanitize?
I think we dont need sanitize becasue We already injected script sanitize..

Maybe that's the problem? or I am wrong?
Please contribute.
Thanks.

[augnustin]

For the records, I got it working thanks to the reference above:

Change .useSanitizeValueStrategy parameter to 'sce'

      $translateProvider.useSanitizeValueStrategy('sce');

[LiamK]

I just tried using the the 'sce' parameter and it works as far as the translations were concerned. However, it also triggers a digest loop error, which is not there with either 'escape' or 'sanitize' params.

Any idea what might be the problem? I removed the watch() statements in the controller but that had no effect.

UPDATE: I tried sceParameters and that worked.

[keybeth]

I tested with all strategies but I cannot translate a placeholder. Also I put HTML entity, hexa code, and the character and nothing doesn't work . The literals are good, but in the input placeholder never put the correct character.

<input type="email" name="email" class="form-control" required autofocus ng-model="ctrl.login.email" translate-attr-placeholder="attribute.email" translate>

locale*es.json

"attribute.email":"Correo electrónico",

[knalli]

fyi: current demo running AJS@1.6.4 & angular-translate@2.15.2

@keybeth I'm applied the character in question here. It's okay?

[keybeth]

@knalli, I don't have problem when translate the character like literal

The next line works, with "attribute.email":"Correo electrónico", in my locale.json
<label for="inputEmail" class="sr-only">attribute.email</label>

but, with the same configuration doesn't work here:

<input type="email" name="email" class="form-control" required autofocus ng-model="ctrl.login.email" translate-attr-placeholder="attribute.email" translate>

Also, I tried

<input type="email" name="email" class="form-control" required autofocus ng-model="ctrl.login.email" placeholder="{{'attribute.email' | translate}}">

With sce, null,escape,sanitize strategy with or without params, but nothing works in the placeholder param.

[knalli]

What is the difference compared with my demo link (the second one, targeting exactly your special character). If the only difference is the character is in the $app.js vs $locale.json, then the issue is a standard encoding one when delivering the files. Otherwise I don't get it.

[keybeth]

@knalli I did the test and when a took the translatiosn form there:

.translations('es', { 'attribute.email': 'Correo electrónico' })
was good, but when I took the translation from the static file:

$translateProvider.useStaticFilesLoader({ prefix : 'i18n/locale-', suffix : '.json' })

no was good. I copied and pasted the same string line like I see in my browser to do the first configuration without any other configuration. It seems a trouble from static files

[knalli]

As I already mentioned: That's a common issue serving (static) files. Get your server output encoding right, that's not an issue for an JS application (in which angular-translate is running).

[knalli]

All strategies are listet at https://angular-translate.github.io/docs/#/guide/19_security

[rmakara]

We had the same problem with our application just before go-live. :) We found that Github issue to look for the solution, but unfortunately changing sanitize strategies didn't work. We use Magento as backend application and Angular for frontend application. In our case, the problem wasn't in ngSanitize, nor Angular translations as we thought at the beginning. The problem was in the process of merging many JavaScript files into one, which is done by Magento to optimize the page.

Files before the merge were UTF-8 but after merge we had the only one file that wasn't properly encoded and we had "rubbish" in sanitized text strings. To solve the problem we turned that Magento's merging process off.

[barbecube]

Hi, I'm facing problem with encoding when using sanitize strategy and translate-attr- directive or translate filter. Directive translate works ok. Using version 2.17.0. Is there fix coming? Thanks

[astronati]

The bug is still reproducible

[fynnfeldpausch]

Is there any progress on this issue?

Edit:
For anyone interested, I am currently using the following workaround. Feedback welcome.

.config(function($provide) {
    $provide.decorator('translateFilter', function($delegate) {
        return function() {
            var result = $delegate.apply(this, arguments);
            return angular.element('<div/>').html(result).text();
        };
    });
});

[knalli]

Is there any progress on this issue?

Short version: no.

Long version: Well, the problem is: I have shown a collection of different situations/strategies and even a maybe-fix, but I'm still unsure about the outcome. While this is an old issue and I'm getting new questions/issues about this topic from time to time, there is actually no really feedback effectively. I'm linking everytime at this issue here.

We are still interested in solving this, and any help is welcome. Maybe a refresh or restart in thinking is fine, I don't know. Because it's not a quick-fix and requires a lot of work in finding and adapting any change, it seems to be not an attractive issue :/

[auchEnia]

We would be hapy to switch to sceParameters strategy, but unfortunatelly it is not as secure as sanitizeParameters. The user can still provide for example <img src="x" onerror="alert('test')"> as an input text value and if that value is then used as a translation parameter, the onerror function is actually executed. The only strategy which prevents this behaviour is the sanitizeParamaters. There is also no way to provide some sort of black/white list in $sce to filter out this kind of stuff.