Information Security

Privilege auditing is the tracking of powerful system privileges (such as CREATE TABLE or SELECT ANY TABLE) when used by users, without being restricted to specific schema objects. Object auditing tracks actions on named schema objects, while auditing privileges with respect to specific objects is not privilege auditing.

Multi-Factor Authentication (MFA) rules can perform different security actions based on risk assessment: Alert (notify security), Challenge (require additional verification), or Block (prevent access). The correct answer is 'All' because MFA systems support all three response types depending on policy configuration.

Multi-Factor Authentication (MFA) rules can perform different security actions based on risk assessment: Alert (notify security), Challenge (require additional verification), or Block (prevent access). The correct answer is 'All' because MFA systems support all three response types depending on policy configuration.

MFA rules can perform Alert, Challenge, and Block actions depending on risk assessment, making 'All' (option D) correct. Options A, B, and C each list only one action, not the complete set.

Security measures (encryption, SSL, authentication) add computational overhead, causing encryption/decryption delays, additional network round-trips for handshakes, and CPU resources for cryptographic operations. This creates an inverse relationship - increasing security generally decreases performance. High security doesn't improve performance, performance isn't a prerequisite for security, and low-performance systems can still be secure (just slower).

CRM Application Security does provide field-level security, allowing administrators to control access to specific fields within the system. This enables fine-grained access control where different users or roles can have view/edit permissions on particular data fields.

XSS vulnerabilities enable attackers to inject malicious scripts into web pages viewed by other users. The primary impact is session hijacking - by stealing cookies or session tokens through injected JavaScript, attackers can impersonate legitimate users and gain unauthorized access to their accounts.

CSRF attacks are prevented by validating unique, unpredictable, and user-specific tokens (like trnsactToken) associated with the current session. HTTPS only encrypts communication to prevent eavesdropping, and encrypting session cookies does not prevent the browser from automatically sending them in CSRF scenarios.

Secure session management requires completely invalidating and destroying sessions on logout, not just displaying generic messages. This prevents session fixation attacks where an attacker could reuse a valid session identifier after logout. Persistent cookies create additional security risks by extending the attack window.

Returning a 404 Not Found response instead of 403 Forbidden prevents information disclosure about directory existence. Attackers probing for sensitive folders learn nothing from 404 responses, whereas 403 responses confirm that something exists but is restricted, providing valuable reconnaissance information.

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.

XSS defenses require preventing malicious script execution. Output encoding converts special characters to safe equivalents (e.g., < to <), blocking script injection. Data validation ensures input matches expected patterns before processing. HTTPS alone (options A and D) protects transmission but not XSS execution.

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.

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.