Thanks for your report.

Regarding expected behavior you've suggested. I'm not sure that you're right here, since your server (vulnerabledoma.in) specifies a charset in Content-Type header:

HTTP/1.1 200 OK
Date: Wed, 04 Jan 2017 11:57:40 GMT
Server: Apache
X-XSS-Protection: 0
X-Other-Header: nothing or invalid
Connection: close
Transfer-Encoding: chunked
Content-Type: text/html; charset=utf-8

<meta http-equiv="refreſh" content="0;url=https://example.com/">


While HTTP standard (https://html.spec.whatwg.org/#character-encoding-declaration) says that ASCII-compatible encoding would be applied:

"If an HTML document does not start with a BOM, and its encoding is not explicitly given by Content-Type metadata, and the document is not an iframe srcdoc document, then the character encoding used must be an ASCII-compatible encoding, and the encoding must be specified using a meta element with a charset attribute or a meta element with an http-equiv attribute in the Encoding declaration state."


To clarify its security implications" what blacklist based sanitizer are you referring to?

For clarity, I added the <meta charset="utf-8"> in the following link:

https://vulnerabledoma.in/char_test?xss=0&charset=utf-8&body=%3Cmeta%20charset=%22utf-8%22%3E%3Cmeta%20http-equiv=%22refre%C5%BFh%22%20content=%220%3Burl=https://example.com/%22%3E

https://vulnerabledoma.in/char_test?xss=0&charset=utf-8&body=%3Cmeta%20charset=%22utf-8%22%3E%3Cmeta%20http-equiv=%22%C5%BFet-Coo%E2%84%AAie%22%20content=%22test=1%22%3E%20%3Cbutton%20onclick=alert%28document.cookie%29%3Ealert%28document.cookie%29%3C/button%3E

>To clarify its security implications" what blacklist based sanitizer are you referring to?
For example, the developers want the users to use many HTML in the their application. But they don't want the attacks such as the XSS. At such time, the blacklist approach is universally used. 

I haven't seen a actual example which is vulnerable by this bug yet. But considering XSS Auditor blocks only meta tags which has the `Set-Cookie` and `Refresh`, basically, if the application blocks only both http-equiv values, we can say almost safe against the attack via meta tags. This bug breaks that premise.

(FYI, Auditor can block both non-ascii variations because it uses the same comparison function named `equalIgnoringCase`.)

Also, the `equalIgnoringCase` function is used many places. I think it has potentially another risks in many places.

Thank you for providing more feedback. Adding requester "mmoroz@google.com" for another review and adding "Needs-Review" label for tracking.

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

I'm not sure what the ideal behavior is here. We don't generally treat these kinds of issues as security vulnerabilities for the reasons mentioned at https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-XSS-filter-bypasses-considered-security-bugs- (this isn't exactly the same case, but the rationale applies here as well).

I'll leave it up to others to decide what we should do here, though.

Had chat offline. Note to self.

- We should fix the issue.
-- Using equalIgnoringCase is too loose.
-- I think its safer to have the meta trigger only for restricted ascii set.
- This isn't a *Chromium/Blink* security bug.
-- Per policy: https://dev.chromium.org/Home/chromium-security/security-faq#TOC-Are-XSS-filter-bypasses-considered-security-bugs-
-- Although XSS filter here is more of third-parties.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb07ed0749ddbb4791c03e9a1b996ec1b0fe191b

commit fb07ed0749ddbb4791c03e9a1b996ec1b0fe191b
Author: lpy <lpy@chromium.org>
Date: Fri Mar 17 19:48:03 2017

Use equalIgnoringASCIICase in HttpEquiv.

Using equalIgnoringCase is too loose, it's safer to have restricted ASCII set
here.

BUG= 678150 

Review-Url: https://codereview.chromium.org/2690703002
Cr-Commit-Position: refs/heads/master@{#457861}

[add] https://crrev.com/fb07ed0749ddbb4791c03e9a1b996ec1b0fe191b/third_party/WebKit/LayoutTests/http/tests/misc/meta-http-equiv-ascii-charset-expected.txt
[add] https://crrev.com/fb07ed0749ddbb4791c03e9a1b996ec1b0fe191b/third_party/WebKit/LayoutTests/http/tests/misc/meta-http-equiv-ascii-charset.html
[modify] https://crrev.com/fb07ed0749ddbb4791c03e9a1b996ec1b0fe191b/third_party/WebKit/Source/core/loader/HttpEquiv.cpp

This was fixed.