Security  

Penetration Testing Basics for ASP.NET Core Web Applications

A practical, defensible guide for developers and security testers that explains the what, why, and how of penetration testing (pen-testing) for ASP.NET Core apps—with C# examples you can drop into tooling or test harnesses. Only test systems you own or have explicit written permission to test. Unauthorized testing is illegal.

1. What is penetration testing (short)

Penetration testing is a simulated attack against an application to discover security weaknesses before an attacker does. It complements static analysis (SAST) and dynamic scanning (DAST) by combining automated scanning with manual, creative testing of logic and flows.

Goals

  • Find authentication/authorization flaws and business logic issues.

  • Find input validation, injection, XSS, CSRF, file upload, and session weaknesses.

  • Measure impact (data exposure, privilege escalation, remote code execution).

  • Produce reproducible findings and remediation guidance.

2. Rules of engagement (must read)

Before testing

  • Get written authorization with scope, dates, allowed tools, and contacts.

  • Define in-scope assets (hostnames, endpoints, and environments). Prefer dedicated staging environments.

  • Define out-of-scope items (production databases, payment processors, third-party APIs).

  • Arrange backup and incident contacts in case of accidental disruption.

  • Keep tests non-destructive unless explicitly permitted.

3. Test methodology (high level)

  1. Reconnaissance: gather info about app routes, public assets, and technologies.

  2. Mapping & crawling: enumerate endpoints, API routes, and forms.

  3. Automated scanning: run DAST scanners for common issues.

  4. Manual testing: authentication/authorization logic, business logic flaws, injection, XSS, CSRF, and file upload attacks.

  5. Exploitation & validation: validate findings with non-destructive proof-of-concept (PoC).

  6. Reporting & remediation: document reproduction steps, impact, and mitigation.

4. Reconnaissance & mapping

What to gather:

  • Hostnames, subdomains, and exposed ports.

  • App tech (ASP.NET Core version, server headers, frameworks).

  • Public routes, sitemap, API endpoints, JS files.

  • Authentication flow and third-party integrations.

Tools (high-level): browser DevTools, automated site crawlers (OWASP ZAP / Burp Spider), robots.txt, sitemap.

C# reconnaissance snippet: fetch /.well-known and robots automatically.

using System;
using System.Net.Http;
using System.Threading.Tasks;

public static async Task ReconAsync(string baseUrl)
{
    using var client = new HttpClient { BaseAddress = new Uri(baseUrl) };
    var endpoints = new[] { "/robots.txt", "/.well-known/security.txt", "/favicon.ico" };
    foreach (var ep in endpoints)
    {
        var res = await client.GetAsync(ep);
        Console.WriteLine($"{ep} -> {(int)res.StatusCode} {res.ReasonPhrase}");
    }
}

5. Automated scanning (DAST)

Automated scanners quickly find low-hanging fruit:

  • OWASP ZAP

  • Burp Suite (Professional for automation)

  • Nikto (web server issues)

  • SecurityHeaders.io for header checks

Best practice

  • Scan the staging environment.

  • Use authenticated scans for deeper coverage (login scripts).

  • Review results—scanners produce false positives.

You can orchestrate ZAP in CI (simple Docker command):

docker run --rm owasp/zap2docker-stable zap-baseline.py -t https://staging.example.com -r zap_report.html

