312-97

CASE .NET (312-97) Exam Details

Domain Weight Breakdown

About the CASE .NET Certification

The EC-Council Certified Application Security Engineer (CASE) .NET certification validates a developer's ability to build secure applications using the .NET framework and C#. It covers the entire secure software development lifecycle (SSDLC), from threat modeling and secure design to secure coding, testing, and deployment within the Microsoft technology stack. The certification is designed for .NET developers, software engineers, and application architects who want to demonstrate expertise in securing ASP.NET applications against the OWASP Top 10 and other common vulnerabilities.

Prerequisites include at least two years of .NET/C# development experience or completion of EC-Council's official CASE training. The exam focuses heavily on practical secure coding techniques specific to the .NET platform, including ASP.NET Core security middleware, Entity Framework parameterization, .NET Identity, and the System.Security.Cryptography namespace.

OWASP Top 10 - Key Vulnerabilities for .NET

SQL Injection Prevention in .NET

SQL injection occurs when untrusted input is concatenated directly into SQL queries. The .NET ecosystem provides multiple layers of defense against this attack vector.

• Entity Framework (EF Core): LINQ queries are automatically parameterized. Use dbContext.Users.Where(u => u.Name == input) instead of raw SQL. EF generates parameterized SQL behind the scenes.
• SqlParameter (ADO.NET): Use SqlCommand with SqlParameter objects. Set cmd.Parameters.AddWithValue("@name", userInput). Never concatenate user input into CommandText.
• Dapper ORM: Use parameterized queries: connection.Query("SELECT * FROM Users WHERE Id = @Id", new { Id = userId }). Dapper binds parameters safely.
• Stored Procedures: Call with CommandType.StoredProcedure and parameterized inputs. Stored procedures provide an additional layer but are not immune if they use dynamic SQL internally.
• EF Core Raw SQL (Safe): Use FromSqlInterpolated($"SELECT * FROM Users WHERE Name = {input}") which auto-parameterizes. Avoid FromSqlRaw with string concatenation.

Exam Tip: Entity Framework LINQ queries are inherently safe from SQL injection. The exam tests whether you know that string concatenation in raw SQL (FromSqlRaw) bypasses this protection.

Cross-Site Scripting (XSS) Prevention

• Razor auto-encoding: By default, @ expressions in Razor views HTML-encode output. Use @Html.Raw() only when you explicitly trust the content.
• HtmlEncoder / UrlEncoder / JavaScriptEncoder: Use System.Text.Encodings.Web namespace for context-specific encoding (HTML, URL, JS).
• Content-Security-Policy: Add CSP headers via middleware to restrict inline scripts and external sources.
• Request Validation: ASP.NET Framework has built-in request validation that rejects input containing HTML. ASP.NET Core relies on output encoding and explicit validation instead.

Cross-Site Request Forgery (CSRF) Prevention

• Anti-Forgery Tokens (ASP.NET Core): Use @Html.AntiForgeryToken() in forms and [ValidateAntiForgeryToken] on POST actions. ASP.NET Core auto-generates and validates the token pair (cookie + hidden field).
• AutoValidateAntiforgeryToken: Apply [AutoValidateAntiforgeryToken] globally to protect all POST/PUT/DELETE actions without decorating each action individually.
• SameSite Cookie Attribute: Configure in Startup.cs: options.Cookie.SameSite = SameSiteMode.Strict to prevent cookies from being sent with cross-origin requests.
• AJAX Requests: For JavaScript fetch/AJAX calls, read the anti-forgery token from a hidden field or meta tag and include it in the RequestVerificationToken header.
• API Endpoints: APIs using JWT or bearer tokens in the Authorization header are inherently CSRF-resistant since the token is not automatically attached by the browser like cookies.

Exam Tip: In ASP.NET Core, the anti-forgery system uses a double-submit pattern: one token in a cookie and one in the form/header. The server validates that both match.

Input Sanitization Best Practices

• Server-side validation is mandatory: Never rely solely on client-side validation. All input must be re-validated on the server even if JavaScript validation exists.
• Model Validation (Data Annotations): Use [Required], [StringLength], [RegularExpression], [Range], [EmailAddress] attributes on model properties. Check ModelState.IsValid in controllers.
• FluentValidation: Third-party library for complex validation rules with a fluent API. Separates validation logic from model classes.
• Whitelist over blacklist: Define what is allowed (alphanumeric, specific patterns) rather than what is blocked. Blacklists can be bypassed with encoding tricks.
• File upload validation: Check file extension, MIME type via content inspection (not just Content-Type header), and file size. Store uploads outside the web root. Use Path.GetRandomFileName() for storage names.

.NET Authentication Frameworks

Session Security in ASP.NET

• Session Configuration: Configure in Startup.cs with services.AddSession(options => { options.IdleTimeout = TimeSpan.FromMinutes(20); options.Cookie.HttpOnly = true; options.Cookie.SecurePolicy = CookieSecurePolicy.Always; }).
• Cookie Security Attributes: Set HttpOnly = true (prevents JavaScript access), SecurePolicy = Always (HTTPS only), SameSite = Strict (CSRF protection), and IsEssential = false for GDPR compliance.
• Session Fixation Prevention: ASP.NET Core regenerates the session cookie on authentication state changes by default when using Identity. For custom auth, explicitly issue a new session after login.
• Distributed Session Store: For multi-server deployments, use AddDistributedRedisCache() or AddDistributedSqlServerCache() instead of in-memory session. Prevents session loss on server restarts.
• Session Invalidation: Call HttpContext.Session.Clear() and await HttpContext.SignOutAsync() on logout. Delete the session cookie by setting its expiration to the past.

Exam Tip: HttpOnly cookies cannot be read by JavaScript (prevents XSS-based session theft). Secure cookies are only sent over HTTPS. SameSite prevents CSRF by restricting cross-origin cookie transmission.

JSON Web Tokens (JWT) in .NET

• .NET Libraries: System.IdentityModel.Tokens.Jwt (Microsoft), Microsoft.AspNetCore.Authentication.JwtBearer middleware
• Token Validation: Configure TokenValidationParameters with ValidateIssuer = true, ValidateAudience = true, ValidateLifetime = true, ValidateIssuerSigningKey = true.
• Token Storage: Store in HttpOnly cookies (preferred for web apps) or Authorization header (APIs). Never store in localStorage (vulnerable to XSS).
• Refresh Token Rotation: Issue short-lived access tokens (15-30 min) with long-lived refresh tokens stored securely. Rotate refresh tokens on each use and invalidate the old one.

OAuth 2.0 and OpenID Connect in .NET

ASP.NET Core OAuth2: Use AddAuthentication().AddOpenIdConnect() for OIDC login or AddOAuth() for generic OAuth2. Configure via appsettings.json with Authority, ClientId, ClientSecret. Duende IdentityServer or Azure AD B2C serve as the identity provider.

Password Hashing in ASP.NET Identity

• Default PasswordHasher: ASP.NET Core Identity uses PBKDF2 with HMAC-SHA256 by default (100,000 iterations in Identity v3). It automatically generates a unique salt per password and includes the salt in the hash output.
• Configuring Iterations: Increase iterations via services.Configure<PasswordHasherOptions>(options => options.IterationCount = 600000) for stronger protection.
• Custom PasswordHasher: Implement IPasswordHasher<TUser> to use bcrypt or Argon2 via libraries like BCrypt.Net-Next or Konscious.Security.Cryptography.
• Never use: MD5, SHA-1, or SHA-256 alone for password hashing. These are fast hash functions vulnerable to rainbow table and brute-force attacks.
• Password Policy: Configure via IdentityOptions.Password: RequiredLength, RequireDigit, RequireUppercase, RequireNonAlphanumeric. Also configure lockout settings: MaxFailedAccessAttempts, DefaultLockoutTimeSpan.

Exam Tip: ASP.NET Identity's PasswordHasher uses PBKDF2 by default (not bcrypt). Know the difference: PBKDF2 is NIST-approved and built into .NET, while bcrypt requires a third-party library.

.NET Security APIs & Namespaces

.NET Cryptography (System.Security.Cryptography)

• AES-GCM in .NET: Use AesGcm class (.NET Core 3.0+) for authenticated encryption (AEAD). Provides both confidentiality and integrity. Always use a unique nonce per encryption operation.
• Data Protection API: Use IDataProtector.Protect() and Unprotect() for encrypting sensitive data (tokens, cookies). Handles key rotation automatically. Simpler than direct cryptography for common scenarios.
• Key Storage: Use Azure Key Vault, AWS Secrets Manager, or DPAPI for key storage. Never hardcode keys in appsettings.json or source code. Use Secret Manager during development.

Exam Tip: In .NET, use RandomNumberGenerator (not System.Random) for security-sensitive random values like tokens, keys, and nonces. System.Random is deterministic and predictable.

Secure File Handling in .NET

• Path Traversal Prevention: Use Path.GetFullPath() to resolve the canonical path and verify it starts with the allowed base directory. Never pass user input directly to File.Open() or FileStream.
• File Upload Security: Validate file extension against an allowlist, verify content type by inspecting file headers (magic bytes), limit file size via [RequestSizeLimit], and store files outside the web root.
• Temporary Files: Use Path.GetTempFileName() and delete in a finally block. Set restrictive ACLs on temp directories.
• Resource Cleanup: Always use using statements or await using for streams, readers, and writers to ensure proper disposal and prevent resource leaks.
• Deserialization Safety: Avoid BinaryFormatter (marked obsolete, known RCE vector). Use System.Text.Json or JsonSerializer with strict type handling. Never deserialize untrusted data with type-name handling enabled.

Error Handling & Logging

