Detalle CWE-642

The product stores security-critical state information about its users, or the product itself, in a location that is accessible to unauthorized actors.

Modos de introducción

Architecture and Design : OMISSION: This weakness is caused by missing a security tactic during the architecture and design phase.
Implementation

Plataformas aplicables

Lenguaje

Class: Not Language-Specific (Undetermined)

Tecnologías

Name: Web Server (Often)

Consecuencias comunes

Ejemplos observados

Mitigaciones potenciales

Phases : Architecture and Design
Understand all the potential locations that are accessible to attackers. For example, some programmers assume that cookies and hidden form fields cannot be modified by an attacker, or they may not consider that environment variables can be modified before a privileged program is invoked.
Phases : Architecture and Design
Phases : Architecture and Design
Store state information on the server side only. Ensure that the system definitively and unambiguously keeps track of its own state and user state and has rules defined for legitimate state transitions. Do not allow any application user to affect state directly in any way other than through legitimate actions leading to state transitions.
Phases : Architecture and Design
Phases : Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Phases : Operation // Implementation
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
Phases : Testing
Use tools and techniques that require manual (human) analysis, such as penetration testing, threat modeling, and interactive tools that allow the tester to record and modify an active session. These may be more effective than strictly automated techniques. This is especially the case with weaknesses that are related to design and business rules.

Métodos de detección

Automated Static Analysis

Automated static analysis, commonly referred to as Static Application Security Testing (SAST), can find some instances of this weakness by analyzing source code (or binary/compiled code) without having to execute it. Typically, this is done by building a model of data flow and control flow, then searching for potentially-vulnerable patterns that connect "sources" (origins of input) with "sinks" (destinations where the data interacts with external components, a lower layer such as the OS, etc.)
Efectividad : High

Fuzzing

Use dynamic tools and techniques that interact with the product using large test suites with many diverse inputs, such as fuzz testing (fuzzing), robustness testing, and fault injection. The product's operation may slow down, but it should not become unstable, crash, or generate incorrect results.

Notas de mapeo de vulnerabilidades

Justificación : This CWE entry is a Class and might have Base-level children that would be more appropriate
Comentario : Examine children of this entry to see if there is a better fit

Patrones de ataque relacionados

Referencias

REF-528

Top 10 2007-Insecure Direct Object Reference
OWASP.
https://web.archive.org/web/20160319225940/http://www.owasp.org/index.php/Top_10_2007-A4

REF-529

HMAC
https://en.wikipedia.org/wiki/HMAC

REF-44

24 Deadly Sins of Software Security
Michael Howard, David LeBlanc, John Viega.

REF-1482

D3FEND: D3-TL Trusted Library
D3FEND.
https://d3fend.mitre.org/technique/d3f:TrustedLibrary/

Envío

Modificaciones