Web Application Security Testing

Repudiation threats involve a user denying legitimate actions they performed. Non-repudiation mechanisms like digital signatures and audit logs provide evidence of transactions. Spoofing (A) is impersonation, tampering (B) is unauthorized modification, and DoS (D) disrupts availability. The scenario describes a classic repudiation risk where a user falsely denies executing a transaction.

HTTP is stateless - each request stands alone with no memory of previous requests. Session IDs create continuity by storing user state on the server, referenced via cookies or headers. Stateful protocols (A) maintain connection state inherently. File transfer (C) and email protocols (D) are unrelated to HTTPs statelessness and session management.

Parameterized queries separate SQL logic from data, preventing injection by treating user input as literal values not executable code. SSL/TLS (A) encrypts transmission but doesnt stop injection. URL/HTML encoding (B) mitigates XSS, not SQLi. Directory restrictions (D) address information disclosure, not injection. Parameterized queries (also called prepared statements) are the primary defense.

Spiders, robots, and crawlers automate information gathering by traversing websites and cataloging content, links, and structure. This reconnaissance phase identifies targets, technologies, and potential vulnerabilities. Authentication (A) and authorization (D) testing focus on access controls. Session management (B) concerns maintaining user state. These tools primarily enable discovery and mapping.

CAPTCHAs specifically resist automated solving by design - they test humanity. Fuzzers like WebScarab send massive automated requests but cannot interpret visual/audio challenges meant for humans. Fuzzers can discover files (A), test lockout limits (B), and attempt passwords (C). CAPTCHA breaking requires human interaction or specialized AI, not simple request automation, making it unsuitable for fuzzing tools.

Blind SQL injection reveals no data in responses, so testers use time-based techniques like WAITFOR DELAY (SQL Server) or sleep() (MySQL) to confirm vulnerability. If injection succeeds, the delay occurs. Options C and D work in reflected injection where results appear in page output. Option B causes errors regardless. Time-based observation (A) is definitive for blind scenarios.

POST is more secure than GET for form data because GET places parameters in the URL query string, which is visible in browser history, server logs, and can be cached. POST sends data in the request body, which is not logged or cached by default. PUT is for updates, TRACE is for debugging (and often disabled for security reasons). For sensitive form data, POST is the recommended method.