Application and Web Vulnerabilities Questions

Comprehensive knowledge of common application and web security weaknesses and attack vectors across modern architectures and deployment models. Candidates should understand categories such as structured query language injection, command injection, cross site scripting, cross site request forgery, insecure deserialization, broken authentication and session management, broken access control, sensitive data exposure, insecure cryptography, security misconfiguration, using components with known vulnerabilities, insufficient logging and monitoring, race conditions, server side request forgery, xml external entity attacks, and business logic flaws. They should be able to explain attack mechanisms and exploitation techniques, give real world examples and business impact, and describe architectural and design level mitigations and secure patterns to reduce exposure. Familiarity with taxonomies and severity frameworks such as the Open Web Application Security Project Top Ten and the Common Weakness Enumeration, and an understanding of how prevalence and risk differ by application type, architecture, platform, and deployment pattern, is expected. Candidates should also know common assessment approaches and tooling such as vulnerability scanning, static application security testing, dynamic application security testing, and manual penetration testing.

MediumTechnical

70 practiced

A production web service exposes verbose error messages that include stack traces and internal paths. As a penetration tester, explain the risks, provide steps to safely enumerate what sensitive data might be exposed through errors, and propose immediate configuration changes and long-term error-handling patterns to remediate the issue.

HardTechnical

77 practiced

Concurrent requests to an account-transfer endpoint are suspected to allow double-spending via a race. As a tester, design an automated test harness to reproduce and confirm the race condition, explain how you would safely quantify the likelihood of the race condition in production, and propose code-level and architectural fixes.

Sample Answer

**Approach (brief)** I would build an automated harness that floods the transfer endpoint with concurrent conflicting requests, observes balances and transaction records, and detects inconsistencies (double-spend). Tests run against a staging copy with realistic timing/latency.

**Test harness (example)** - Spawn N concurrent workers that submit transfer requests from same source account to different targets with same nonce/amount. - Verify final ledger rows, account balances, and idempotency tokens.

Example in Python using threads + requests:

python

import threading, requests, time
RESULTS=[]
def send(i):
    r = requests.post("https://staging/transfer", json={
        "from":"acctA","to":f"acct{i}","amount":100,"idempotency_key":"test-race"
    }, timeout=5)
    RESULTS.append((i,r.status_code,r.text))
threads=[threading.Thread(target=send,args=(i,)) for i in range(20)]
for t in threads: t.start()
for t in threads: t.join()
print(RESULTS)
# then query ledger API/db to assert sum balances == precondition

**Quantify likelihood in production (safely)** - Run controlled experiments in canary environment with production-like load and network conditions. - Use feature flags/canary rollout and shadow traffic (replay real traffic to canary). - Measure race occurrence per million transfers, CI vs latency, and plot vs concurrency. - Add monitoring/alerting on invariants: negative balances, balance sum drift, duplicate transaction IDs.

**Code-level fixes** - Wrap transfer in single DB transaction with strong check-and-update: - SQL: UPDATE accounts SET balance = balance - :amt WHERE id=:id AND balance >= :amt; check rows_affected==1 then INSERT ledger. - Use SELECT ... FOR UPDATE or database-supported pessimistic locking for multi-row transfer. - Use idempotency keys and unique constraint on transaction id. - Optimistic locking via version column (WHERE version = x AND ... then increment).

**Architectural fixes** - Centralize money movement in a single service/component (leader) or use distributed lock (e.g., Redis Redlock) per account. - Event-sourcing ledger where balance is computed from immutable events; reconcile off critical path. - Strong telemetry and invariants, automated reconciliation job.

**Why this works** - Atomic DB operations + idempotency prevent concurrent decrements. - Harness reproduces race by maximizing concurrency; canary/metrics quantify real-world risk without user impact.

HardTechnical

66 practiced

GraphQL endpoints often expose flexible queries. As a penetration tester, describe three classes of vulnerabilities specific to GraphQL (e.g., introspection abuse, query complexity DoS, injection), how you'd test for each, and practical mitigations including schema-level fixes and gateway controls.

