Difference between revisions of "Duplicate key in associative list (alist)"

From OWASP
Jump to: navigation, search
Line 2: Line 2:
 
{{Template:SecureSoftware}}
 
{{Template:SecureSoftware}}
  
==Overview==
+
[[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__
 +
 
 +
 
 +
==Description==
  
 
Associative lists should always have unique keys, since having non-unique keys can often be mistaken for an error.
 
Associative lists should always have unique keys, since having non-unique keys can often be mistaken for an error.
  
==Consequences ==
+
'''Consequences'''
  
 
Unspecified.
 
Unspecified.
  
==Exposure period ==
+
'''Exposure period'''
  
* Design: The use of a safe data structure could be used.
+
* Design: The use of a safe data structure could be used.
  
==Platform ==
+
'''Platform'''
  
* Languages: Although alists generally are used only in languages like Common Lisp - due to the functionality overlap with hash tables - an alist could appear in a language like C or C++.
+
* Languages: Although alists generally are used only in languages like Common Lisp - due to the functionality overlap with hash tables - an alist could appear in a language like C or C++.
 +
* Operating platforms: Any
  
* Operating platforms: Any
+
'''Required resources'''
 
+
==Required resources ==
+
  
 
Any
 
Any
  
==Severity ==
+
'''Severity'''
  
 
Medium
 
Medium
  
==Likelihood  of exploit ==
+
'''Likelihood  of exploit'''
  
 
Low
 
Low
  
==Avoidance and mitigation ==
 
  
* Design: Use a hash table instead of an alist.
+
A duplicate key entry - if the ''alist'' is designed properly - could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.
  
* Design: Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.
 
  
==Discussion ==
+
==Risk Factors==
 +
 
 +
TBD
  
A duplicate key entry - if the ''alist'' is designed properly - could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.
 
  
==Examples ==
+
==Examples==
  
 
In Python:
 
In Python:
Line 56: Line 64:
 
Since basename is not necessarily unique, this may not sort how one would like it to be.
 
Since basename is not necessarily unique, this may not sort how one would like it to be.
  
==Related problems ==
 
  
Not available.
+
==Related [[Attacks]]==
  
 +
* [[Attack 1]]
 +
* [[Attack 2]]
  
[[Category:Vulnerability]]
 
  
[[Category:General Logic Error Vulnerability]]
+
==Related [[Vulnerabilities]]==
  
 +
* [[Vulnerability 1]]
 +
* [[Vulnerabiltiy 2]]
 +
 +
Note: the contents of "Related Problems" sections should be placed here
 +
 +
 +
==Related [[Controls]]==
 +
* Design: Use a hash table instead of an alist.
 +
* Design: Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.
 +
 +
==Related [[Technical Impacts]]==
 +
 +
* [[Technical Impact 1]]
 +
* [[Technical Impact 2]]
 +
 +
 +
==References==
 +
Note: A reference to related [http://cwe.mitre.org/ CWE] or [http://capec.mitre.org/ CAPEC] article should be added when exists. Eg:
 +
 +
* [http://cwe.mitre.org/data/definitions/79.html CWE 79].
 +
* http://www.link1.com
 +
* [http://www.link2.com Title for the link2]
 +
 +
[[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:General Logic Error Vulnerability]]
 
[[Category:OWASP_CLASP_Project]]
 
[[Category:OWASP_CLASP_Project]]

Revision as of 18:24, 23 September 2008

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

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

Vulnerabilities Table of Contents

ASDR Table of Contents

Contents


Description

Associative lists should always have unique keys, since having non-unique keys can often be mistaken for an error.

Consequences

Unspecified.

Exposure period

  • Design: The use of a safe data structure could be used.

Platform

  • Languages: Although alists generally are used only in languages like Common Lisp - due to the functionality overlap with hash tables - an alist could appear in a language like C or C++.
  • Operating platforms: Any

Required resources

Any

Severity

Medium

Likelihood of exploit

Low


A duplicate key entry - if the alist is designed properly - could be used as a constant time replace function. However, duplicate key entries could be inserted by mistake. Because of this ambiguity, duplicate key entries in an association list are not recommended and should not be allowed.


Risk Factors

TBD


Examples

In Python:

alist = []
while (foo()):
  #now assume there is a string data with a key basename
  queue.append(basename,data)
queue.sort()

Since basename is not necessarily unique, this may not sort how one would like it to be.


Related Attacks


Related Vulnerabilities

Note: the contents of "Related Problems" sections should be placed here


Related Controls

  • Design: Use a hash table instead of an alist.
  • Design: Use an alist which checks the uniqueness of hash keys with each entry before inserting the entry.

Related Technical Impacts


References

Note: A reference to related CWE or CAPEC article should be added when exists. Eg: