Difference between revisions of "Failure to protect stored data from modification"

From OWASP
Jump to: navigation, search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
 +
{{Template:Vulnerability}}
  
==Overview==
+
Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
  
Data should be protected from direct modification.
+
[[ASDR_TOC_Vulnerabilities|Vulnerabilities Table of Contents]]
  
==Consequences ==
+
==Description==
  
* Integrity: The object could be tampered with.
+
Data should be protected from direct modification.
  
==Exposure period ==
+
'''Consequences'''
  
* Design through Implementation: At design time it is important to reduce the total amount of accessible data.  
+
* Integrity: The object could be tampered with.
  
* Implementation: Most implementation level issues come from a lack of understanding of the language modifiers.
+
'''Exposure period'''
  
==Platform ==
+
* Design through Implementation: At design time it is important to reduce the total amount of accessible data.
 +
* Implementation: Most implementation level issues come from a lack of understanding of the language modifiers.
  
* Languages: Java, C++
+
'''Platform'''
  
* Operating platforms: Any
+
* Languages: Java, C++
 +
* Operating platforms: Any
  
==Required resources ==
+
'''Required resources'''
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
Medium
 
Medium
  
==Likelihood   of exploit ==
+
'''Likelihood of exploit'''
  
 
Medium
 
Medium
  
==Avoidance and mitigation ==
+
One of the main advantages of object-oriented code is the ability to limit access to fields and other resources by way of accessor functions. Utilize accessor functions to make sure your objects are well-formed.
  
* Design through Implementation: Use private members, and class accessor methods to their full benefit. This is the recommended mitigation. Make all public members private, and - if external access is necessary - use accessor functions to do input validation on all values.  
+
Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.
  
* Implementation: Data should be private, static, and final whenever possible This will assure that your code is protected by instantiating early, preventing access and preventing tampering.
 
  
* Implementation: Use sealed classes. Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.
+
==Risk Factors==
  
* Implementation: Use class accessor methods to their full benefit. Use the accessor functions to do input validation on all values intended for private values.
+
TBD
  
==Discussion ==
+
==Examples==
 
+
One of the main advantages of object-oriented code is the ability to limit access to fields and other resources by way of accessor functions. Utilize accessor functions to make sure your objects are well-formed.
+
 
+
Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.
+
 
+
==Examples ==
+
  
 
In C++:
 
In C++:
Line 92: Line 87:
 
</pre>
 
</pre>
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
==Categories ==
+
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:Protocol Errors]]
+
==Related [[Vulnerabilities]]==
  
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 +
==Related [[Controls]]==
 +
 +
* Design through Implementation: Use private members, and class accessor methods to their full benefit. This is the recommended mitigation. Make all public members private, and - if external access is necessary - use accessor functions to do input validation on all values.
 +
* Implementation: Data should be private, static, and final whenever possible This will assure that your code is protected by instantiating early, preventing access and preventing tampering.
 +
* Implementation: Use sealed classes. Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.
 +
* Implementation: Use class accessor methods to their full benefit. Use the accessor functions to do input validation on all values intended for private values.
 +
 +
==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:Protocol Errors]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Latest revision as of 19:46, 20 February 2009

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


Last revision (mm/dd/yy): 02/20/2009

Vulnerabilities Table of Contents

Description

Data should be protected from direct modification.

Consequences

  • Integrity: The object could be tampered with.

Exposure period

  • Design through Implementation: At design time it is important to reduce the total amount of accessible data.
  • Implementation: Most implementation level issues come from a lack of understanding of the language modifiers.

Platform

  • Languages: Java, C++
  • Operating platforms: Any

Required resources

Any

Severity

Medium

Likelihood of exploit

Medium

One of the main advantages of object-oriented code is the ability to limit access to fields and other resources by way of accessor functions. Utilize accessor functions to make sure your objects are well-formed.

Final provides security by only allowing non-mutable objects to be changed after being set. However, only objects which are not extended can be made final.


Risk Factors

TBD

Examples

In C++:

public:
  int someNumberPeopleShouldntMessWith;

In Java:

private class parserProg {
    public stringField;
}

Another set of Examples are:

In C/C++:

private:
  int someNumber;

public:
  void writeNum(int newNum) {
    someNumber = newNum;
  }

In Java:

public class eggCorns {
   private String acorns;
   public void misHear(String name){
      acorns=name;
   }
}


Related Attacks


Related Vulnerabilities

Related Controls

  • Design through Implementation: Use private members, and class accessor methods to their full benefit. This is the recommended mitigation. Make all public members private, and - if external access is necessary - use accessor functions to do input validation on all values.
  • Implementation: Data should be private, static, and final whenever possible This will assure that your code is protected by instantiating early, preventing access and preventing tampering.
  • Implementation: Use sealed classes. Using sealed classes protects object-oriented encapsulation paradigms and therefore protects code from being extended in unforeseen ways.
  • Implementation: Use class accessor methods to their full benefit. Use the accessor functions to do input validation on all values intended for private values.

Related Technical Impacts


References

TBD