• Custom Error Pages: Configure app.UseExceptionHandler("/Error") for production. Use app.UseDeveloperExceptionPage() only in Development environment. Set <customErrors mode="On"> in ASP.NET Framework.
• Global Exception Handling: Implement IExceptionFilter or exception handling middleware to catch unhandled exceptions, log them securely, and return generic error responses to clients.
• Structured Logging: Use Serilog or NLog with structured logging. Example: Log.Information("User {UserId} logged in from {IP}", userId, ipAddress). Never log passwords, tokens, credit cards, or PII.
• Log Injection Prevention: Structured logging frameworks parameterize values, preventing log forging. Avoid string interpolation in log messages. Sanitize user input before logging.
• Application Insights: Microsoft's APM service for monitoring, diagnostics, and telemetry. Automatically collects request metrics, exceptions, dependencies, and custom events. Configure data scrubbing to exclude sensitive fields.

Exam Tip: UseDeveloperExceptionPage() must NEVER be enabled in production. It exposes stack traces, source code snippets, and environment variables to end users.

Secure Configuration Management

• Secret Manager (Development): Use dotnet user-secrets to store development secrets outside the project directory. Secrets are stored in a user-profile-specific JSON file, not in source control.
• Environment Variables: Store sensitive configuration in environment variables. Access via Configuration["Key"] or IOptions<T> pattern.
• Azure Key Vault: Use AddAzureKeyVault() configuration provider for production secrets. Supports automatic key rotation and access policies.
• Configuration Encryption: Use Data Protection API to encrypt sensitive sections in appsettings.json. In ASP.NET Framework, use aspnet_regiis -pe to encrypt web.config sections.

Testing Methodologies Overview

SAST (Static Analysis) for .NET

• Tools: SonarQube (.NET analyzer), Roslyn Security Analyzers, Security Code Scan, Checkmarx, Fortify, Semgrep
• Roslyn Analyzers: Microsoft's compiler platform allows custom code analysis rules that run during compilation. Microsoft.CodeAnalysis.NetAnalyzers includes security rules. Warnings appear directly in Visual Studio.
• How it works: Parses C# source code to build a syntax tree and semantic model. Traces tainted data from sources (user input, HTTP request) to sinks (SQL queries, file operations) to identify vulnerabilities.
• Strengths: Finds vulnerabilities early in SDLC, covers all code paths, integrates into Visual Studio and CI/CD, provides exact file/line location.
• Weaknesses: High false positive rate, cannot detect runtime configuration issues, may miss business logic flaws, does not test deployed environment.

DAST (Dynamic Analysis) for .NET Applications

• Tools: OWASP ZAP, Burp Suite, Acunetix, Netsparker (Invicti), Qualys WAS
• How it works: Sends crafted HTTP requests to a running ASP.NET application, analyzes responses for vulnerabilities. Acts as an automated attacker (black-box testing).
• Strengths: Tests the actual running application including IIS/Kestrel configuration, finds runtime issues, technology-agnostic, low false positive rate.
• 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 mirroring production IIS/Kestrel config. 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 C# source code for vulnerabilities, business logic flaws, and insecure patterns that automated tools may miss.
• Review Checklist: Input validation (Data Annotations), output encoding (Razor), authorization ([Authorize] attributes), EF query construction, error handling (exception middleware), logging practices, CORS policy, CSRF protection.
• Focus Areas in .NET: Entity Framework raw SQL usage, BinaryFormatter deserialization, hardcoded connection strings, missing [Authorize] on controllers, UseDeveloperExceptionPage in production, insecure cookie configuration.
• Pull Request Security Review: Integrate security review as a mandatory step in PR approval. Use branch protection rules to require approval from a security-trained reviewer for sensitive code changes.

Penetration Testing

Dependency Scanning & Supply Chain Security

• dotnet list package --vulnerable: Built-in .NET CLI command that checks NuGet dependencies against known vulnerabilities. Run dotnet list package --vulnerable --include-transitive to include transitive dependencies.
• NuGet Audit: .NET 8+ includes NuGet audit during restore. Warns about known vulnerable packages automatically on dotnet restore or dotnet build.
• GitHub Dependabot: Automatically detects vulnerable NuGet packages in .csproj files and opens pull requests with version updates.
• Snyk: Commercial SCA tool with .NET support. Scans NuGet packages, provides fix recommendations, and integrates into CI/CD pipelines.
• SBOM Generation: Use dotnet CycloneDX or SPDX tools to generate Software Bill of Materials. Documents all components, versions, and licenses for compliance.

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

SAST vs DAST vs IAST vs SCA

Symmetric vs Asymmetric Encryption in .NET

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: ASP.NET Identity uses PBKDF2 (Rfc2898DeriveBytes) by default, NOT bcrypt. Memory-hard algorithms (Argon2, scrypt) resist GPU/ASIC attacks by requiring large amounts of memory, making parallel cracking expensive.