312-96

CASE Java (312-96) Exam Details

Domain Weight Breakdown

About the CASE Java Certification

The EC-Council Certified Application Security Engineer (CASE) Java certification validates a developer's ability to build secure Java applications. It covers the entire secure software development lifecycle (SSDLC), from threat modeling and secure design to secure coding, testing, and deployment. The certification is designed for Java developers, software engineers, and application architects who want to demonstrate proficiency in writing secure code and defending applications against the OWASP Top 10 and other common vulnerabilities.

Prerequisites include at least two years of Java development experience or completion of EC-Council's official CASE training. The exam focuses heavily on practical secure coding techniques specific to the Java platform, including the use of Java Security APIs, Spring Security, and Jakarta EE security features.

OWASP Top 10 - Key Vulnerabilities for Java

SQL Injection Prevention in Java

SQL injection occurs when untrusted input is concatenated directly into SQL queries. Java provides several layers of defense against this attack vector.

• PreparedStatement (Parameterized Queries): Always use PreparedStatement instead of Statement. Bind parameters with setString(), setInt(), etc. The JDBC driver handles escaping automatically.
• JPA / Hibernate: Use named parameters (:paramName) or positional parameters (?1) in JPQL. Avoid concatenating user input into HQL/JPQL strings.
• Stored Procedures: Use CallableStatement with parameterized inputs. Stored procedures offer an additional layer but are not immune if they internally use dynamic SQL.
• Input Validation: Whitelist acceptable characters and patterns. Reject input that contains SQL metacharacters where not expected. Use regex validation on the server side.
• ORM Criteria API: Use JPA Criteria API or Hibernate Criteria for type-safe, programmatic query construction that eliminates string concatenation entirely.

Exam Tip: The exam tests whether you know that PreparedStatement prevents SQL injection by separating SQL logic from data. String concatenation with Statement is ALWAYS the wrong answer.

Cross-Site Scripting (XSS) Prevention

• Use OWASP Java Encoder library: Encode.forHtml(), Encode.forJavaScript(), Encode.forCssString()
• Set Content-Security-Policy headers to restrict inline scripts and external script sources
• Set HttpOnly and Secure flags on cookies to prevent JavaScript access
• JSP: Use <c:out> JSTL tag which auto-escapes HTML by default, or fn:escapeXml()

Cross-Site Request Forgery (CSRF) Prevention

• Synchronizer Token Pattern: Generate a unique CSRF token per session. Include it as a hidden field in forms. Verify the token on the server before processing state-changing requests.
• Spring Security CSRF: Enabled by default. Automatically generates _csrf token. In Thymeleaf: th:action automatically includes the token. For AJAX: read token from meta tag and include in X-CSRF-TOKEN header.
• SameSite Cookie Attribute: Set SameSite=Strict or SameSite=Lax to prevent cookies from being sent with cross-origin requests.
• Double Submit Cookie: Send the CSRF token as both a cookie and a request parameter. Server compares the two values. Works well for stateless architectures.
• Verify Origin Header: Check Origin and Referer headers on the server side to confirm requests come from your domain.

Exam Tip: CSRF attacks exploit the browser's automatic inclusion of cookies. The defense is proving the request was intentionally made by the user, not triggered by a third-party site.

Input Sanitization Best Practices

• Validate on the server side: Never rely solely on client-side validation. All input must be re-validated server-side.
• Whitelist over blacklist: Define what is allowed (alphanumeric, specific patterns) rather than what is blocked. Blacklists can be bypassed with encoding tricks.
• Use Bean Validation (JSR 380): Annotate model fields with @NotNull, @Size, @Pattern, @Email from javax.validation.
• Canonicalize before validation: Decode and normalize input before applying validation rules to prevent double-encoding attacks.
• File upload validation: Check file extension, MIME type, file size, and scan content. Never trust the client-provided filename. Store uploaded files outside the web root.

Java Authentication Frameworks

Session Security in Java

• Session ID Regeneration: Always regenerate the session ID after successful authentication using request.changeSessionId() (Servlet 3.1+) to prevent session fixation attacks.
• Session Timeout: Configure session timeout in web.xml with <session-timeout> or programmatically with session.setMaxInactiveInterval(seconds). Use short timeouts for sensitive applications (15-30 minutes).
• Secure Cookie Attributes: Set HttpOnly (prevents JavaScript access), Secure (HTTPS only), SameSite (prevents CSRF), and a restrictive Path on session cookies.
• Session Invalidation: Call session.invalidate() on logout to destroy all session data. Clear authentication cookies explicitly.
• Concurrent Session Control: Spring Security sessionManagement().maximumSessions(1) limits concurrent logins per user, preventing session hijacking from multiple locations.

