Modes d'introduction
Architecture and Design : COMMISSION: This weakness refers to an incorrect design related to an architectural security tactic.
Plateformes applicables
Langue
Class: Not Language-Specific (Undetermined)
Conséquences courantes
Portée |
Impact |
Probabilité |
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. | |
Exemples observés
Références |
Description |
| product authentication succeeds if user-provided MD5 hash matches the hash in its database; this can be subjected to replay attacks. |
Mesures d’atténuation potentielles
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.
Notes de cartographie des vulnérabilités
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.
Commentaire : 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.
Modèles d'attaque associés
CAPEC-ID |
Nom du modèle d'attaque |
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.
Références
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.
Soumission
Nom |
Organisation |
Date |
Date de publication |
Version |
CLASP |
|
2006-07-19 +00:00 |
2006-07-19 +00:00 |
Draft 3 |
Modifications
Nom |
Organisation |
Date |
Commentaire |
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 |