On Mon, Jul 4, 2022 at 5:49 PM Steven M Christey <co...@mitre.org> wrote:
> 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 developers. > > > > 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. > > Nope, there's no ambiguity, those extra semicolons are out of spec: https://datatracker.ietf.org/doc/html/rfc6797 6.1. Strict-Transport-Security HTTP Response Header Field The Strict-Transport-Security HTTP response header field (STS header field) indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this header field. The ABNF (Augmented Backus-Naur Form) syntax for the STS header field is given below. It is based on the Generic Grammar defined in Section 2 of [RFC2616] (which includes a notion of "implied linear whitespace", also known as "implied *LWS"). Strict-Transport-Security = "Strict-Transport-Security" ":" [ directive ] *( ";" [ directive ] ) directive = directive-name [ "=" directive-value ] directive-name = token directive-value = token | quoted-string ========== 6.2. Examples The HSTS header field below stipulates that the HSTS Policy is to remain in effect for one year (there are approximately 31536000 seconds in a year), and the policy applies only to the domain of the HSTS Host issuing it: Strict-Transport-Security: max-age=31536000 The HSTS header field below stipulates that the HSTS Policy is to remain in effect for approximately six months and that the policy applies to the domain of the issuing HSTS Host and all of its subdomains: Strict-Transport-Security: max-age=15768000 ; includeSubDomains > 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 <k...@seifried.org> > *Sent:* Sunday, July 3, 2022 3:47 PM > *To:* jonathan.w.hood6....@army.mil > *Cc:* CWE Research Discussion <cwe-research-list@mitre.org> > *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) <jonathan.w.hood6....@army.mil> 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 <k...@seifried.org> > *Sent:* Friday, July 1, 2022 8:37 PM > *To:* CWE-RESEARCH-LIST CWE RESEARCH DISCUSSION < > CWE-RESEARCH-LIST@mitre.org> > *Subject:* [Non-DoD Source] Is there a CWE for this? > > > > I ran across this today while auditing CSA services quarterly: > > > > In bl.ink 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) > k...@seifried.org > > > > > -- > > Kurt Seifried (He/Him) > k...@seifried.org > -- Kurt Seifried (He/Him) k...@seifried.org