Sample Answer

**Overview (role: Penetration Tester)** Below are three GraphQL-specific vulnerability classes, how I’d test them, and practical mitigations at schema and gateway levels.

1) Introspection & Info Disclosure - What: Schema introspection reveals types, fields, relationships and custom directives that aid attackers. - Testing: Query __schema and __type; use tools (GraphiQL, graphql-cli, Burp Repeater) to enumerate fields, mutation names, deprecated/reserved operations. Look for sensitive field names (password, ssn, secrets). - Mitigations: Disable introspection in production or require authenticated roles. Schema fix: mark sensitive fields as private (remove from schema or use separate internal-only schema). Gateway: enforce auth & allowlist; return minimal error messages.

2) Query Complexity / DoS (Expensive Traversals) - What: Deep or recursive queries and wide selections cause CPU/DB exhaustion. - Testing: Craft nested queries, large lists, and cycles; use automated flood (slow loris style GraphQL) or tools like GraphQL-Copilot to measure response time and DB load. Try batching queries in one request. - Mitigations: Schema fix: add depth limits, restrict recursive types, and implement connection/pagination defaults. Gateway: enforce max complexity, max depth, rate limits, query cost scoring, caching and query whitelisting.

3) Injection (Field/Argument Injection & Resolver-Level) - What: Arguments or fields used directly in resolvers cause NoSQL/SQL/OS/Graph injections or SSRF. - Testing: Supply payloads for SQLi/NoSQLi (e.g., "' OR 1=1--"), template/command injections, SSRF URLs in file/URL args; fuzz nested inputs and variables; monitor backend errors and side-effects. - Mitigations: Schema fix: apply strict input types (enums, scalars with validation), remove loose JSON scalars; use parameterized DB calls and object mappers. Gateway: input validation, WAF rules, sanitize variables, block outbound requests from resolver contexts.

Practical controls I recommend in reports: require authenticated/role-based resolver access, implement query whitelisting for public endpoints, enforce centralized query cost/depth scoring at the gateway, add schema linting in CI to catch risky types, and instrument telemetry (slow queries, resolver latencies) to detect abuse.

EasyTechnical

107 practiced

Explain Broken Access Control and Insecure Direct Object Reference (IDOR). Given a file download endpoint pattern like /files/download?fileId=12345, describe step-by-step how you'd test for horizontal and vertical access control issues and what PoC you would include in a report.

Sample Answer

**Definition (short)** Broken Access Control occurs when an application fails to enforce who can access which resources or actions. IDOR is a type of broken access control where object identifiers (e.g., fileId) are user-controllable and the server authorizes access only by obscurity.

**Test approach — setup** - Identify endpoint: /files/download?fileId=12345 - Capture a valid request as User A (auth cookie / token).

**Horizontal test (same privilege, different user’s resource)** 1. Enumerate likely fileId patterns (increment, uuid, predictable). 2. As User A, request fileId=12345 then try neighboring IDs (12344,12346). 3. If other users exist, try IDs known to belong to User B. PoC example (curl):

bash

curl -s -H "Cookie: session=USER_A" "https://app/files/download?fileId=12344" -o stolen.pdf

Expected: If successful, User A downloads User B’s file — include HTTP status, response size, headers and sample file hash.

**Vertical test (privilege escalation)** 1. Authenticate as low-privilege user (role=user). 2. Try fileIds reserved for admin or system objects (e.g., 1, admin-report-2026). 3. Attempt to swap tokens: use admin session token if obtainable, or manipulate role parameter if present. PoC: show request with altered Authorization header or role cookie and resulting access.

bash

curl -H "Authorization: Bearer <lowprivtoken>" "https://app/files/download?fileId=1"

Record success, HTTP 200 and file content.

**What to include in report** - Steps to reproduce (captured requests), exact curl/Postman commands, screenshots, response headers, file hashes, severity (e.g., High), impact (data exposure), root cause (missing server-side authorization), and remediation (enforce server-side checks: verify resource ownership & role-based checks, use non-guessable IDs, implement ACLs, rate-limit enumeration).

