EC-Council CASE cheat sheet

Threat modeling classification: STRIDE maps spoofing to authentication, tampering to integrity, repudiation to non-repudiation, information disclosure to confidentiality, denial of service to availability, and elevation of privilege to authorization.

OWASP Top 10 categories are risk rankings derived from exploitability, prevalence, detectability, and impact - not a checklist of coding rules; injection, broken access control, and cryptographic failures recur across releases.

Injection succeeds when data crosses a trust boundary and is interpreted as code; SQLi, command injection, LDAP injection, and XPath injection share this root cause, so parameterization fixes all four.

XSS types differ by persistence: reflected XSS echoes input in the immediate response, stored XSS persists in a datastore, and DOM-based XSS executes in client-side JavaScript without server reflection.

CSRF exploits ambient credentials (cookies) attached automatically by the browser; a successful defense requires an unguessable token or SameSite cookie attribute, not merely a POST method.

SSRF causes the server to fetch attacker-chosen URLs; defenses include allowlisting destination hosts and blocking link-local metadata endpoints such as 169.254.169.254.

Insecure deserialization allows object graph manipulation leading to remote code execution; mitigations include integrity checks (HMAC) on serialized data and avoiding native serialization of untrusted input.

Defense in depth layers controls so a single bypass does not yield full compromise; least privilege and fail-safe defaults limit blast radius when an outer layer fails.

Attack surface equals the sum of entry points, trust boundaries, and privileged interfaces; reducing unused endpoints and services shrinks it measurably.

Security requirements must be testable: state actor, action, asset, and measurable condition (e.g., lockout after 5 failed attempts within 15 minutes), otherwise they cannot become acceptance criteria.

Abuse cases invert a use case to describe attacker goals and are derived alongside functional requirements during elicitation, not after design.

Compliance drivers map to requirement sources: PCI DSS for cardholder data, HIPAA for PHI, GDPR for EU personal data, and SOX for financial reporting integrity.

Data classification (public, internal, confidential, restricted) determines required controls such as encryption at rest, retention period, and access review cadence.

Threat modeling at requirements time (e.g., STRIDE per data-flow diagram) surfaces missing requirements earlier and cheaper than discovering them in testing.

Non-functional security requirements cover availability targets, logging retention, cryptographic algorithm strength, and maximum acceptable session idle timeout.

Traceability matrix links each security requirement to a design element, test case, and risk; orphan requirements and untested controls are both defects.

Assumptions and dependencies (third-party identity provider, TLS termination point) must be recorded explicitly because unstated assumptions become unmanaged risk.

Trust boundaries are drawn wherever data crosses privilege, process, or network domains; every boundary needs validation, authentication, and logging.

Least privilege applies to service accounts, database users, containers, and API scopes; a component should hold only permissions required for its current task.

Fail-safe defaults (deny by default) mean access decisions default to denial and error paths do not grant access.

Separation of duties prevents one principal from both authoring and approving a change; complete mediation requires every access to be checked, not cached indefinitely.

Defense in depth pairs preventive controls (WAF, input validation) with detective controls (logging, IDS) and corrective controls (backup, incident response).

Microservice designs must enforce authentication at the edge and authorization per service; perimeter-only trust fails once internal traffic is assumed safe.

Secrets must be externalized to a vault or KMS, never baked into images or source; rotation and short-lived credentials reduce exposure window.

Secure design patterns include secure factory, policy-based authorization, secure session, and input validation at the boundary; anti-patterns include client-side-only checks and security by obscurity.

Architecture risk analysis (e.g., attack tree or DFD-based threat model) is repeated when the data flow, trust boundary, or technology stack changes.

Prefer allowlisting (define permitted characters, length, format) over denylisting, which is bypassable via encoding, case variation, and alternate representations.

Validate on the server; client-side validation is a usability feature only and is trivially bypassed.

Canonicalize before validating: decode URL/HTML/Unicode encodings, normalize Unicode, then apply the allowlist to avoid double-encoding bypass.

Parameterized queries or prepared statements separate code from data and are the primary defense against SQL injection; stored procedures are safe only if they do not concatenate input.

Output encoding is context-specific: HTML entity encoding for HTML body, attribute encoding for attributes, JavaScript encoding for script context, URL encoding for URL parameters.

File upload validation must check extension, MIME type, magic bytes, size, and store files outside the webroot with randomized names and no execute permission.

