|XSS Auditor: unacceptable false positives and gives no details|
|Reported by teo8...@gmail.com, Apr 6 2017||Back to list|
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 Steps to reproduce the problem: 1. I was using the admincp of an vBulletin-base board 2. I edited a template and submitted the form to save it. 3. Since I took too long to do that, my session expired, but that isn't relevant to the issue (it just affects what the content of the response page was, which may be what triggered the issue) 3. I got the bogus error in the screenshot, not allowing me to even know what the fuck was going on, let alone continue with my work What is the expected behavior? chrome should just have shown me the page that was returned by the server. Which in this case, since my session had expired, would have just been the login form asking me to log in again. Whatever "unusual code" it detected that it thought was suspicious, it is a false positive. This kind of protections should not try to be "smart", they should only block content based on very reliable, standardised and, most importantly, PREDICTABLE criteria, or otherwise nothing at all. Blocking code based on some bullshit euristic is not acceptable. MOST IMPORTANTLY: if there really is a valid reason for blocking the content (which definitely was not the case here), then it MUST give extremely detailed information AND also provide a way to ignore (or rather acknowledge) the warning and proceed at your own risk. This should be obvious, for god's sake. What went wrong? 1) I got the bogus error due to a false positive of whatever stupid algorithm tries to detect malicious script 2) I wasn't given the smallest bit of information about the details of what supposedly "unusual" code was blocked. 3) I was given no option to acknowledge the warning and proceed at my own risk 4) as a consequence of all this, I lost my work. Did this work before? Yes Chrome version: 57.0.2987.110 Channel: n/a OS Version: Flash Version: Shockwave Flash 25.0 r0
Apr 6 2017,
Without steps allowing us to reproduce the issue in question, this bug is not actionable.
Apr 6 2017,
You are wrong, points 2 and 3 can be fixed, and they would allow me to figure out how to reproduce the issue in the first place
Apr 7 2017,
Re Comment #2: The XSS Auditor is a feature that websites may opt out of; lack of a user-override is an intentional design feature. The "smallest bit of information about the details" would not be useful to >99% of users; developers may use the Developer Tools to learn more.
Apr 12 2017,
Apr 12 2017,
> developers may use the Developer Tools to learn more. How exactly?? I haven't found any specific information in the devtools either.
|► Sign in to add a comment|