HardTechnical

63 practiced

You discover an insecure deserialization vulnerability in a microservice that consumes messages from a queue and forwards objects to other services (different languages across services). Explain an exploitation plan that abuses serialization formats to achieve remote code execution or privilege escalation across services, and suggest architectural mitigations to prevent cross-service gadget abuse.

Sample Answer

**Situation & goal (brief)** I’m a penetration tester: I find a microservice that consumes serialized objects from a queue and forwards them to heterogenous downstream services. Goal: craft an exploit that abuses insecure deserialization to get RCE or escalate privileges across services.

**Exploitation plan (stepwise)**

- Recon: enumerate serialization formats on producer/consumer (Java Serialization, Python pickle, PHP serialize, protobuf/Thrift with type metadata). Inspect queue messages and headers for type hints, class names, or version fields.- Local gadget discovery: for each language, look for gadget chains in dependencies (Java: Apache Commons Collections / JDK gadgets via ysoserial; Python: pickle-able classes with __reduce__; PHP: magic methods __wakeup/__destruct). Use existing gadget repositories to craft payloads.- Cross-service chaining: if the consumer deserializes and forwards the object (possibly after minor transformation) to another service that uses a different runtime, include polymorphic payloads or dual-format wrappers (e.g., JSON with embedded base64-serialized blob + type header) to reach the other runtime’s deserializer. Example: a Java consumer deserializes a Java payload, then republishes the object (or its serialized bytes) to a PHP service that unserializes it — chain execution across runtimes.- Deliver payload via queue with OOB callback (DNS, HTTP beacon) to validate RCE, or get a reverse shell when network access allows.- Privilege escalation: target deserialization in higher-privileged services (admin processors), or abuse forwarded credentials/props inside deserialized objects to gain lateral movement.- Stealth & reliability: implement staged payloads (info leak → gadget selection → RCE), retry and fallback gadgets for different library versions.

**Examples**- Java: ysoserial Commons-Collections gadget → command execution when ObjectInputStream.readObject() runs.- Python: pickle payload using subprocess popen in __reduce__ to run system command.- Cross-language: JSON envelope with "payload_type":"java" and "payload":"<base64 java serialized>" — the consumer forwards payload bytes; destination service blindly deserializes.

**Mitigations (architectural, defense-in-depth)**

- Prevent unsafe deserialization: - Replace native binary deserialization with safe formats (strict JSON, protobuf with generated schemas) and avoid deserializing arbitrary objects. - Enforce schema validation and reject messages that include class/type metadata from untrusted sources. - Cryptographically sign and verify messages (message-level HMAC or JWT) to ensure provenance/integrity. - Whitelist permitted types/classes at deserialization time; use safe deserialization libraries/APIs that allow class filtering.- Minimize gadget surface: - Remove unused libraries and dangerous APIs (Commons-Collections, Java Native Serialization). - Use dependency scanning to flag gadget-prone libraries.- Runtime hardening: - Run services with least privilege (no root), restrict network egress, container isolation, and SELinux/AppArmor profiles. - Enable JVM deserialization filters (SerialFilter) or use ObjectInputFilter; in Python, avoid pickle and restrict loading.- Message broker controls: - Separate queues by trust boundary; enforce ACLs, producer authentication, and per-client quotas. - Validate message size and content-type; use separate topics for internal vs external producers.- Detection & response: - Monitor for suspicious deserialization patterns, high-frequency failures, unusual outbound connections; instrument with canary messages and OOB detection. - Run regular fuzzing/gadget tests as part of CI to detect regressions.

**Why this works / trade-offs**- Attack leverages implicit trust in serialized object graphs and presence of gadget classes. Mitigations focus on eliminating trust, reducing gadget availability, and adding provenance checks. Replacing formats and adding filters are highest-impact; signing and runtime confinement compensate where full replacement is infeasible.

Unlock Full Question Bank

Get access to hundreds of Application and Web Vulnerabilities interview questions and detailed answers.

Join thousands of developers preparing for their dream job.