Reject or normalize path traversal sequences (../, .., encoded variants) and resolve the canonical path before comparing against an allowed base directory.

Bound integer and buffer inputs to prevent overflow; in memory-unsafe languages use bounds-checked APIs and compiler hardening (stack canaries, ASLR).

Password storage must use adaptive salted hashes (Argon2id, bcrypt, scrypt, or PBKDF2 with high iteration count); fast hashes such as MD5 or SHA-1 are unsuitable.

NIST SP 800-63B guidance: minimum 8 characters, check against breached-password lists, no forced composition rules or periodic rotation without evidence of compromise.

Multi-factor authentication combines knowledge, possession, and inherence factors; two instances of the same factor (password plus security question) is not MFA.

Authentication verifies identity; authorization decides permitted actions. Broken access control (IDOR) occurs when object references are trusted without an ownership check.

Enforce authorization server-side on every request using a central policy; hiding UI elements is not access control.

RBAC assigns permissions to roles, ABAC evaluates attributes and context; both must deny by default and be validated for privilege escalation paths.

Session fixation is prevented by issuing a new session identifier at authentication success; credential stuffing is mitigated with rate limiting and breached-credential checks.

OAuth 2.0 authorization code flow with PKCE is preferred for public clients; implicit flow is deprecated because tokens leak via URL fragments.

JWT validation must verify signature, algorithm (reject 'none' and algorithm confusion), issuer, audience, and expiry before trusting claims.

Use vetted libraries (libsodium, Bouncy Castle, JCA, OpenSSL) rather than implementing primitives; custom crypto is a defect class, not a feature.

Symmetric encryption should use AES-GCM or ChaCha20-Poly1305 (AEAD) to provide confidentiality and integrity together; ECB mode leaks patterns and must not be used.

IVs and nonces must be unique per encryption under a given key; reuse with GCM or CTR catastrophically breaks confidentiality and integrity.

Asymmetric choices: RSA with at least 2048-bit keys (3072 recommended) or ECC with P-256/P-384; RSA must use OAEP padding, never PKCS#1 v1.5 for new designs.

Hashing for integrity uses SHA-256 or SHA-3; MD5 and SHA-1 are broken for collision resistance and must not be used for signatures or certificates.

Passwords use salted, slow KDFs; key derivation from passphrases uses PBKDF2, scrypt, or Argon2id with tuned memory and iteration parameters.

Key management covers generation (CSPRNG), storage (HSM/KMS), rotation, separation by purpose, and destruction; hard-coded keys in source are a critical finding.

Randomness for security must come from a cryptographically secure PRNG (SecureRandom, /dev/urandom, crypto.randomBytes), never from time-seeded or language default RNGs.

Encrypt data in transit with TLS 1.2+ (prefer 1.3), disable weak ciphers and protocols (SSLv3, TLS 1.0/1.1), and enforce HSTS.

Session identifiers must be generated with a CSPRNG and be long enough (at least 128 bits of entropy) to resist guessing and brute force.

Regenerate the session ID on login and on privilege change to prevent session fixation; invalidate the old identifier server-side.

Cookie attributes: Secure (HTTPS only), HttpOnly (blocks JavaScript access), SameSite=Lax or Strict (CSRF mitigation), and a scoped Path and Domain.

Idle timeout and absolute timeout both apply; idle timeout limits abandoned sessions, absolute timeout caps total session lifetime regardless of activity.

Logout must destroy the server-side session record and clear the cookie; client-side cookie deletion alone leaves a valid server session.

Store session state server-side or in signed, encrypted tokens; never place sensitive data in client-readable cookies or URL query strings.

Concurrent session limits and re-authentication for sensitive operations (password change, payment) reduce the impact of stolen session tokens.

Session tokens must not appear in logs, referrer headers, or URLs; use POST bodies or headers and set Referrer-Policy to limit leakage.

Error messages to users should be generic (e.g., 'invalid credentials') while detailed diagnostics go to server-side logs with a correlation ID.

Stack traces, SQL errors, and framework versions disclosed to clients aid attackers and constitute information leakage.

Authentication failures must not reveal whether the username or the password was wrong, preventing account enumeration.

Fail securely: on exception, deny access and roll back transactions rather than continuing in an undefined state.

Catch specific exceptions; broad catch blocks that swallow errors hide security-relevant failures and can bypass authorization checks.

Log security events (authentication success/failure, authorization denial, input validation failure) with timestamp, principal, source, and outcome, but never log secrets or full card numbers.

