this issue is similar to  issue 396544 , and shows that xss filter may lead to other vulnerabilities.

in addition,from  https://crbug.com/396544#c2  , i find that this vuln actually do not need the following cases

1. The site must supply an 'x-xss-protection mode=block' header.
2. The site must place sensitive information in an inline <script> block.

for #1 my user page use the default setting
for #2 <input token="123456" /> the token could also be stolean,but it is not in the script block , make this vuln more common

Some of the bug numbers above aren't right, but the general report is correct:

The XSS Auditor, by blocking pages containing reflected script strings and one or more frames, allows confirmation of guesses about the content of cross-origin pages by using the frame count of those pages as an oracle (Issue 752190) to reveal whether the page was loaded or blocked. Framecount is similar to the oracle mentioned in [1] except that it does not require that the attacker inject that additional markup.

The X-XSS-Protection Mode was changed to "Block" by default in Chrome 57+, but the other limits in [2] still apply and limit the scope.

Assuming we cannot break the Issue 752190 oracle entirely (webcompat reasons), I can't think of a quick fix for this except throttling the attack attempts based on the number of failed guesses. (E.g. if an origin spawns >50 pages that trigger cross-origin XSS Auditor blocks, its ability to create cross-origin frames and windows is blocked for some time or indefinitely).

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=396544#c14
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=176137#c17

So, it turns out that that this was already reported in 2015 and 2017, via  Issue 498982  and Issue 767828.

Do you have a POC for this repro?

   "for #2 <input token="123456" /> the token could also be stolen,
    but it is not in the script block , make this vuln more common"

re #7 sorry eric, it's my mistake to say any properties could be stolen.
but there are aslo many other properties for html tag to be stolen

see this online demo

http://www.infelphira.cn/static/property_stolen.html?d=%3Ciframe%20id=%22secretlogfile%22%20src=%22747323.log%22%3E

there is a secret file user in victim's site , and the attacker could guess about its URL.

for example , iframe.src , embed.src , and many other properties which would enable the xss-filter , could be stolen in this issue , not just the variable in script block.

another online demo for link.href

http://www.infelphira.cn/static/p2.html?p=%3Clink%20href=%22747323.log

Yep, and the question is whether we have anything other than a linear-time speedup of the effort required, since one could simply hammer the site with requests iterating over the secret until it hits successfully (modulo DOS defenses) by attaching iframes, etc.

Hence, a secret of "123456" doesn't have enough entropy to really be a secret. If you can find a way to brute-force something with greater than 64 bits we'd be interested.

Ultimately, this is identical to 498982, so I'm duping it to that. 

In practice, I think this is only going to get fixed if we fix Issue 752190, likely by introducing support for DisownOpener in CSP.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot