The software provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.
Extended Description
This weakness can lead to a wide variety of resultant weaknesses, depending on the behavior of the exposed method. It can apply to any number of technologies and approaches, such as ActiveX controls, Java functions, IOCTLs, and so on.
The exposure can occur in a few different ways:
1) The function/method was never intended to be exposed to outside actors.
2) The function/method was only intended to be accessible to a limited set of actors, such as Internet-based access from a single web site.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Language-Independent
Common Consequences
Scope
Effect
Integrity
Confidentiality
Availability
Access Control
Other
Technical Impact: Gain privileges / assume
identity; Read application
data; Modify application
data; Execute unauthorized code or
commands; Other
Exposing critical functionality essentially provides an attacker with
the privilege level of the exposed functionality. This could result in
the modification or exposure of sensitive data or possibly even
execution of arbitrary code.
Likelihood of Exploit
Low to Medium
Demonstrative Examples
Example 1
In the following Java example the method removeDatabase will delete
the database with the name specified in the input parameter.
(Bad Code)
Example
Language: Java
public void removeDatabase(String databaseName) {
try {
Statement stmt = conn.createStatement();
stmt.execute("DROP DATABASE " + databaseName);
} catch (SQLException ex) {...}
}
The method in this example is declared public and therefore is exposed
to any class in the application. Deleting a database should be
considered a critical operation within an application and access to this
potentially dangerous method should be restricted. Within Java this can
be accomplished simply by declaring the method private thereby exposing
it only to the enclosing class as in the following example.
security tool ActiveX control allows download or
upload of files
Potential Mitigations
Phase: Architecture and Design
If you must expose a method, make sure to perform input validation on
all arguments, limit access to authorized parties, and protect against
all possible vulnerabilities.
Phases: Architecture and Design; Implementation
Strategy: Identify and Reduce Attack Surface
Identify all exposed functionality. Explicitly list all functionality
that must be exposed to some user or set of users. Identify which
functionality may be:
accessible to all users
restricted to a small set of privileged users
prevented from being directly accessible at all
Ensure that the implemented code follows these expectations. This
includes setting the appropriate access modifiers where applicable
(public, private, protected, etc.) or not marking ActiveX controls
safe-for-scripting.
Weakness Ordinalities
Ordinality
Description
Primary
(where
the weakness exists independent of other weaknesses)
Under-reported and under-studied. This weakness could appear in any
technology, language, or framework that allows the programmer to provide a
functional interface to external parties, but it is not heavily reported. In
2007, CVE began showing a notable increase in reports of exposed method
vulnerabilities in ActiveX applications, as well as IOCTL access to OS-level
resources. These weaknesses have been documented for Java applications in
various secure programming sources, but there are few reports in CVE, which
suggests limited awareness in most parts of the vulnerability research
community.
Description