Suppress or mask sensitive data in logs and error pages; use centralized exception handling so no code path returns raw exception detail.

Configure production error pages and disable debug/verbose modes before deployment; debug endpoints are a common finding in DAST scans.

SAST analyzes source, bytecode, or binaries without executing the application; it finds issues early and can pinpoint the exact file and line.

DAST tests a running application from the outside, exercising it like an attacker; it finds runtime and configuration issues but cannot see source.

SAST strengths: early feedback, full code coverage, data-flow and taint analysis. Weaknesses: false positives, inability to see runtime configuration or third-party binaries.

DAST strengths: technology-agnostic, detects runtime misconfigurations and auth flaws. Weaknesses: limited code coverage, requires a deployed environment, cannot localize the defect.

Taint analysis tracks untrusted sources (request parameters) to dangerous sinks (SQL execution, command execution, response output) through sanitizers.

Interactive (IAST) and software composition analysis (SCA) complement SAST/DAST: IAST instruments runtime agents, SCA inventories third-party dependencies against known CVEs.

False positive triage requires a reproducible proof; false negatives are addressed by expanding rule sets, authentication coverage, and crawl depth.

Integrate SAST in the CI pipeline on pull requests and DAST against a staging environment; gate builds on severity thresholds rather than raw counts.

Harden build artifacts: pin dependency versions, verify checksums and signatures, and generate an SBOM to track components and their CVEs.

Secrets in CI/CD must come from a secrets manager with short-lived credentials; environment variables in build logs leak frequently.

Deployment environments must separate dev, test, and production with distinct credentials and data; production data should not be copied to test systems unmasked.

Infrastructure as code must be scanned for misconfiguration (open storage buckets, permissive security groups, unencrypted volumes) before apply.

Patch management uses risk-based SLAs (e.g., critical CVEs within 7-14 days) and tracks dependency versions continuously.

Runtime protections include WAF rules, RASP agents, least-privilege container users, read-only filesystems, and network segmentation.

Monitoring and alerting on security events (repeated auth failures, privilege changes, anomalous egress) provide detection after preventive controls fail.

Backup, restore testing, and documented incident response procedures are maintenance controls that limit impact of compromise or ransomware.

Threat modeling classification: STRIDE maps spoofing to authentication, tampering to integrity, repudiation to non-repudiation, information disclosure to confidentiality, denial of service to availability, and elevation of privilege to authorization.

OWASP Top 10 categories are risk rankings derived from exploitability, prevalence, detectability, and impact - not a checklist of coding rules; injection, broken access control, and cryptographic failures recur across releases.

Injection succeeds when data crosses a trust boundary and is interpreted as code; SQLi, command injection, LDAP injection, and XPath injection share this root cause, so parameterization fixes all four.

XSS types differ by persistence: reflected XSS echoes input in the immediate response, stored XSS persists in a datastore, and DOM-based XSS executes in client-side JavaScript without server reflection.

CSRF exploits ambient credentials (cookies) attached automatically by the browser; a successful defense requires an unguessable token or SameSite cookie attribute, not merely a POST method.

SSRF causes the server to fetch attacker-chosen URLs; defenses include allowlisting destination hosts and blocking link-local metadata endpoints such as 169.254.169.254.

Insecure deserialization allows object graph manipulation leading to remote code execution; mitigations include integrity checks (HMAC) on serialized data and avoiding native serialization of untrusted input.

Defense in depth layers controls so a single bypass does not yield full compromise; least privilege and fail-safe defaults limit blast radius when an outer layer fails.

Attack surface equals the sum of entry points, trust boundaries, and privileged interfaces; reducing unused endpoints and services shrinks it measurably.

Security requirements must be testable: state actor, action, asset, and measurable condition (e.g., lockout after 5 failed attempts within 15 minutes), otherwise they cannot become acceptance criteria.

Abuse cases invert a use case to describe attacker goals and are derived alongside functional requirements during elicitation, not after design.

Compliance drivers map to requirement sources: PCI DSS for cardholder data, HIPAA for PHI, GDPR for EU personal data, and SOX for financial reporting integrity.

Data classification (public, internal, confidential, restricted) determines required controls such as encryption at rest, retention period, and access review cadence.

Threat modeling at requirements time (e.g., STRIDE per data-flow diagram) surfaces missing requirements earlier and cheaper than discovering them in testing.

