Difference between revisions of "Trust of system event data"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
==Overview==
+
[[Category:FIXME|This is the text from the old template. This needs to be rewritten using the new template.]]
  
Security based on event locations are insecure and can be spoofed.
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
==Consequences ==
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
* Authorization: If one trusts the system-event information and executes commands based on it, one could potentially take actions based on a spoofed identity.
+
[[ASDR Table of Contents]]
 +
__TOC__
  
==Exposure period ==
 
  
* Design through Implementation: Trusting unauthenticated information for authentication is a design flaw.
+
==Description==
  
==Platform ==
+
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.
  
* Languages: Any
+
'''Platform'''
  
* Operating platforms: Any
+
* Languages: 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 61:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:Environmental Vulnerability]]
+
==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]]

Revision as of 13:58, 1 October 2008

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

Last revision (mm/dd/yy): 10/1/2008

Vulnerabilities Table of Contents

ASDR 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