This is an interesting and simultaneously complicated question.

While the names and descriptions for CWE-140 through CWE-146 are not clear 
about the distinction, the mitigations are all about input, and their 
Class-level ancestor CWE-138: Improper Neutralization of Special Elements is 
input-focused: “The software receives input from an upstream component…” So, 
the intention of these CWEs was for input only.

As a side note, the names and descriptions for CWE-140 through CWE-146 should 
be modernized because of the possibility of misinterpretation, and the lack of 
emphasis on the intended behavior (also, was it really necessary to make 
variants for each type of “delimiter”? That PLOVER guy from 2006 has some 
explaining to do (for those who don’t get the joke, it was me)). These are 
early-day CWEs that reflected the focus on skilled vuln researchers, not 

In this case with the extra semicolon for includeSubdomains, deeper analysis is 
required. Kurt says that the semicolon is “not needed.” But is it technically 
allowed according to the spec (… and if so, <which> spec? HSTS? HTTP?) If a 
semicolon is technically allowed, then maybe there’s some kind of parsing error 
on the part of the client because it isn’t following the spec (CWE-684: 
Incorrect Provision of Specified Functionality )? But if both sides of this 
exchange are following some spec (with allowances for “undefined” behavior), 
then this could be regarded as CWE-436: Interpretation Conflict.

Parsing input and translating it to incorrect values is a gap in CWE that we’re 
aware of, but even if the issue is CWE-684 or some descendant of CWE-138, 
hopefully this will show that there are community-wide limitations in our 
language for classifying weaknesses that aren’t the “usual” basic issues like 
overflows and injection.

- Steve

From: Kurt Seifried <>
Sent: Sunday, July 3, 2022 3:47 PM
Cc: CWE Research Discussion <>
Subject: Re: [Non-DoD Source] Is there a CWE for this?

I would prefer to split them because you have two possibilities:

1) fix the output
2) be more tolerant of input and maybe (safely?) try to suss out what happens, 
e.g. is there an attack scenario for an attacker injecting headers with an 
extra ; that are then parses in an HSTS scenario? I can't think of one, so it 
should be safe, but I could be wrong.

On Sun, Jul 3, 2022 at 10:36 AM Hood, Jonathan W CTR USARMY DEVCOM AVMC (USA) 
<<>> wrote:
I see what you’re saying about the CWE-14[0-6] family being pretty limited to 
input processing when the issue could exist because of input or malformed 
output. Perhaps changing these to input/output would be more inclusive of this 
type of issue. Good catch.

From: Kurt Seifried <<>>
Sent: Friday, July 1, 2022 8:37 PM
Subject: [Non-DoD Source] Is there a CWE for this?

I ran across this today while auditing CSA services quarterly:

In URL redirection service, as of 2022-07-01 an improperly formatted 
security header exists in the HSTS support, specifically, the header served is 
\"strict-transport-security: max-age=63072000; includeSubdomains;\" which 
contains an extra semicolon (the final one is not needed), this may result in 
some client ignoring the HSTS header and thus rendering this security 
protection ineffective.

there's some stuff for inbound/input/malformed/configuration/directive/etc, but 
I'm not seeing anything for malformed outbound configuration/output.

Kurt Seifried (He/Him)<>

Kurt Seifried (He/Him)<>

Reply via email to