Web Application Security and AppScan

When part of the app uses a domain name but login uses IP (10.1.52.3), AppScan needs to know about both to test the complete application. Adding the domain to 'Additional servers and domains' allows AppScan to follow links and test all parts. Adding only the IP or changing code are incorrect approaches.

Proper session management requires destroying session data on logout to prevent session hijacking. Invalidating and destroying the session removes all session data from server. Displaying personalized info (A) or generic welcome (B) doesn't address session security. Persistent cookies (D) increase security risk as they remain after browser closes.

The injected payload contains %0d%0a (CRLF - carriage return + line feed) used to split HTTP responses. AppScan tests for HTTP Response Splitting by injecting these characters to attempt injecting arbitrary headers or splitting the response body. This can lead to cache poisoning, XSS, or other attacks. CRLF injection is the key indicator.

AppScan automatically fills and submits forms during testing, including password change forms. When it encounters a password change form, it submits with auto-generated values like '1234', changing the actual password. This is normal testing behavior, not an attack. Solution: use a dedicated test account during scans.

AppScan flags predictable credentials using patterns: dictionary words, simple substitutions (1 for i, 0 for o, @ for a), or minimal variations. 'n@sc1234r' uses special characters and numbers unpredictably. Others: admin1 (common word+number), nAscar (simple substitution), nascar2 (minimal variation). The special characters and random number placement make C harder to predict.

Server path disclosure occurs when absolute file system paths are exposed. 'd:/etc/host/pwd' is a Windows absolute path revealing server directory structure, helping attackers understand layout and plan attacks. Relative paths (../) don't show server location. HTML comments and JavaScript strings are client-side and don't directly expose server paths.

Malicious file execution allows attackers to upload and execute arbitrary code on the server, leading to complete server takeover. This enables site defacement, data theft, using the server to attack others, and full control of the application. Impact is far more severe than compromising individual user accounts or sessions - it's total server compromise.

Multi-step operations record complex application flows requiring multiple sequential requests to reach a specific state or functionality. This includes multi-page forms, wizards, workflows where state changes across requests, or any scenario requiring navigation through several pages. It's not just for login sequences or parameter manipulation - it captures any complex user journey.

SOX, HIPAA, and FISMA are regulatory compliance frameworks. AppScan categorizes them under Compliance because they represent legal and industry requirements organizations must meet, not technical standards or custom configurations.

AppScan discovered files from third-party domains linked in your application. These must be excluded from scan scope, otherwise AppScan crawls them as if they were part of your app, reporting findings that aren't actually yours.

Parameter tracking ensures AppScan tests each unique page value separately. If you ignore or limit it, AppScan might only test one value and miss vulnerabilities on other pages.

The Difference pane shows the exact modifications AppScan made to the original request when constructing a test. It highlights what payload or parameter was changed, which is crucial for understanding how the vulnerability was tested.

HTTP 500 status codes specifically indicate server-side errors. These are application errors thrown during execution (exceptions, crashes, unhandled conditions), unlike 4xx codes which indicate client request problems.

High thread counts and low timeouts cause communication errors and network congestion. Reducing the thread count decreases load and resource contention, while increasing the timeout allows slow responses to complete successfully rather than failing.

AppScan operates as a black-box tool, testing applications from the outside by sending HTTP requests and analyzing responses without accessing source code or internal state. It simulates an external attacker's perspective.

.NET web services traditionally use SOAP, where parameters are embedded in the XML SOAP envelope. AppScan modifies these SOAP parameters to inject test payloads, not the HTTP-level GET/POST parameters or cookies.

XSS injects JavaScript that executes in victims' browsers, allowing attackers to access cookies, session tokens, or other sensitive data. Unlike SQL injection or command injection, XSS doesn't directly affect the server or database.

Anti-CSRF tokens like the trnsactToken in option A prevent CSRF by including an unpredictable, session-bound value that attackers can't guess. HTTPS and cookie encryption protect against different threats (eavesdropping), not CSRF.

Sending a 404 Not Found code hides a resource's existence entirely. A 403 Forbidden or 302 Found (redirect) reveals the resource exists but requires access rights or redirection, whereas a 200 OK indicates success and exposes the resource.

Secure coding practices address vulnerabilities at the root level during development. While HTTPS, encryption, and testing are vital, they are secondary defenses if the code itself is fundamentally insecure.