CWE-246: J2EE Bad Practices: Direct Use of Sockets
J2EE Bad Practices: Direct Use of Sockets
Weakness ID: 246 (Weakness Variant)
Status: Draft
Description
Description Summary
The J2EE application directly uses sockets instead of using
framework method calls.
Time of Introduction
Architecture and Design
Implementation
Applicable Platforms
Languages
Java
Demonstrative Examples
Example 1
In the following example, a Socket object is created directly from
within the body of a doGet() method in a Java servlet.
(Bad Code)
Java
public void doGet(HttpServletRequest request, HttpServletResponse
response) throws ServletException, IOException {
// Perform servlet tasks.
...
// Open a socket to a remote server (bad).
Socket sock = null;
try {
sock = new Socket(remoteHostname, 3000);
// Do something with the socket.
...
} catch (Exception e) {
...
}
}
Potential Mitigations
Phase
Description
Use framework method calls instead of using sockets directly.
Other Notes
The J2EE standard permits the use of sockets only for the purpose of
communication with legacy systems when no higher-level protocol is
available. Authoring your own communication protocol requires wrestling with
difficult security issues, including: - In-band versus out-of-band signaling
- Compatibility between protocol versions - Channel security - Error
handling - Network constraints (firewalls) - Session management Without
significant scrutiny by a security expert, chances are good that a custom
communication protocol will suffer from security problems. Many of the same
issues apply to a custom implementation of a standard protocol. While there
are usually more resources available that address security concerns related
to implementing a standard protocol, these resources are also available to
attackers.
Weakness Ordinalities
Ordinality
Description
Resultant
(where the
weakness is typically related to the presence of some other
weaknesses)
Description
