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

55 practiced

Given this client-side snippet in a Node/Express app: document.getElementById('name').innerHTML = userInput; and an HTML view that renders user supplied names, identify the XSS risk and propose secure fixes at both server and client sides. Also describe a short automated test or assertion that would catch regressions introducing this XSS during CI.

Sample Answer

**Risk (brief)** Rendering userInput directly into innerHTML creates stored/reflected XSS: an attacker can submit payloads like <script>alert(1)</script> or event handlers that execute in victims' browsers.

**Server-side fixes**- Validate & canonicalize input: allow only expected characters (e.g., names: letters, spaces, hyphens) using a whitelist.- Encode on output if inserting into HTML templates (HTML escape). Example in Express with Pug/EJS: use built-in escaping (do not mark as safe).- Sanitize rich input with a trusted library if needed (DOMPurify server-side via jsdom is acceptable).

Example (whitelist):

javascript

// Node/Express validation middleware
function validateName(req, res, next) {
  const name = req.body.name || '';
  if (!/^[\p{L}\s'-]{1,100}$/u.test(name)) return res.status(400).send('Invalid name');
  next();
}

**Client-side fixes**- Avoid innerHTML; use textContent or setAttribute to insert untrusted text.

javascript

// safer DOM update
document.getElementById('name').textContent = userInput;

- If you must accept HTML, sanitize with DOMPurify before inserting:

javascript

const clean = DOMPurify.sanitize(userInput);
element.innerHTML = clean;

**CI automated test / assertion**- Add a unit/integration test that renders the view with a malicious payload and asserts the output contains the escaped text or no script execution marker. Example Jest + jsdom:

javascript

test('renders name safely', () => {
  const payload = "<img src=x onerror=window.__xss=1>";
  renderViewWithName(payload); // server-side render or client JS run
  expect(global.window.__xss).toBeUndefined();
  expect(container.querySelector('#name').innerHTML).not.toContain('onerror');
  expect(container.querySelector('#name').textContent).toContain(payload.replace(/</g,'<'));
});

Also include an automated scanner (OWASP ZAP or npm package) in CI to detect XSS regressions.

EasyTechnical

69 practiced

Explain the CVSS v3 base metrics and how each metric (attack vector, attack complexity, privileges required, user interaction, scope, confidentiality impact, integrity impact, availability impact) influences the overall base score. Provide a concrete example comparing a remote code execution in a public web app versus a local privilege escalation and how CVSS metrics differ between them.

MediumSystem Design

66 practiced

Describe how you would verify a remediation for an SQL injection vulnerability end-to-end. Include automated unit and integration tests, DAST tests to run in CI, CI pipeline gates to prevent regressions, rollback considerations if a fix causes instability, and metrics to prove the vulnerability is resolved and remains fixed.

Sample Answer

**Clarify scope & goal**Verify an SQLi remediation end-to-end: ensure vulnerable input paths are fixed, tests (unit/integration/DAST) catch regressions, CI gate blocks bad builds, safe rollback exists, and metrics show resolution over time.

**1) Automated unit & integration tests**- Unit: add parameterized tests asserting all DB calls use parameterized queries/ORM APIs or sanitized query builders. Mock DB to confirm no string concatenation.- Integration: spin up ephemeral app + test DB; run tests that exercise endpoints with malicious payloads (e.g., "' OR '1'='1") and assert: - payload does not alter query logic (no elevated results) - queries use prepared statements (trace DB logs or query plan markers) - response codes/contents are sanitized

**2) DAST in CI**- Include an authenticated DAST job (e.g., OWASP ZAP/Burp CLI) against staging after integration tests. Run focused SQLi scans for injected payloads and evidence of clause manipulation or error-based leakage.- Use baseline and tuned attack rules to reduce false positives; fail build on high-confidence SQLi findings.

**3) CI pipeline gates**- Unit & integration tests must pass.- Static scan (SAST) checks for unsafe concatenation patterns; if SAST flags high-severity SQL construction, block merge.- DAST high-confidence alerts fail pipeline.- Require peer review with security reviewer approval for database-query changes.

**4) Rollback & mitigation**- Feature-flag the fix or deploy behind a canary for a percentage of traffic; monitor errors and DB metrics.- If instability: automatically rollback via CI/CD (previous stable image), revert feature flag, and create emergency patch branch.- Preserve logs and DB query traces for post-mortem before rollback.

**5) Metrics to prove resolution**- Pre/post attack success rate: automated attack suite should drop to 0% success for exploited endpoints.- DAST results: zero high-confidence SQLi alerts for 30+ days.- SAST findings: no new high/critical SQL construction alerts.- Runtime telemetry: database error rates, anomalous query patterns, and number of suspicious payload hits.- Regression rate: zero reintroductions detected by continuous tests over rolling 90 days.

**6) Continuous validation**- Schedule regular DAST scans, gated SAST on PRs, and periodic pentests. Feed findings into triage and update tests to cover any new vectors.

This approach ensures technical verification, CI enforcement, safe rollouts, and measurable evidence the vulnerability is resolved and remains fixed.

MediumTechnical

70 practiced

Write a Python script that reads a SAST JSON output file and filters for findings with severity high or critical. Deduplicate findings by a fingerprint made of file path and function or method name, and output a CSV with columns severity, file, function, line, and fingerprint. Describe any assumptions you make about the JSON schema and how you handle missing fields.