6. Manual testing focus areas (with C# testing helpers)

Below are the core manual tests and small C# examples to help automate safe checks.

6.1 Authentication & session management

Check

  • Weak password policy, account enumeration, session fixation, missing MFA.

  • Cookie flags: HttpOnly, Secure, SameSite.

  • Session timeout / logout behavior.

C#: test whether login sets secure cookie flags

using System;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;

public static async Task CheckCookieFlags(HttpClient client, string loginUrl)
{
    var res = await client.GetAsync(loginUrl);
    if (res.Headers.TryGetValues("Set-Cookie", out var setCookies))
    {
        foreach (var c in setCookies)
        {
            Console.WriteLine(c);
            if (!c.Contains("HttpOnly")) Console.WriteLine("Warning: Cookie missing HttpOnly");
            if (!c.Contains("Secure")) Console.WriteLine("Warning: Cookie missing Secure");
        }
    }
}

6.2 Authorization & access control

Check

  • Horizontal privilege escalation (user A accessing user B resources).

  • Vertical privilege escalation (user role bypass to admin).

  • Insecure direct object references (IDOR).

C# approach: call API endpoints with different roles/tokens and assert 403 where appropriate.

// Simplified: send requests with different Authorization headers and assert response codes

6.3 Input validation & injection

Check

  • SQL/command injection, unsafe raw SQL, and deserialization issues.

  • Validate all inputs and ensure use of parameterized queries/ORM.

C# fuzzing snippet to POST common suspicious inputs to an endpoint:

using System;
using System.Net.Http;
using System.Net.Http.Json;
using System.Text.Json;
using System.Threading.Tasks;

public static async Task FuzzEndpoint(HttpClient client, string endpoint)
{
    var payloads = new[] {
        new { name = "normal" },
        new { name = "' OR '1'='1" },
        new { name = "<script>alert(1)</script>" },
        new { name = new string('A', 5000) }
    };

    foreach (var p in payloads)
    {
        var res = await client.PostAsJsonAsync(endpoint, p);
        Console.WriteLine($"Payload len {JsonSerializer.Serialize(p).Length} => {(int)res.StatusCode}");
    }
}

Note: Use safe, non-destructive payloads that reveal behavior (status codes, error messages).

6.4 Cross-Site Scripting (XSS)

Check

  • Reflected, stored, and DOM XSS.

  • Ensure output encoding in Razor/JS and proper Content Security Policy (CSP).

Manual test: insert benign markers (e.g., <<TEST_XSS>>) and search responses. Avoid using real script tags in automated tests if not allowed; use markers and inspect whether they are reflected unencoded.

6.5 Cross-Site Request Forgery (CSRF)

Check

  • State-changing endpoints accept only valid anti-forgery tokens.

  • For APIs: require same-origin checks or anti-forgery header tokens.

C#: attempt POST without anti-forgery token (expect 400 or 403).

var res = await client.PostAsJsonAsync("/account/create", new { dummy = "x" });
Console.WriteLine(res.StatusCode); // should be 400/403 if server enforces CSRF

6.6 File upload handling

Check

  • Restrict file types and validate file signatures.

  • Store outside web root or in blob storage with safe content types.

  • Virus scanning.

Manual: try upload with .jpg extension but containing other content; monitor server response and behavior.

6.7 Business logic flaws

These are app-specific and most valuable:

  • Improper quota checks, pricing bypass, and race conditions (e.g., double spending).

  • Test flows (checkout, refunds) with manipulated parameters and concurrency.

7. Safe exploitation & proof-of-concept

When proving a finding:

  • Use non-destructive PoC (read-only requests; do not modify or delete data unless permitted).

  • Include request/response pairs, length/headers, and steps to reproduce.

  • If a destructive test is required for validation, obtain explicit permission.

8. Tools & utilities (short list)

  • Proxy / Manual testing: Burp Suite (Pro), OWASP ZAP

  • Crawling: Burp Spider, ZAP Spider

  • Automated scanning: ZAP, Nikto

  • Fuzzing/custom testing: custom C# HttpClient scripts, ffuf, wfuzz

  • Scripting: PowerShell/Bash for orchestration, C# for authenticated workflows or integration tests

  • SAST complement: Security Code Scan, Roslyn analyzers, SonarQube

  • Reporting: CSV/Markdown/HTML templates; create tickets in tracker (JIRA/GitHub)

9. Integrating pen-tests into your SDLC

  • Run automated scans on every major release (staging).

  • Add authenticated scans in CI for private endpoints (use test accounts).

  • Schedule periodic manual pen tests (quarterly or before major releases).

  • Track remediation and retest fixes automatically where possible.

You can orchestrate ZAP in CI and upload reports as artifacts. Use a test account and ensure credentials are securely injected into CI (secret variables).

10. Sample penetration testing checklist

Authentication

  • Rate limiting and lockout exist for login endpoints.

  • Multifactor authentication is supported for sensitive roles.

  • Password reset flows cannot be abused.

Authorization

  • Role checks are enforced on server-side endpoints.

  • No IDOR: object IDs validated for ownership.

Input handling

  • Parameterized DB queries/prepared statements are used.

  • Output encoding used for HTML and JS contexts.

  • Size and type checks for file uploads.

Session & cookies

  • Cookies include, and are appropriate SameSite.

  • Sessions expire, and logout invalidates the session server-side.

CSRF & XSRF

  • Anti-forgery tokens validated for state-changing operations.

  • APIs use appropriate CORS rules and CSRF protections.

Security headers & TLS

  • HSTS enabled (non-dev).

  • CSP, X-Frame-Options, and X-Content-Type-Options are present.

  • TLS 1.2+ enforced, no weak ciphers.

Logging & secrets

  • No secrets in code or logs.

  • Sensitive data redacted in logs.

Business logic

  • Validate workflows for race or logic bypass.

11. Reporting: structure & what to include

For each finding, include:

  • Title & ID

  • Severity (Info / Low / Medium / High / Critical)

  • Affected components (URL, API path)

  • Description—what it is and why it matters

  • Reproduction steps—include exact HTTP request/response (redact sensitive data)

  • Proof-of-concept—safe, non-destructive example

  • Impact & risk

  • Recommended remediation—code snippets or configuration changes

  • References—OWASP, MSDN, docs

Example severity mapping

  • Critical—remote code execution, unauthenticated data exposure

  • High—authentication bypass, privilege escalation

  • Medium—stored XSS, SQLi (requires authentication)

  • Low—missing security header, info leak

12. Sample C# test harness

A simple C# test harness that runs a few automated checks and outputs a basic report.

// Minimal demo: run a set of checks and print summary
using System;
using System.Net.Http;
using System.Threading.Tasks;
using System.Linq;

class PentestMini
{
    static async Task Main(string[] args)
    {
        var baseUrl = args.Length > 0 ? args[0] : "https://staging.example.com";
        using var client = new HttpClient { BaseAddress = new Uri(baseUrl) };

        Console.WriteLine($"Running quick checks against {baseUrl}\n");

        // 1. Check security headers
        var res = await client.GetAsync("/");
        Console.WriteLine("Status: " + (int)res.StatusCode);
        var headers = new[] { "X-Frame-Options", "X-Content-Type-Options", "Content-Security-Policy", "Referrer-Policy" };
        foreach (var h in headers)
            Console.WriteLine($"{h}: {(res.Headers.Contains(h) ? "Present" : "Missing")}");

        // 2. Simple POST to state endpoint without CSRF (example)
        var post = await client.PostAsync("/account/create", new StringContent("{\"dummy\":\"x\"}", System.Text.Encoding.UTF8, "application/json"));
        Console.WriteLine($"/account/create => {(int)post.StatusCode} {post.StatusCode}");

        // 3. Check login page cookie flags (GET)
        if (res.Headers.TryGetValues("Set-Cookie", out var sc))
        {
            foreach (var c in sc)
            {
                Console.WriteLine("Set-Cookie -> " + c);
                if (!c.Contains("HttpOnly")) Console.WriteLine("  Warning: cookie missing HttpOnly");
                if (!c.Contains("Secure")) Console.WriteLine("  Warning: cookie missing Secure");
            }
        }

        Console.WriteLine("\nQuick checks finished.");
    }
}

This is a minimal starting point — expand with authenticated flows, role testing, and fuzzing.

13. Legal & ethical reminders

Penetration testing can break systems. Only test with explicit written authorization and follow your organization’s legal and safety requirements. If you find critical vulnerabilities in production, follow your incident response plan.

Membership not found