I would say it's a sliding scale with room for several CWE's: at the "definite": end, someone implements the RFC incorrectly. I mean. Yeah. the output should look like X, it doesn't, therefore it's wrong.
at the maybe middle: there are common behaviors/consensus, like Rob's JSON example, which... well. "it depends". There are definitely more safe behaviors than not (e.g. throw an error, refuse it, etc.), so in my mind, as there is a solution, something actionable, then there is value in having a CWE. at the "we're not sure" end: there are things that are not security/exploitable per se (at least not yet)... but they are concerning. And again being aware of them is a lot safer than not being aware of them at all. But I've seen all too many things go from "that's weird but never a problem" to "that's a CWE top 25 now." So I would say the sooner it gets a CWE, the better. On Tue, Jul 5, 2022 at 10:19 AM Rob Wissmann <rob.wissm...@nteligen.com> wrote: > Steven, > > > > Is there any room to update the description or extended description of > CWE-436: Interpretation Conflict to suggest specs or requirements may be at > fault for leaving certain behaviors up the implementation that should not > be, leaving room for interpretation conflicts to occur and become > vulnerabilities? > > > > For example, the JSON spec is underspecified for certain error conditions, > which leads to interoperability errors. > https://bishopfox.com/blog/json-interoperability-vulnerabilities > > > > Not sure if Kurt’s issue is an RFC issue but if the RFC doesn’t specify > what a client should do when receiving a bad header field, it could be. > > > > -Rob > > > > *From:* Steven M Christey <co...@mitre.org> > *Sent:* Monday, July 4, 2022 7:50 PM > *To:* Seifried, Kurt <k...@seifried.org>; 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? > > > > 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. > > > > 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
