EC-Council CASE study plan
EC-Council CASE · Give each week a clear focus.
8 weeks · About 6 hours per week
Understanding Application Security, Threats, and Attacks & Secure Coding Practices for Input Validation
Map the OWASP Top 10 categories to concrete attack mechanics, writing a one-paragraph attacker narrative for each category that names the vulnerable sink (SQL interpreter, template engine, OS shell, deserializer, browser DOM).
Classify injection families by trust boundary crossed (client-to-server, server-to-database, server-to-OS, server-to-LDAP/XML) and note for each which validation control actually stops it.
Write and then bypass three input validation routines: a regex allowlist, a type/length canonicalization check, and a schema validator; document the exact payload that defeats each weak version.
Explain canonicalization, encoding layers (URL, HTML entity, Unicode, base64), and null-byte truncation well enough to predict how a filter placed before decoding will fail.
Build a personal payload cheat sheet of 20 test strings covering SQLi, XSS, path traversal, command injection, and XXE, each annotated with the defense that neutralizes it.
Your checkpoint
A 10-15 page injection and input-validation lab notebook: one page per attack family with the vulnerable code snippet, the working payload, the root cause, and the corrected code using allowlist validation plus context-aware output encoding.
Secure Coding Practices for Input Validation & Secure Coding Practices for Authentication and Authorization
Implement server-side validation for a sample REST endpoint covering type, range, length, format, and allowed-character rules, and prove client-side checks alone are bypassable with an intercepting proxy.
Configure parameterized queries and stored procedures for a small CRUD app and demonstrate that the same input which broke the string-concatenated version no longer executes.
Compare authentication designs (password-based, MFA/TOTP, federated OIDC) and write the failure modes of each, including credential stuffing, replay, and token theft.
Implement secure password storage using Argon2id or bcrypt with per-user salt and a documented work factor, and justify the chosen cost parameters against hardware benchmarks.
Enforce authorization at the object level: build one endpoint that is broken-object-level-authorization vulnerable and one that checks ownership server-side, then show the request difference.
Your checkpoint
A working demo repository with two branches: a vulnerable build exhibiting SQLi, stored XSS, and IDOR, and a hardened build with parameterized queries, contextual encoding, Argon2id hashing, and server-side ownership checks, plus a README diff explaining every change.
Secure Coding Practices for Authentication and Authorization & Secure Coding Practices for Session Management
Diagram the full authentication and session lifecycle for a web app, marking every point where a session identifier is created, transmitted, rotated, or destroyed.
Implement session management controls: HttpOnly, Secure, and SameSite cookie attributes, idle and absolute timeouts, and session ID regeneration on privilege change.
Distinguish CSRF from XSS-driven request forgery and implement at least two independent CSRF defenses (synchronizer token, Origin/Referer check).
Compare server-side session stores with stateless JWT designs and document the revocation problem, algorithm-confusion risk, and where to keep tokens client-side.
Write authorization test cases for horizontal and vertical privilege escalation and run them against the week-2 demo app.
Your checkpoint
A session security test plan with at least 15 executable test cases (ID, precondition, request, expected secure result, observed result) run against the demo app, with pass/fail results and remediation notes for every failure.
Secure Application Design and Architecture & Secure Coding Practices for Cryptography
Apply threat modeling to one feature using STRIDE, producing a data-flow diagram with trust boundaries, an enumerated threat list, and a mitigation mapped to each threat.
Articulate defense-in-depth and least-privilege as architectural constraints and identify three places in the demo app where a single control failure collapses the whole design.
Implement symmetric encryption (AES-GCM) and asymmetric encryption/signature (RSA or ECDSA) correctly, including unique nonces, authenticated associated data, and secure key storage.
Break common crypto mistakes hands-on: ECB pattern leakage, static IV reuse, hardcoded keys in source, weak PRNG seeding, and password hashing with a fast general-purpose hash.
Select appropriate algorithms and key sizes for data at rest, data in transit, and password storage, and justify each against current guidance.
Your checkpoint
A threat model document for one application feature plus a crypto review checklist of 12 items, each demonstrated with a short before/after code pair showing the insecure and corrected implementation.
Secure Coding Practices for Error Handling & Security Requirements Gathering
Implement centralized error handling that returns generic user-facing messages while logging full diagnostic detail server-side with a correlation ID.
Eliminate information leakage from stack traces, verbose framework debug pages, and differential error messages that enable user enumeration.
Write security requirements as testable statements with measurable acceptance criteria, and derive them from the threat model produced in week 4.
Translate a compliance or business driver into concrete secure design requirements, distinguishing functional, non-functional, and assurance requirements.
Practice abuse-case writing: for each of five features, state how an attacker misuses it and the requirement that prevents it.
Your checkpoint
A requirements and error-handling package: a 20-item security requirements register in testable form (each with acceptance criteria and a linked threat), plus a hardened error-handling module with logging, correlation IDs, and a demonstration that no stack trace or internal path reaches the client.
Static and Dynamic Application Security Testing (SAST & DAST)
Run SAST against the demo repository, triage the findings, and separate true positives from false positives with a written justification for each.
Run DAST against the running application with an intercepting proxy and a scanner, and correlate a DAST finding back to the exact source line that caused it.
Explain the strengths and blind spots of SAST versus DAST versus SCA versus IAST, and pick the right tool class for three given scenarios.
Integrate a scanner into a CI pipeline so a build fails on a defined severity threshold, and tune the rule set to reduce noise.
Write a finding report in standard form: title, severity with justification, reproduction steps, evidence, root cause, remediation, and retest criteria.
Your checkpoint
A vulnerability assessment report on the demo app containing at least 10 findings, each with SAST and DAST evidence cross-referenced to source, a severity rating, and a retest result after remediation.
Secure Deployment and Maintenance & Understanding Application Security, Threats, and Attacks
Harden a deployment: remove debug modes and default accounts, restrict directory listing, enforce TLS with strong cipher suites, and set security headers (CSP, HSTS, X-Content-Type-Options, frame options).
Separate secrets from code using environment injection or a secrets manager, and prove no credential appears in the repository history.
Describe a secure SDLC with security gates at requirements, design, code, test, and deploy, and place the week-6 tooling at the correct gates.
Review the OWASP Top 10 again against your own demo app and score it honestly, noting which categories you can now both exploit and fix.
Draft a patch and maintenance process covering dependency updates, CVE monitoring, and emergency release handling.
Your checkpoint
A deployment hardening checklist of 25 verifiable items, each marked pass/fail against the demo app with evidence (header dump, config diff, or scan output), plus a one-page secure SDLC gate diagram placing SAST, DAST, and SCA.
Understanding Application Security, Threats, and Attacks & Security Requirements Gathering & Secure Application Design and Architecture & Secure Coding Practices for Input Validation & Secure Coding Practices for Authentication and Authorization & Secure Coding Practices for Cryptography & Secure Coding Practices for Session Management & Secure Coding Practices for Error Handling & Static and Dynamic Application Security Testing (SAST & DAST) & Secure Deployment and Maintenance
Re-derive each domain's core controls from memory on a blank sheet, then check against your notes and log every gap.
Re-run every hands-on lab from weeks 1-7 without notes and record which ones you cannot complete unaided.
Take two full-length timed practice assessments and analyze every wrong answer by domain to find weak areas.
Close the three weakest domains with targeted review and one new hands-on exercise per weak domain.
Assemble a one-page pre-exam reference of the controls, algorithms, headers, and tool classes you keep forgetting.
Your checkpoint
A gap analysis scorecard across all 10 domains with self-rated confidence, practice-exam scores, a list of remaining weak areas with a remediation action for each, and the final one-page reference sheet.
Milestones
Week 2: You can explain, without notes, why client-side validation never substitutes for server-side validation, and you have a working vulnerable-versus-hardened demo repository with parameterized queries and Argon2id hashing committed.
Week 4: You have produced a STRIDE threat model with trust boundaries and mapped mitigations, and you can demonstrate at least three broken-crypto failures (ECB leakage, IV reuse, hardcoded key) and their corrected implementations.
Week 6: You have run both SAST and DAST on your own application, cross-referenced at least one finding from scanner output to source line, and written 10 findings in standard report format with retest results.
Week 8: You score consistently above your target pass threshold on two timed practice assessments, and every domain rated low-confidence in week 8 has a completed remediation action rather than an open item.