Tag Archives: XSS

Reflection on CVE 2021–34506

Background

I happened to see an article about this CVE and felt impressed. It is not because how interesting this CVE is, but because I realized how close was I to this CVE, as well to the $20000 reward.

It will be a very short article, but should be inspiring.

CVE 2021-34506

function translateInternal(originalLang, targetLang, shouldTranslateFullPageInOneGo) {
        resetDataBeforeTranslateCall();
        try {
            originalLang = GetEdgeLanguageCode(originalLang);
            targetLang = GetEdgeLanguageCode(targetLang);
            /**
           * This will call the startPageTranslation function of edge script
           */
            Microsoft.JS.startPageTranslation(originalLang, targetLang, shouldTranslateFullPageInOneGo, ""/*domTranslatorSessionId*/
            , ""/*token*/
            , onSuccessCallback, onTranslateApiCalled, onErrorCallback);
            console.error("edge Translation started");
        } catch (err) {
            console.error("Translate: " + err);
            errorCode = ERROR["UNEXPECTED_SCRIPT_ERROR"];
            return false;
        }
        return true;

This is a very streightforward vulnerability that Microsoft Edge’s native translation service did not consider the possibility of XSS at all.

Therefore, any page containing

"><img src=x onerror=alert(1)>
# or other effective XSS payload

will be executed after translation.

An example of facebook

Since it is at a browser level and can be used to attack any website, it was defined as uXSS and rewarded $20000 accordingly.

My Story

Almost around the same time (2021 Summer), I found Microsoft’s Bing Translation online (https://www.bing.com/translator) had a very similar issue that there was no protection against XSS either: when you click the translation button, any XSS payload inside of the original language will be executed.

Though it seems to be a self-XSS and rejected at the first place, I crafted it as a very covert click-hijacking and got the acknowledgement from Microsoft Security Response Center.

Reflections

At that time, I did quickly search for any website/service that may use Bing Translation Engine. (i.e. Azure) because if this issue exists in online tranlsation service, it may also exist elsewhere since it should be produced by one team.

However, I did not check Edge’s translation service at all because I seldomly use Edge. It seemed obvious right now but it was kind of hard to related them.

So I guess the lesson here will be: When a vulnerability is found to exist, search for other businesses or products that may have been developed by the same team if possible. If this business is a website, then applications from the same department also need to be checked, and vice versa

References:

https://www.rapid7.com/db/vulnerabilities/microsoft-edge-cve-2021-34506/

XSS Trick – Priority

I found an interesting example today where the double quote is banned inside of the value parameter.

<input type="text" value="[input]">

Typically there is no solution to this because attackers are not able to escape the double quotes, and therefore everything will be the value including brackets.

I.E. the following form is not working

<input type="text" value="<script>alert</script>">

However, the situation gets dramatically change if there is a tag that has higher priority than input tag.

For example,

<textarea><input type="text" value="[input]">

At this time, though we are still not able to use double quotes to escape, we can use </texarea> to escape

<textarea><input type="text" value="</textarea><script>alert(1)</script>">

The similar “high priority” tags include

<!--,<iframe>,<noframes>,<noscript>,<script>,<style>,<textarea>,<title>,<xmp>

TODO:

Read https://bishopfox.com/blog/lexss-bypassing-lexical-parsing-security-controls, which contains more scientific explanation towarding “priority”