Web Application Security and AppScan

AppScan systematically tests all forms including password change functionality, so it submitted the change password form during automated testing. This is not an attack but rather AppScan exercising the application's functionality, which is why testing should be done against non-production environments.

AppScan discovered hidden files on external domains because third-party domains were not excluded from the scan scope. When applications include content or links from external sources, AppScan follows those links and tests them, reporting findings from domains outside the target application.

AppScan identifies predictable credentials as weak password patterns. Options A, B, and D use simple variations (admin1, nAscar, nascar2) that are easily guessed. Option C (n@sc1234r) includes special characters and numbers in a non-obvious pattern, making it the least predictable and therefore NOT flagged.

Server path disclosure occurs when server-side file paths are exposed in responses. Option C (d:/etc/host/pwd) reveals an actual Windows server file path structure. Options A and B show relative paths or HTML comments, while D shows JavaScript code - none expose actual server filesystem paths.

DAST security tools like AppScan send automated payloads that can modify database contents or degrade application performance. Running scans in preproduction ensures that production databases remain safe and that active users experience no service disruptions or functionality failures during testing.

Pre-test preparations should prevent disruption and enable rollback. Informing users (A) prevents panic from unusual activity. Notifying QA/admins (B) ensures they understand test behavior. Database backup (C) enables recovery if tests cause damage. SMTP shutdown (D) is unnecessary - email testing should be controlled, not disabled.

Malicious file execution allows attackers to run arbitrary code on the server. This most severely leads to site defacement and complete application takeover (C) as the attacker gains server-level access. User account compromise (A, D) and session theft (B) are possible but less severe than full server control.

Secure coding (D) is foundational - building applications without vulnerabilities from the start prevents entire attack classes. HTTPS (A) and encryption (B) protect data in transit but don't prevent application logic flaws. Black box testing (C) finds issues but doesn't prevent them.

HTTP status codes indicate request outcomes. 500 (Internal Server Error) specifically indicates server-side application errors. 400 is client error, 302 is redirect, 200 is success - none indicate server application failure.

Information leakage exposes internal system details to users. Call stack traces (C) reveal file paths, function names, and internal architecture - valuable intelligence for attackers. Options A and B show normal user-facing messages; 404 (D) is a standard error code.

AppScan lockout occurs when automated testing triggers account lockout mechanisms. Repeatedly testing login/logout pages causes multiple failed login attempts. Excluding these pages (A) prevents AppScan from triggering the lockout while still scanning other functionality. Thread count (B) and timeout settings (C, D) don't address account lockout logic.

Since AppScan only scans the host defined in the starting URL, any additional host or domain accessed by the application must be added to the 'Additional servers and domains' settings. This ensures AppScan is authorized to crawl and test those components.

Insecure Direct Object Reference (IDOR) occurs when internal implementation references (file paths, database keys, directory names) are exposed in URLs or parameters. Attackers can modify these references to access unauthorized objects. Cross-site Scripting (A) injects scripts, Injection Flaws (C) manipulate commands, CSRF (D) tricks users - none involve direct object references.

An out-of-session error occurs when AppScan cannot maintain a valid login session during a scan, typically because a dynamic session parameter or ID is not being properly tracked. Platform authentication, redundant path limits, and flash parsing are unrelated to session tracking failures.

The embedded script () appeared in responses without being injected by the current request, indicating it was stored by the application and returned to users. This is Stored XSS (A) where malicious script persists on the server. Regular XSS (B) is reflected immediately. The path traversal attempt failed, and directory listing (D) is unrelated to script injection.

IBM AppScan is a dynamic application security testing (DAST) tool designed to scan the web application itself, the underlying web server hosting it, and the web application platform. It does not scan operating systems or network-layer devices, which are handled by network vulnerability scanners.

AppScan out-of-session errors occur when the scanner loses its session context. After 30 minutes, sessions commonly expire. If a session parameter (cookie, URL token) isn't tracked (B), AppScan can't maintain session state and loses access. Redundant path (A), Flash parsing (C), and platform authentication (D) don't directly cause session loss.

Attackers exploit web application vulnerabilities by crafting and sending malicious HTTP requests that contain payloads designed to trigger flaws like SQL injection or XSS. Firewalls operate at the network level and cannot inspect HTTP payloads, while viruses and traffic sniffing target different attack surfaces.

Failure to restrict URL access allows attackers to browse sensitive directories, files, or privileged pages directly. Injection flaws involve untrusted input execution, insecure storage exposes data at rest, and insecure communication lacks encryption, none of which directly permit directory browsing via URLs.

HTTPS encryption prevents sensitive information like passwords, session tokens, and personal data from being intercepted during transmission between client and server. It does not prevent server-side attacks like SQL injection or XSS, which occur at the application layer.