Exam Tip: Session fixation is prevented by regenerating the session ID after login. Session hijacking is mitigated by HttpOnly cookies, HTTPS, and short timeouts.

JSON Web Tokens (JWT) in Java

• Java Libraries: jjwt (io.jsonwebtoken), Nimbus JOSE+JWT, Auth0 java-jwt
• Token Storage: Store in HttpOnly cookies (preferred) or Authorization header. Never store in localStorage (vulnerable to XSS).
• Token Expiration: Set short expiration for access tokens (15-30 min). Use refresh tokens (longer-lived) stored securely server-side for token renewal.
• Token Revocation: Implement a token blacklist or use short-lived tokens with a refresh token rotation strategy.

OAuth 2.0 and OpenID Connect

Spring Security OAuth2: Use spring-boot-starter-oauth2-client for OAuth2 login and spring-boot-starter-oauth2-resource-server for JWT-based resource server. Configure via application.yml with provider details (issuer-uri, client-id, client-secret).

Password Hashing with bcrypt

• bcrypt in Spring Security: Use BCryptPasswordEncoder with a work factor of 10-12. It automatically generates a unique salt per password and includes the salt in the hash output.
• Never use: MD5, SHA-1, or SHA-256 alone for password hashing. These are fast hash functions designed for integrity, not password storage. They are vulnerable to rainbow table and brute-force attacks.
• Alternatives: Argon2 (memory-hard, winner of PHC), scrypt (memory-hard), PBKDF2 (NIST approved, use with HMAC-SHA256 and high iterations).
• Password Policy: Enforce minimum length (12+ characters), check against known breached passwords, allow all characters including spaces, do not require arbitrary complexity rules.

Exam Tip: bcrypt is the default and recommended password encoder in Spring Security. It is intentionally slow (adaptive cost factor) to resist brute-force attacks.

Java Security APIs

Cryptography in Java

• AES-GCM: Provides both confidentiality and authenticity (AEAD). Use Cipher.getInstance("AES/GCM/NoPadding"). Always use a unique IV/nonce per encryption operation.
• Key Management: Store keys in KeyStore (PKCS12 format), never hardcode keys in source code. Use environment variables or a secrets manager (Vault, AWS Secrets Manager) in production.
• TLS Configuration: Enforce TLS 1.2+ via SSLContext.getInstance("TLSv1.2"). Disable weak cipher suites. Enable certificate pinning for mobile apps.

Exam Tip: ECB mode encrypts identical plaintext blocks to identical ciphertext blocks, making patterns visible. Always use CBC or GCM mode for AES encryption.

Secure File Handling

• Path Traversal Prevention: Canonicalize file paths with File.getCanonicalPath() and verify the resolved path is within the allowed directory. Never use user input directly in file paths.
• Temporary Files: Use Files.createTempFile() with restrictive permissions. Delete temp files in a finally block or use try-with-resources.
• File Permissions: Use java.nio.file.attribute.PosixFilePermissions to set restrictive permissions (e.g., owner read/write only).
• Resource Cleanup: Always close streams, readers, and writers using try-with-resources (try (InputStream is = ...)) to prevent resource leaks.
• Deserialization Safety: Never deserialize untrusted data. Use ObjectInputFilter (Java 9+) to whitelist allowed classes. Prefer JSON/XML over Java native serialization.

Error Handling & Logging

• Never expose stack traces: Configure custom error pages in web.xml. Use <error-page> directives to map exception types and HTTP status codes to user-friendly error pages.
• Catch specific exceptions: Avoid catching Exception or Throwable broadly. Catch the most specific exception type and handle each appropriately.
• Secure Logging: Use SLF4J with Logback or Log4j2. Never log passwords, tokens, credit card numbers, or PII. Use parameterized logging (logger.info("User {} logged in", username)) to prevent log injection.
• Log Injection Prevention: Sanitize user input before logging. Replace newline characters (\n, \r) to prevent log forging. Use structured logging (JSON format) for SIEM integration.
• Audit Trail: Log authentication events (login, logout, failed attempts), authorization failures, data access, and configuration changes. Include timestamp, user ID, IP address, and action.

