[EXT] Suggestion for category 1215: Input Validation Issues

[Amy Gale]

At the moment  category CWE-1215: Input Validation Issues is incomparable with  weakness CWE-20: Improper Input Validation : the members of CWE-1215 include a strict subset of the children of CWE-20.

I suggest making CWE-20 (rather than these children) a first-class member of CWE-1215.

 

(Sorry, this seems very terse but there really wasn’t a lot to say.)

 

Amy Gale

GrammaTech, Inc.

 

---

The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

[Kurt Seifried]

CWE-20 is kind of useless, it's overly broad and not well defined, I get that it's handy to have a term that covers a multitude of sins but I would suggest instead maybe we look at making more constrained sub-instances of CWE-20 if you want to include them as a first class citizen in another CWE. 

On Thu, Apr 16, 2020 at 11:04 AM Amy Gale <[hidden email]> wrote:

At the moment  category CWE-1215: Input Validation Issues is incomparable with  weakness CWE-20: Improper Input Validation : the members of CWE-1215 include a strict subset of the children of CWE-20.

I suggest making CWE-20 (rather than these children) a first-class member of CWE-1215.

 

(Sorry, this seems very terse but there really wasn’t a lot to say.)

 

Amy Gale

GrammaTech, Inc.

 

---

The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

--

[Andrew Buttner]

Thank you for bring up this question. Hopefully the following helps explain what is going on.

 

CWE-1215 is a category (and hence not a weakness) under the Software Development view.  This view attempts to present weaknesses in a simple and intuitive way. As such it targets a single level of abstraction. The view has a number of categories centered around concepts that are frequently used or encountered in software development. Within each category is a collection of related weaknesses all at the same level of abstraction.  It is important to realize that in order to achieve the desired simplicity, not every CWE will be represented in this view. High-level class weaknesses and low-level variant weaknesses are mostly not included. So in the example brought up, CWE-1215 is the category related to input validation issues, and there are 10 base-level weaknesses listed under it.

 

CWE-20 is a class-level weakness and is presented at a high-level by design.  It is an important concept and an important weakness to capture. Unfortunately it is often misused as a catch all for a variety of issues that really should be described using lower-level CWEs. One of our focuses this year is to provide better guidance surrounding the use of class-level weaknesses like CWE-20.

 

The Research Concepts view uses a deep hierarchical organization, with many levels of abstraction. CWE-20, and all other weaknesses at any level of abstraction, can be found using this view. This view is intended to facilitate research into weaknesses, including their inter-dependencies, and offers a more complex yet complete way of exploring CWE.

 

I hope this helps answer your question.

 

Thanks

Drew

 

 

 

From: Amy Gale <[hidden email]>
Sent: Thursday, April 16, 2020 12:20 PM
To: CWE Research Discussion <[hidden email]>
Subject: [EXT] Suggestion for category 1215: Input Validation Issues

 

At the moment  category CWE-1215: Input Validation Issues is incomparable with  weakness CWE-20: Improper Input Validation : the members of CWE-1215 include a strict subset of the children of CWE-20.

I suggest making CWE-20 (rather than these children) a first-class member of CWE-1215.

 

(Sorry, this seems very terse but there really wasn’t a lot to say.)

 

Amy Gale

GrammaTech, Inc.

 

---

The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

[Amy Gale]

Perhaps it will be useful one way or another to describe my specific use case.

 

I have a static code checker that detects “tainted buffer access”. Its categorization mappings include a number of CWE IDs, including CWE-20 as a ‘superset’ – all tainted buffer accesses are due to improper input validation, but not vice versa.

 

It seems fairly clear to me that that the inclusion closure of the mappings for this checker should include CWE-1215, but the only way I can currently achieve this is by mapping it directly, which is fine in a practical sense but seems conceptually less than ideal.

CWE-20 has one child that is both applicable to the checker (specifically CWE-129, “Improper Validation of Array Index”) and also a current member of CWE-1215, but that would be a ‘subset’ mapping and leave me with two issues:

• If I exchange CWE-129 for CWE-20, I’m no longer characterizing all instances detected by the checker. If I map both, it seems a slightly weird use of an inheritance hierarchy.
• Either way, a subset mapping isn’t going to have any effect on the inclusion closure. (I do have the option here of redefining the inclusion closure to incorporate category membership more broadly, but this would have its own issues.)

 

So I have multiple options for getting a sensible outcome under the current structure, I just also have something of a sense that CWE-1215 should have come ‘for free’ with CWE-20.

 

Amy

 

From: Kurt Seifried <[hidden email]>
Sent: Thursday, April 16, 2020 9:09 PM
To: Amy Gale <[hidden email]>
Cc: CWE Research Discussion <[hidden email]>
Subject: [External] - Re: [EXT] Suggestion for category 1215: Input Validation Issues

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

 

CWE-20 is kind of useless, it's overly broad and not well defined, I get that it's handy to have a term that covers a multitude of sins but I would suggest instead maybe we look at making more constrained sub-instances of CWE-20 if you want to include them as a first class citizen in another CWE. 

 

On Thu, Apr 16, 2020 at 11:04 AM Amy Gale <[hidden email]> wrote:

At the moment  category CWE-1215: Input Validation Issues is incomparable with  weakness CWE-20: Improper Input Validation : the members of CWE-1215 include a strict subset of the children of CWE-20.

I suggest making CWE-20 (rather than these children) a first-class member of CWE-1215.

 

(Sorry, this seems very terse but there really wasn’t a lot to say.)

 

Amy Gale

GrammaTech, Inc.

 

---

The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.

 

--

Kurt Seifried
[hidden email]

---

The information contained in this e-mail and any attachments from GrammaTech, Inc may contain confidential and/or proprietary information, and is intended only for the named recipient to whom it was originally addressed. If you are not the intended recipient, any disclosure, distribution, or copying of this e-mail or its attachments is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately by return e-mail and permanently delete the e-mail and any attachments.