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"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:Fortify}}
 
{{Template:Fortify}}
  
==Abstract==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
 +
 
 +
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
 +
 
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 
 +
[[ASDR Table of Contents]]
 +
__TOC__
  
Socket-based communication in web applications is prone to error.
 
  
 
==Description==
 
==Description==
 +
 +
Socket-based communication in web applications is prone to error.
  
 
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:
 
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:
Line 22: Line 30:
  
  
==Examples ==
+
==Risk Factors==
 +
 
 +
* Talk about the [[OWASP Risk Rating Methodology|factors]] that make this vulnerability likely or unlikely to actually happen
 +
* Discuss the technical impact of a successful exploit of this vulnerability
 +
* Consider the likely [business impacts] of a successful attack
 +
 
 +
 
 +
==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.
 
* 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 [[Attacks]]==
 +
 
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
==Related Vulnerabilities==
 
  
==Related Countermeasures==
+
==Related [[Vulnerabilities]]==
 +
 
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 
 +
 
 +
==Related [[Controls]]==
  
 
URLConnection does not directly supports timeout. There is thread scenario possible which is a bit dirty.  
 
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.
 
Solution: Use client socket and set timeout and linger flags.
  
==Categories==
 
  
 +
==Related [[Technical Impacts]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
 +
TBD
 +
 +
[[Category:FIXME|add links
 +
 +
In addition, one should classify vulnerability based on the following subcategories: Ex:<nowiki>[[Category:Error Handling Vulnerability]]</nowiki>
 +
 +
Availability Vulnerability
 +
 +
Authorization Vulnerability
 +
 +
Authentication Vulnerability
 +
 +
Concurrency Vulnerability
 +
 +
Configuration Vulnerability
 +
 +
Cryptographic Vulnerability
 +
 +
Encoding Vulnerability
 +
 +
Error Handling Vulnerability
 +
 +
Input Validation Vulnerability
 +
 +
Logging and Auditing Vulnerability
 +
 +
Session Management Vulnerability]]
 +
 +
__NOTOC__
 +
 +
 +
[[Category:OWASP ASDR Project]]
 
[[Category:Java]]
 
[[Category:Java]]
 
 
[[Category:Use of Dangerous API]]
 
[[Category:Use of Dangerous API]]
 
 
[[Category:Communication]]
 
[[Category:Communication]]
 
 
[[Category:API Abuse]]
 
[[Category:API Abuse]]

Revision as of 17:16, 26 September 2008

This is a Vulnerability. To view all vulnerabilities, please see the Vulnerability Category page.

This article includes content generously donated to OWASP by MicroFocus Logo.png

Last revision (mm/dd/yy): 09/26/2008

Vulnerabilities Table of Contents

ASDR Table of Contents


Description

Socket-based communication in web applications is prone to error.

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.


Risk Factors

  • Talk about the factors that make this vulnerability likely or unlikely to actually happen
  • Discuss the technical impact of a successful exploit of this vulnerability
  • Consider the likely [business impacts] of a successful attack


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 Attacks


Related Vulnerabilities


Related Controls

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.


Related Technical Impacts


References

TBD