Content-Type is Case-Sensitive ?

[multipartninja]

Enabled headers in a scan:

It is reported that Content-Type has Incorrect value:

Is it just becaue of "utf" and "UTF" ?

[rfc-st]

Hi, @multipartninja

The check “Content-Type (Incorrect Value - Response body)” concerns the meta http-equiv element in the response body, not the HTTP response headers.

That check only runs if http_equiv has a value:

humble/humble.py

Line 3572 in 31c67df

if http_equiv:

http_equiv is derived from body, which stores the text of the response for the requested URL:

humble/humble.py

Line 2893 in 31c67df

body = r.text

http_equiv stores the result of a regular expression:

humble/humble.py

Lines 3100 to 3101 in 31c67df

	if body:
	http_equiv = re.findall(RE_PATTERN[8], body, re.IGNORECASE)

which searches the response body content for lines such as:

<meta http-equiv='refresh' content='0;url=https://example.com/' />
<meta http-equiv="x-ua-compatible" content="ie=edge">

Finally, the check “Content-Type (Incorrect Value - Response body)” inspects the response body for any line similar to this one, but without the expected value of text/html; charset=utf-8:

<meta http-equiv="content-type content="

humble/humble.py

Lines 3572 to 3575 in 31c67df

	if http_equiv:
	ctype_meta = any('content-type' in item for item in http_equiv)
	if ctype_meta and not any('text/html; charset=utf-8' in item for tuple in
	http_equiv for item in tuple):

humble expects text/html; charset=utf-8 as the value of content-type in accordance with https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv#content-type

[...]

Have I clarified your question about this specific control?.

Regards,

[multipartninja]

So, does that mean that any Roundcube webmail login page has an incorrect value?

Sample:

---

Sample:

[multipartninja]

I think Humble is not reporting anything regarding the presence of CSP in meta tags. Is this normal?

This is in a page but it is not reported:

<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">

[rfc-st]

Hi, @multipartninja

Hello,

According to https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv#content-type, the exact value should be “text/html; charset=utf-8”.

However, https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta#charset states, “If the attribute is present, its value must be an ASCII case-insensitive match for the string "utf-8"” so in fact, I think both forms should be valid in this context. I will review it this weekend.

And regarding ‘Content-Security-Policy’ in meta tags, I'll take a look at that this weekend as well.

Regards,

[rfc-st]

Hi, @multipartninja

Regarding Content-Type (Incorrect Value - Response body) please check a116b85:

• It's now only performed for responses that contain text/html in the HTTP Content-Type response header, according to https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/http-equiv#content-type

• Once that condition is met, it checks for these strings in the body of the response (meta http-equiv="content-type"):
  text/html; charset=utf-8
text/html; charset=UTF-8

• I have tested it against https://webmail.roundcube.101.hostinglogin.net/ (Roundcube webmail login page) and it no longer reports this warning because that page includes this in its body:
  <meta http-equiv=“content-type” content="text/html; charset=UTF-8">

[...]

Take a look and let me know what you think!.

Regards,

[multipartninja]

Hi looks like content-type is fixed now.
But I see another problem. X-Frame-Options is reported to have Insecure Value. What is the problem in X-Frame-Options here?
(I always comment out Set-Cookie in security.txt because I dont report cookie problems in headers section)