Exam Tip: Error messages shown to users should be generic ("An error occurred"). Detailed error information should only be written to server-side logs accessible to administrators.

Secure Dependency Management

• OWASP Dependency-Check: Maven/Gradle plugin that scans dependencies against the NVD (National Vulnerability Database) and reports known CVEs.
• Snyk / Dependabot: Automated tools that monitor project dependencies and create pull requests for vulnerable library versions.
• Version Pinning: Always specify exact dependency versions in pom.xml or build.gradle. Avoid using version ranges or LATEST/RELEASE tags.
• Repository Security: Use only trusted repositories (Maven Central). Verify checksums and signatures. Consider using a repository manager (Nexus, Artifactory) as a proxy.

Testing Methodologies Overview

SAST (Static Analysis) for Java

• Tools: SonarQube, Checkmarx, Fortify, SpotBugs (with FindSecBugs plugin), PMD, Semgrep
• How it works: Parses source code or bytecode to build an abstract syntax tree (AST) and data flow graph. Traces tainted data from sources (user input) to sinks (SQL queries, file operations) to find vulnerabilities.
• Strengths: Finds vulnerabilities early in SDLC, covers all code paths (including untested ones), provides exact file/line location, integrates into IDE and CI/CD.
• Weaknesses: High false positive rate, cannot detect runtime configuration issues, may miss business logic flaws, does not test deployed environment.
• Best Practice: Run SAST on every pull request in CI. Configure quality gates in SonarQube to block merges with critical security issues. Tune rules to reduce false positives over time.

DAST (Dynamic Analysis) for Java Applications

• Tools: OWASP ZAP, Burp Suite, Acunetix, Netsparker, Qualys WAS
• How it works: Sends crafted HTTP requests to a running application, analyzes responses for vulnerabilities. Acts as an automated attacker (black-box testing).
• Strengths: Tests the actual running application, finds runtime/configuration issues, technology-agnostic, low false positive rate for confirmed findings.
• Weaknesses: Cannot see source code, may miss code paths not reachable via UI, slower than SAST, requires a running environment.
• Best Practice: Run DAST in staging environment that mirrors production. Authenticate the scanner to test behind-login functionality. Combine with SAST for comprehensive coverage.

Code Review for Security

• Manual Code Review: Trained security reviewers examine source code for vulnerabilities, business logic flaws, and insecure patterns that automated tools may miss.
• Review Checklist: Input validation, output encoding, authentication/authorization checks, cryptography usage, error handling, logging practices, SQL query construction, file operations, deserialization.
• Focus Areas in Java: PreparedStatement vs Statement usage, Spring Security configuration, CORS policy, CSRF protection, session management, sensitive data in logs or error messages.
• Pair Programming: Security-focused pair programming where one developer writes code and the other reviews for security implications in real-time.

Penetration Testing

Dependency Scanning & Supply Chain Security

• OWASP Dependency-Check: Maven plugin (org.owasp:dependency-check-maven) scans project dependencies against NVD. Generates HTML/JSON reports with CVE details and CVSS scores.
• GitHub Dependabot: Automatically detects vulnerable dependencies in pom.xml or build.gradle and opens pull requests with version updates.
• Snyk: Commercial SCA tool with CI/CD integration. Provides fix recommendations, license compliance checks, and container image scanning.
• SBOM (Software Bill of Materials): Generate using CycloneDX or SPDX format. Documents all components, versions, and licenses in the application. Required by many compliance frameworks.
• CI/CD Integration: Run SCA tools as part of the build pipeline. Fail builds when critical or high-severity CVEs are detected. Maintain an exception/suppression list for accepted risks.

Exam Tip: SAST analyzes code without running it (white-box), DAST tests the running application (black-box), and IAST combines both approaches using an instrumentation agent.

SAST vs DAST vs IAST vs SCA

Symmetric vs Asymmetric Encryption

Exam Tip: TLS uses asymmetric encryption for the handshake (key exchange) and symmetric encryption for the actual data transfer. This hybrid approach combines security with performance.

Authentication Methods Compared

XSS vs CSRF vs SSRF

SQL Injection vs Command Injection vs LDAP Injection

Password Hashing Algorithms Compared

Exam Tip: Memory-hard algorithms (Argon2, scrypt) resist GPU/ASIC attacks because they require large amounts of memory, making parallel cracking expensive. bcrypt resists brute-force through its adjustable work factor but is not memory-hard.