Sample Answer

**Approach**- Parse JSON, filter severity in {"HIGH","CRITICAL"} (case-insensitive).- Build fingerprint = f"{file_path}::{function_name}" (use "<unknown>" when missing).- Deduplicate by fingerprint keeping first occurrence (or highest severity / earliest line).- Write CSV with columns: severity,file,function,line,fingerprint.

**Assumptions**- JSON is either a dict with "findings" list or a top-level list of findings.- Each finding may contain fields: "severity", "location"/"file", "function"/"method", "line"/"line_number".- Missing file/function/line are replaced with "<unknown>" or -1.

python

# python3
import json, csv, sys

def normalize_sev(s):
    return (s or "").strip().upper()

def extract(f):
    # tolerate multiple schema variants
    sev = f.get("severity") or f.get("level")
    location = f.get("location") or {}
    file = location.get("file") or f.get("file") or "<unknown>"
    function = f.get("function") or f.get("method") or f.get("symbol") or "<unknown>"
    line = location.get("line") or f.get("line") or f.get("line_number") or -1
    return normalize_sev(sev), file, function, line

def main(json_path, csv_path):
    with open(json_path) as fh:
        j = json.load(fh)
    findings = j.get("findings") if isinstance(j, dict) and "findings" in j else j
    seen = {}
    rows = []
    for f in findings:
        sev, file, function, line = extract(f)
        if sev not in ("HIGH","CRITICAL"):
            continue
        fp = f"{file}::{function}"
        if fp in seen:
            continue
        seen[fp] = True
        rows.append({"severity":sev,"file":file,"function":function,"line":line,"fingerprint":fp})
    with open(csv_path,"w",newline="") as out:
        writer = csv.DictWriter(out, fieldnames=["severity","file","function","line","fingerprint"])
        writer.writeheader()
        writer.writerows(rows)

if __name__ == "__main__":
    main(sys.argv[1], sys.argv[2])

Complexity: O(n) time, O(m) memory for m unique fingerprints. Handles missing fields by default tokens; change behavior to prefer latest/highest-severity if desired. Useful in CI to fail build when deduped criticals present.

HardTechnical

65 practiced

A native library used by your application has a published memory corruption vulnerability but the vendor provides limited exploit details. Explain how you would assess exploitability given mitigations like ASLR, NX, stack canaries, and container isolation. Recommend immediate runtime mitigations, long-term code fixes or vendor updates, and how to test whether your deployed runtime is vulnerable.

Sample Answer

**Assessing exploitability (high-level steps)**

- Reproduce & triage: build a minimal testcase from vendor details or trigger crash in staging, capture core dump.- Static/runtime inventory: check binary hardening (PIE/ASLR, NX, RELRO, stack canaries) with readelf/objdump and ldd to confirm shared object locations and symbol visibility.- Dynamic analysis: run under gdb/rr to get PC/stack at crash; use ASAN/UBSAN/Valgrind to surface heap/stack issues.- Attack surface & threat model: identify attacker-controlled inputs, whether exploit crosses privilege boundaries or stays inside container, and possible gadget availability for ROP.

**How mitigations change exploitability**- ASLR/PIE: increases difficulty (requires info leak) but not sufficient if info leak exists.- NX: prevents direct shellcode; ROP/jump-oriented techniques still possible.- Stack canaries: stop simple stack-smash returns; bypassable via info leak or non-stack corruption.- Container isolation: reduces blast radius but does not prevent local privilege escalation or VM escape; treat as defense-in-depth, not mitigation for exploitability.

**Immediate runtime mitigations (short-term)**- Apply process hardening: ensure PIE, FULL RELRO, NX, stack-protector-strong are enabled for the binary.- Run as least-privileged user, drop capabilities, use seccomp filters and AppArmor/SELinux policies.- Container controls: enable user namespaces, read-only filesystem, cgroups, disable host mounts.- Network controls / WAF to block exploit vectors; restrict inputs to vulnerable library.- Monitor: enable crash telemetry + alerting, EDR signatures for anomalous process behavior.

**Long-term fixes / vendor actions**- Push vendor for patch and PoC details; request backports for supported versions.- Replace or rewrite unsafe code paths with memory-safe alternatives or add strong bounds checking.- Integrate fuzzing (AFL/LibFuzzer) and sanitizers into CI; add regression tests for the crash case.- Adopt supply-chain controls: signed packages, SBOM, pin versions, regular binary hardening checks.

**Testing whether deployed runtime is vulnerable**- Binary checks: - readelf -h / readelf -s to confirm PIE/RELRO/canary symbols.- ASLR toggle test: - sysctl kernel.randomize_va_space and reproduce crash with ASLR on/off to see dependencies on fixed addresses.- Instrumented tests: - Run exploit-proof PoC in isolated lab/container; use gdb/rr to observe control-flow hijack possibility. - Run ASAN/UBSAN builds and fuzz targeted APIs to find additional triggers.- Pen-test: perform controlled exploit development in isolated environment to determine practicality and requirements (info leaks, gadget chains).

**Conclusion / recommendation**Treat this as high-priority: apply runtime hardening and isolation immediately, run focused fuzzing/sanitizers and exploit development in lab to assess real exploitability, and push for vendor patch/backport while planning replacement or remediation if vendor response is slow.

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.