Non-functional security requirements cover availability targets, logging retention, cryptographic algorithm strength, and maximum acceptable session idle timeout.

Traceability matrix links each security requirement to a design element, test case, and risk; orphan requirements and untested controls are both defects.

Assumptions and dependencies (third-party identity provider, TLS termination point) must be recorded explicitly because unstated assumptions become unmanaged risk.

Trust boundaries are drawn wherever data crosses privilege, process, or network domains; every boundary needs validation, authentication, and logging.

Least privilege applies to service accounts, database users, containers, and API scopes; a component should hold only permissions required for its current task.

Fail-safe defaults (deny by default) mean access decisions default to denial and error paths do not grant access.

Separation of duties prevents one principal from both authoring and approving a change; complete mediation requires every access to be checked, not cached indefinitely.

Defense in depth pairs preventive controls (WAF, input validation) with detective controls (logging, IDS) and corrective controls (backup, incident response).

Microservice designs must enforce authentication at the edge and authorization per service; perimeter-only trust fails once internal traffic is assumed safe.

Secrets must be externalized to a vault or KMS, never baked into images or source; rotation and short-lived credentials reduce exposure window.

Secure design patterns include secure factory, policy-based authorization, secure session, and input validation at the boundary; anti-patterns include client-side-only checks and security by obscurity.

Architecture risk analysis (e.g., attack tree or DFD-based threat model) is repeated when the data flow, trust boundary, or technology stack changes.

Prefer allowlisting (define permitted characters, length, format) over denylisting, which is bypassable via encoding, case variation, and alternate representations.

Validate on the server; client-side validation is a usability feature only and is trivially bypassed.

Canonicalize before validating: decode URL/HTML/Unicode encodings, normalize Unicode, then apply the allowlist to avoid double-encoding bypass.

Parameterized queries or prepared statements separate code from data and are the primary defense against SQL injection; stored procedures are safe only if they do not concatenate input.

Output encoding is context-specific: HTML entity encoding for HTML body, attribute encoding for attributes, JavaScript encoding for script context, URL encoding for URL parameters.

File upload validation must check extension, MIME type, magic bytes, size, and store files outside the webroot with randomized names and no execute permission.

Reject or normalize path traversal sequences (../, .., encoded variants) and resolve the canonical path before comparing against an allowed base directory.

Bound integer and buffer inputs to prevent overflow; in memory-unsafe languages use bounds-checked APIs and compiler hardening (stack canaries, ASLR).

Password storage must use adaptive salted hashes (Argon2id, bcrypt, scrypt, or PBKDF2 with high iteration count); fast hashes such as MD5 or SHA-1 are unsuitable.

NIST SP 800-63B guidance: minimum 8 characters, check against breached-password lists, no forced composition rules or periodic rotation without evidence of compromise.

Multi-factor authentication combines knowledge, possession, and inherence factors; two instances of the same factor (password plus security question) is not MFA.

Authentication verifies identity; authorization decides permitted actions. Broken access control (IDOR) occurs when object references are trusted without an ownership check.

Enforce authorization server-side on every request using a central policy; hiding UI elements is not access control.

RBAC assigns permissions to roles, ABAC evaluates attributes and context; both must deny by default and be validated for privilege escalation paths.

Session fixation is prevented by issuing a new session identifier at authentication success; credential stuffing is mitigated with rate limiting and breached-credential checks.

OAuth 2.0 authorization code flow with PKCE is preferred for public clients; implicit flow is deprecated because tokens leak via URL fragments.

JWT validation must verify signature, algorithm (reject 'none' and algorithm confusion), issuer, audience, and expiry before trusting claims.

Use vetted libraries (libsodium, Bouncy Castle, JCA, OpenSSL) rather than implementing primitives; custom crypto is a defect class, not a feature.

Symmetric encryption should use AES-GCM or ChaCha20-Poly1305 (AEAD) to provide confidentiality and integrity together; ECB mode leaks patterns and must not be used.

IVs and nonces must be unique per encryption under a given key; reuse with GCM or CTR catastrophically breaks confidentiality and integrity.

Asymmetric choices: RSA with at least 2048-bit keys (3072 recommended) or ECC with P-256/P-384; RSA must use OAEP padding, never PKCS#1 v1.5 for new designs.

Hashing for integrity uses SHA-256 or SHA-3; MD5 and SHA-1 are broken for collision resistance and must not be used for signatures or certificates.

