EC-Council CASE flashcards
EC-Council CASE · Build recall with a focused review session.
34 cards. Read the term and the definition here. The deck at the top of this page is optional.
- STRIDE threat categories
- Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. Each category maps to a violated security property: authentication, integrity, non-repudiation, confidentiality, availability, and authorization respectively.
- Stored versus reflected XSS
- Reflected XSS echoes attacker input in the immediate response and requires a victim to follow a crafted link. Stored XSS persists the payload in a datastore and executes for every viewer, making it generally more severe.
- SSRF metadata endpoint risk
- Server-side request forgery can force an application to reach internal services. Cloud metadata endpoints such as 169.254.169.254 can return temporary credentials, so allowlisting destinations and blocking link-local ranges is essential.
- Abuse case
- An abuse case describes how an attacker would misuse a function to achieve a hostile goal. It is elicited alongside normal use cases so that mitigations become explicit, testable security requirements.
- Testable security requirement
- A requirement stating actor, action, asset, and a measurable threshold, such as locking an account after five failed attempts within fifteen minutes. Without measurable conditions it cannot become an acceptance criterion.
- Requirements traceability matrix
- A mapping linking each security requirement to its design element, test case, and associated risk. It exposes orphan requirements and untested controls, both of which are treated as defects during review.
- Trust boundary
- A point where data crosses between components with different privilege, process, or network domains. Every boundary requires validation, authentication, and logging because data arriving there is untrusted by definition.
- Fail-safe defaults
- A design principle stating access decisions default to denial and error conditions never grant access. It ensures that an exception or misconfiguration results in a closed, not open, security posture.
- Complete mediation principle
- Every access to every object must be checked against policy each time, rather than relying on cached decisions or prior checks. It prevents authorization bypass after permissions or context change.
- Allowlist versus denylist validation
- Allowlisting defines exactly which characters, formats, and lengths are permitted; denylisting blocks known-bad patterns. Denylists are bypassable through encoding and case variation, so allowlisting is preferred.
- Canonicalization before validation
- Decoding URL, HTML, and Unicode encodings and normalizing representations before applying validation rules. Validating raw input allows double-encoding and alternate-representation bypasses of the filter.
- Context-specific output encoding
- Encoding data for the exact sink where it appears: HTML entity encoding in HTML body, attribute encoding in attributes, JavaScript encoding in scripts, and URL encoding in parameters. One encoding does not fit all contexts.
- Parameterized query defense
- Prepared statements bind user input as data rather than concatenating it into SQL text, so input cannot alter query structure. This is the primary defense against SQL injection.
- Password hashing choice
- Use adaptive, salted key-derivation functions such as Argon2id, bcrypt, scrypt, or PBKDF2 with a high iteration count. Fast general-purpose hashes like MD5 and SHA-1 are unsuitable for password storage.
- IDOR vulnerability
- Insecure direct object reference occurs when an application trusts a client-supplied identifier without checking that the requester owns or may access that object. Server-side authorization on every object access prevents it.
- OAuth PKCE flow
- The authorization code flow with Proof Key for Code Exchange binds the token exchange to the client that started it. It is preferred for public clients, replacing the deprecated implicit flow that leaks tokens in URL fragments.
- JWT validation checks
- Before trusting claims, verify the signature, restrict the accepted algorithm to reject 'none' and algorithm confusion, and validate issuer, audience, and expiry. Skipping any check enables token forgery or replay.
- AEAD cipher modes
- Authenticated encryption with associated data, such as AES-GCM or ChaCha20-Poly1305, provides confidentiality and integrity in one operation. It detects tampering, unlike unauthenticated modes such as CBC without a MAC.
- Nonce reuse impact
- Reusing an IV or nonce under the same key in GCM or CTR mode catastrophically breaks confidentiality and integrity, allowing keystream recovery and forgery. Nonces must be unique per encryption operation.
- Cryptographically secure PRNG
- A random number generator suitable for security use, such as SecureRandom, /dev/urandom, or crypto.randomBytes. Time-seeded and language-default generators are predictable and must never produce keys, tokens, or nonces.
- Hard-coded cryptographic key
- A key embedded in source code, configuration, or container images. It is a critical finding because anyone with repository or image access can decrypt data and forge tokens; keys belong in a KMS or vault.
- Session fixation defense
- Issue a new session identifier upon successful authentication and invalidate the previous one server-side. This prevents an attacker who pre-set a known identifier from hijacking the authenticated session.
- Cookie security attributes
- Secure restricts transmission to HTTPS, HttpOnly blocks JavaScript access, and SameSite=Lax or Strict mitigates cross-site request forgery. Path and Domain scope limit where the cookie is sent.
- Idle versus absolute timeout
- Idle timeout ends a session after a period of inactivity, limiting abandoned sessions. Absolute timeout caps total session lifetime regardless of activity, limiting the window for a stolen token.
- Server-side logout
- Logout must destroy the server-side session record in addition to clearing the cookie. Deleting only the client cookie leaves a valid session that an attacker holding the identifier can still use.
- Account enumeration prevention
- Return identical generic messages and comparable response times for failed authentication regardless of whether the username exists. Differing responses let attackers build a list of valid accounts.
- Fail securely on exception
- When an error occurs, deny access and roll back transactions instead of continuing in an undefined state. Error paths that skip authorization checks are a common source of privilege bypass.
- Sensitive data in logs
- Logs must record security events with timestamp, principal, source, and outcome, but must never contain passwords, session tokens, keys, or full card numbers. Log aggregation widens exposure of any leaked secret.
- SAST characteristics
- Static analysis inspects source, bytecode, or binaries without running the application. It gives early feedback and exact file locations via taint analysis, but produces false positives and cannot see runtime configuration.
- DAST characteristics
- Dynamic analysis tests a running application externally, like an attacker. It is technology-agnostic and finds runtime misconfigurations and authentication flaws, but has limited coverage and cannot localize defects in source.
- Taint analysis
- A technique tracking untrusted input from sources such as request parameters to dangerous sinks such as SQL or command execution, noting whether sanitizers intervene. It is central to SAST data-flow findings.
- Software composition analysis
- SCA inventories third-party and open-source dependencies and matches their versions against known vulnerability databases. It complements SAST and DAST by covering code the team did not write.
- SBOM in secure deployment
- A software bill of materials lists every component and version in a build artifact. It enables rapid identification of exposure when a new dependency vulnerability is disclosed and supports patch management.
- CI/CD secret handling
- Build and deployment pipelines must retrieve short-lived credentials from a secrets manager rather than storing them in files or plain environment variables, which frequently leak into build logs and artifacts.