24
Effectiveness = High
Manual Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Focused Manual Spotcheck - Focused manual analysis of source Manual Source Code Review
(not inspections)
Effectiveness = High
Automated Static Analysis - Source Code
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer
Effectiveness = High
Architecture or Design Review
According to SOAR, the following detection techniques may be useful: Highly cost effective:
Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.) Formal
Methods / Correct-By-Construction Cost effective for partial coverage: Attack Modeling
Effectiveness = High
Potential Mitigations
Phase: Architecture and Design
Strategy = Attack Surface Reduction
Consider using language-theoretic security (LangSec) techniques that characterize inputs using
a formal language and build "recognizers" for that language. This effectively requires parsing
to be a distinct layer that effectively enforces a boundary between raw input and internal data
representations, instead of allowing parser code to be scattered throughout the program, where
it could be subject to errors or inconsistencies that create weaknesses. [REF-1109] [REF-1110]
[REF-1111]
Phase: Architecture and Design
Strategy = Libraries or Frameworks
Use an input validation framework such as Struts or the OWASP ESAPI Validation API. Note that
using a framework does not automatically address all input validation problems; be mindful of
weaknesses that could arise from misusing the framework itself (CWE-1173).
Phase: Architecture and Design
Phase: Implementation
Strategy = Attack Surface Reduction
Understand all the potential areas where untrusted inputs can enter your software: parameters
or arguments, cookies, anything read from the network, environment variables, reverse DNS
lookups, query results, request headers, URL components, e-mail, files, filenames, databases,
and any external systems that provide data to the application. Remember that such inputs may
be obtained indirectly through API calls.
Phase: Implementation
Strategy = Input Validation
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use
a list of acceptable inputs that strictly conform to specifications. Reject any input that does not
strictly conform to specifications, or transform it into something that does. When performing
input validation, consider all potentially relevant properties, including length, type of input, the
full range of acceptable values, missing or extra inputs, syntax, consistency across related
fields, and conformance to business rules. As an example of business rule logic, "boat" may be
CWE Version 4.14
CWE-20: Improper Input Validation
CWE-20: Improper Input Validation