This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org
Difference between revisions of "J2EE Bad Practices: Sockets"
(→Related Countermeasures) |
Weilin Zhong (talk | contribs) (Added contents from Fortify and moved previous description to "Examples" section.) |
||
| Line 1: | Line 1: | ||
| + | {{Template:Fortify}} | ||
| + | |||
{{Template:Vulnerability}} | {{Template:Vulnerability}} | ||
| + | |||
| + | ==Abstract== | ||
| + | |||
| + | Socket-based communication in web applications is prone to error. | ||
==Description== | ==Description== | ||
| − | + | 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. | ||
| + | |||
==Examples == | ==Examples == | ||
| + | |||
| + | * When using URLConnection to one restricted URL resource which is not available (offline) there is posibility that OS will leave those sockets opened (z/OS, Windows). When system starts new URLConnection opened sockets may be reused (including authentication). The URL destination may be reached by the user with lower credentials using previous credentials on that same socket. | ||
==Related Threats== | ==Related Threats== | ||
Revision as of 14:44, 18 July 2006
- This article includes content generously donated to OWASP by
This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.
Abstract
Socket-based communication in web applications is prone to error.
Description
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.
Examples
- When using URLConnection to one restricted URL resource which is not available (offline) there is posibility that OS will leave those sockets opened (z/OS, Windows). When system starts new URLConnection opened sockets may be reused (including authentication). The URL destination may be reached by the user with lower credentials using previous credentials on that same socket.
Related Threats
Related Attacks
Related Vulnerabilities
Related Countermeasures
URLConnection does not directly supports timeout. There is thread scenario possible which is a bit dirty. Solution: Use client socket and set timeout and linger flags.
Categories
This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.
