A public-facing permits API is abused with SQL-injection-style input. What is the attack vector?
Select an answer to reveal the explanation.
Short Explanation
The attacker did not need the VPN or a vendor laptop—they typed hostile input into the permits API. That is a vulnerable public web application. Keep the vector on the app that accepted the injection.
Full Explanation
A public-facing permits API abused with SQL-injection-style input is a vulnerable civic web application as the attack vector. Hostile input accepted by the permits service is the door; the attacker did not need VPN access or a vendor laptop for this path. Municipal permitting systems are attractive because they are public and often complex; application-layer injection remains a first-class introduction vector even when the city also worries about remote access and IoT elsewhere. Keep the vector label on the app that accepted the malicious input.
Calling it the city's SSL-VPN used by remote staff fails by concept: the abused interface is the public permits API, not the VPN concentrator. Calling it an unmanaged parking-kiosk vendor laptop fails by concept: no vendor endpoint connecting to a LAN is described. Calling it a forgotten facilities camera with internet RDP fails by concept: the stem targets the permits API with injection-style input, not camera remote-desktop exposure.
Exam caveat: Injection against a public civic application equals vulnerable web application vector; keep the label on the application that accepted the input.
Operational check: Take the vulnerable endpoint into incident response, review WAF and application logs in Splunk, patch or virtual-patch the injection flaw, rotate any exposed data secrets, and add or tune Enterprise Security detections for SQLi patterns on permits URIs.