Difference between revisions of "Trust of system event data"

From OWASP
Jump to: navigation, search
(Reverting to last version not containing links to www.texterletodela.com)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 +
{{Template:Vulnerability}}
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
 +
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
 +
 +
==Description==
 
Security based on event locations are insecure and can be spoofed.
 
Security based on event locations are insecure and can be spoofed.
  
==Consequences ==
+
'''Consequences'''
  
* Authorization: If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.  
+
* Authorization: If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.  
  
==Exposure period ==
+
'''Exposure period'''
  
* Design through Implementation: Trusting unauthenticated information for authentication is a design flaw.
+
* Design through Implementation: Trusting unauthenticated information for authentication is a design flaw.
  
==Platform ==
+
'''Platform'''
  
* Languages: Any
+
* Languages: Any
 +
* Operating platforms: Any
  
* Operating platforms: Any
+
'''Required resources'''
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
High
 
High
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
High
 
High
  
==Avoidance and mitigation ==
+
Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source.
  
* Design through Implementation: Never trust or rely any of the information in an Event for security.  
+
Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages.
  
==Discussion ==
+
==Risk Factors==
  
Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source.
+
TBD
  
Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages.
+
==Examples==
  
==Examples ==
 
  
 
In Java:
 
In Java:
Line 52: Line 54:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:Environmental Problem]]
+
==Related [[Vulnerabilities]]==
  
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 +
 +
 +
==Related [[Controls]]==
 +
 +
* [[Control 1]]
 +
* [[Control 2]]
 +
* Design through Implementation: Never trust or rely any of the information in an Event for security.
 +
 +
 +
 +
==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:Vulnerability]]
 +
[[Category:Environmental Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Latest revision as of 13:30, 27 May 2009

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



Last revision (mm/dd/yy): 05/27/2009

Vulnerabilities Table of Contents

Description

Security based on event locations are insecure and can be spoofed.

Consequences

  • Authorization: If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.

Exposure period

  • Design through Implementation: Trusting unauthenticated information for authentication is a design flaw.

Platform

  • Languages: Any
  • Operating platforms: Any

Required resources

Any

Severity

High

Likelihood of exploit

High

Events are a messaging system which may provide control data to programs listening for events. Events often do not have any type of authentication framework to allow them to be verified from a trusted source.

Any application, in Windows, on a given desktop can send a message to any window on the same desktop. There is no authentication framework for these messages. Therefore, any message can be used to manipulate any process on the desktop if the process does not check the validity and safeness of those messages.

Risk Factors

TBD

Examples

In Java:

public void actionPerformed(ActionEvent e) {
  if (e.getSource()==button) 
    System.out.println("print out secret information");
}


Related Attacks


Related Vulnerabilities


Related Controls

  • Control 1
  • Control 2
  • Design through Implementation: Never trust or rely any of the information in an Event for security.


Related Technical Impacts


References

TBD