Modes Of Introduction
Architecture and Design : COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Applicable Platforms
Language
Class: Not Language-Specific (Undetermined)
Common Consequences
Scope |
Impact |
Likelihood |
Access Control | Gain Privileges or Assume Identity
Note: The primary result of reflection attacks is successful authentication with a target machine -- as an impersonated user. | |
Observed Examples
References |
Description |
| product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks. |
Potential Mitigations
Phases : Architecture and Design
Use different keys for the initiator and responder or of a different type of challenge for the initiator and responder.
Phases : Architecture and Design
Let the initiator prove its identity before proceeding.
Vulnerability Mapping Notes
Justification : This CWE entry is at the Base level of abstraction, which is a preferred level of abstraction for mapping to the root causes of vulnerabilities.
Comment : Carefully read both the name and description to ensure that this mapping is an appropriate fit. Do not try to 'force' a mapping to a lower-level Base/Variant simply to comply with this preferred level of abstraction.
Related Attack Patterns
CAPEC-ID |
Attack Pattern Name |
CAPEC-90 |
Reflection Attack in Authentication Protocol An adversary can abuse an authentication protocol susceptible to reflection attack in order to defeat it. Doing so allows the adversary illegitimate access to the target system, without possessing the requisite credentials. Reflection attacks are of great concern to authentication protocols that rely on a challenge-handshake or similar mechanism. An adversary can impersonate a legitimate user and can gain illegitimate access to the system by successfully mounting a reflection attack during authentication. |
NotesNotes
The term "reflection" is used in multiple ways within CWE and the community, so its usage should be reviewed.
References
REF-18
The CLASP Application Security Process
Secure Software, Inc..
https://cwe.mitre.org/documents/sources/TheCLASPApplicationSecurityProcess.pdf REF-62
The Art of Software Security Assessment
Mark Dowd, John McDonald, Justin Schuh.
Submission
Name |
Organization |
Date |
Date release |
Version |
CLASP |
|
2006-07-19 +00:00 |
2006-07-19 +00:00 |
Draft 3 |
Modifications
Name |
Organization |
Date |
Comment |
Eric Dalci |
Cigital |
2008-07-01 +00:00 |
updated Time_of_Introduction |
CWE Content Team |
MITRE |
2008-09-08 +00:00 |
updated Common_Consequences, Description, Maintenance_Notes, Relationships, Other_Notes, Taxonomy_Mappings |
CWE Content Team |
MITRE |
2011-06-01 +00:00 |
updated Common_Consequences |
CWE Content Team |
MITRE |
2012-05-11 +00:00 |
updated Observed_Examples, References, Relationships |
CWE Content Team |
MITRE |
2014-07-30 +00:00 |
updated Relationships |
CWE Content Team |
MITRE |
2017-11-08 +00:00 |
updated Applicable_Platforms, Demonstrative_Examples, Modes_of_Introduction, Relationships |
CWE Content Team |
MITRE |
2020-02-24 +00:00 |
updated References, Relationships |
CWE Content Team |
MITRE |
2021-03-15 +00:00 |
updated Description, Other_Notes |
CWE Content Team |
MITRE |
2022-10-13 +00:00 |
updated Relationships |
CWE Content Team |
MITRE |
2023-01-31 +00:00 |
updated Type |
CWE Content Team |
MITRE |
2023-04-27 +00:00 |
updated Relationships |
CWE Content Team |
MITRE |
2023-06-29 +00:00 |
updated Mapping_Notes |