Cleansing, Canonicalization, and Comparison ErrorsID: 171 | Date: (C)2012-05-14 (M)2022-10-10 |
Type: category | Status: DRAFT |
Description
Weaknesses in this category are related to improper handling of
data within protection mechanisms that attempt to perform neutralization for
untrusted data.
Applicable PlatformsLanguage Class: Language-independent
Related Attack Patterns
Common ConsequencesNone
Detection MethodsNone
Potential Mitigations
Phase | Strategy | Description | Effectiveness | Notes |
---|
Architecture and Design | Input Validation | Avoid making decisions based on names of resources (e.g. files) if
those resources can have alternate names. | | |
| | Assume all input is malicious. Use an appropriate combination of black
lists and white lists to ensure only valid, expected and appropriate
input is processed by the system. For example, valid input may be in the
form of an absolute pathname(s). You can also limit pathnames to exist
on selected drives, have the format specified to include only separator
characters (forward or backward slashes) and alphanumeric characters,
and follow a naming convention such as having a maximum of 32 characters
followed by a '.' and ending with specified extensions. | | |
| | Canonicalize the name to match that of the file system's
representation of the name. This can sometimes be achieved with an
available API (e.g. in Win32 the GetFullPathName function). | | |
Relationships
Related CWE | Type | View | Chain |
---|
CWE-171 ChildOf CWE-845 | Category | CWE-844 | |
Demonstrative ExamplesNone
White Box Definitions None
Black Box Definitions None
Taxynomy Mappings
Taxynomy | Id | Name | Fit |
---|
PLOVER | | Cleansing, Canonicalization, and Comparison
Errors | |
CERT Java Secure Coding | IDS02-J | Canonicalize path names before validating
them | |
References:
- M. Howard D. LeBlanc .Writing Secure Code 2nd Edition. Microsoft. Published on 2002.