[Something About Self-Only XSS]

CnCxzSec's Blog

Today, I saw an article Exploitation of "Self-Only" XSS in Google Code in exploit-db, which is about the "cross-Self XSS" on Google Code ".

In the past, I found that some mainstream domestic mailboxes "only cross-user XSS" were found. After reporting, the official team thought it was harmless.

I used to think that too. UnlessIn extreme casesFor example, when trade secrets are stolen, social engineering and other means are used to access the recipient's email address, and the "XSS-only cross-user" payload is inserted for Trojans or other malicious purposes, everything serves the purpose. A specific target attack under "very extreme circumstances" is complete.

However, as mentioned above, this situation is too difficult to use, and there are very few opportunities to use, or even 0. You can only cross yourself. It seems that there is no room for use. A foreigner is called unexploitable.

For this Self-Only XSS, foreigners have several ways to use it. The summary is as follows:

1.Use <allow-access-fromDomain="*"/> Cross-origin operations: if a user is in the logout status and uses flash to initiate an http request, the request content carries a valid csrf_token (if any) and A cookie that has logged on to account A, forcing victim to log on to account. The xss playload is successfully loaded in account.I personally think this is still a very extreme situation. There are not many operations that can be performed through xss. And I always think this xss is a bit redundant.

2.Use reflected xss in the same domain to execute stored self-only xss.

3.Use Clickjacking's Drag and Drop Game for xss.I think this method can be regarded as perfect.

4....... You are welcome to add

Although the following two articles are old ones, we recommend that you read them.

Html "target = _ blank>Exploiting CSRF Protected XSS 

Exploiting Unexploitable XSS