Passwords use salted, slow KDFs; key derivation from passphrases uses PBKDF2, scrypt, or Argon2id with tuned memory and iteration parameters.

Key management covers generation (CSPRNG), storage (HSM/KMS), rotation, separation by purpose, and destruction; hard-coded keys in source are a critical finding.

Randomness for security must come from a cryptographically secure PRNG (SecureRandom, /dev/urandom, crypto.randomBytes), never from time-seeded or language default RNGs.

Encrypt data in transit with TLS 1.2+ (prefer 1.3), disable weak ciphers and protocols (SSLv3, TLS 1.0/1.1), and enforce HSTS.

Session identifiers must be generated with a CSPRNG and be long enough (at least 128 bits of entropy) to resist guessing and brute force.

Regenerate the session ID on login and on privilege change to prevent session fixation; invalidate the old identifier server-side.

Cookie attributes: Secure (HTTPS only), HttpOnly (blocks JavaScript access), SameSite=Lax or Strict (CSRF mitigation), and a scoped Path and Domain.

Idle timeout and absolute timeout both apply; idle timeout limits abandoned sessions, absolute timeout caps total session lifetime regardless of activity.

Logout must destroy the server-side session record and clear the cookie; client-side cookie deletion alone leaves a valid server session.

Store session state server-side or in signed, encrypted tokens; never place sensitive data in client-readable cookies or URL query strings.

Concurrent session limits and re-authentication for sensitive operations (password change, payment) reduce the impact of stolen session tokens.

Session tokens must not appear in logs, referrer headers, or URLs; use POST bodies or headers and set Referrer-Policy to limit leakage.

Error messages to users should be generic (e.g., 'invalid credentials') while detailed diagnostics go to server-side logs with a correlation ID.

Stack traces, SQL errors, and framework versions disclosed to clients aid attackers and constitute information leakage.

Authentication failures must not reveal whether the username or the password was wrong, preventing account enumeration.

Fail securely: on exception, deny access and roll back transactions rather than continuing in an undefined state.

Catch specific exceptions; broad catch blocks that swallow errors hide security-relevant failures and can bypass authorization checks.

Log security events (authentication success/failure, authorization denial, input validation failure) with timestamp, principal, source, and outcome, but never log secrets or full card numbers.

Suppress or mask sensitive data in logs and error pages; use centralized exception handling so no code path returns raw exception detail.

Configure production error pages and disable debug/verbose modes before deployment; debug endpoints are a common finding in DAST scans.

SAST analyzes source, bytecode, or binaries without executing the application; it finds issues early and can pinpoint the exact file and line.

DAST tests a running application from the outside, exercising it like an attacker; it finds runtime and configuration issues but cannot see source.

SAST strengths: early feedback, full code coverage, data-flow and taint analysis. Weaknesses: false positives, inability to see runtime configuration or third-party binaries.

DAST strengths: technology-agnostic, detects runtime misconfigurations and auth flaws. Weaknesses: limited code coverage, requires a deployed environment, cannot localize the defect.

Taint analysis tracks untrusted sources (request parameters) to dangerous sinks (SQL execution, command execution, response output) through sanitizers.

Interactive (IAST) and software composition analysis (SCA) complement SAST/DAST: IAST instruments runtime agents, SCA inventories third-party dependencies against known CVEs.

False positive triage requires a reproducible proof; false negatives are addressed by expanding rule sets, authentication coverage, and crawl depth.

Integrate SAST in the CI pipeline on pull requests and DAST against a staging environment; gate builds on severity thresholds rather than raw counts.

Harden build artifacts: pin dependency versions, verify checksums and signatures, and generate an SBOM to track components and their CVEs.

Secrets in CI/CD must come from a secrets manager with short-lived credentials; environment variables in build logs leak frequently.

Deployment environments must separate dev, test, and production with distinct credentials and data; production data should not be copied to test systems unmasked.

Infrastructure as code must be scanned for misconfiguration (open storage buckets, permissive security groups, unencrypted volumes) before apply.

Patch management uses risk-based SLAs (e.g., critical CVEs within 7-14 days) and tracks dependency versions continuously.

Runtime protections include WAF rules, RASP agents, least-privilege container users, read-only filesystems, and network segmentation.

Monitoring and alerting on security events (repeated auth failures, privilege changes, anomalous egress) provide detection after preventive controls fail.

Backup, restore testing, and documented incident response procedures are maintenance controls that limit impact of compromise or ransomware.