Information Security

View state can be tampered with when passed over unencrypted channels. Setting EnableViewStateMac="true" in the Page directive enables message authentication codes (MAC) that detect tampering. Option A is correct. Option B references a non-existent directive, Option C has incorrect syntax (should be EnableViewStateMac), and Option D is not a standard configuration.

ViewStateMAC (Message Authentication Code) adds a cryptographic hash to view state data, detecting tampering when the data往返s over unencrypted channels. Setting EnableViewStateMac="true" in the Page directive enables this protection. The Register directive is for user controls (not page-level settings), web.config uses different attributes, and IIS doesn't have ViewState-specific protection.

The Intercepting Filter pattern can intercept and modify authentication data in requests before they reach the authentication mechanism. Filters can transform, encode, or process credentials without the user's awareness, which is exactly what this scenario requires. Facade simplifies interfaces, Specialization isn't relevant, and Modifer isn't a standard pattern.

doPost should be used when sending confidential data because POST requests place parameters in the request body rather than the URL. This prevents sensitive information from appearing in browser history, server logs, or URL bookmarks. GET requests expose data in the URL query string, which is less secure for confidential information.

An active credential performs a login on behalf of a client without exposing the secret to the client's code or application. This pattern enhances security by keeping credentials server-side while still allowing authentication. The term 'active' refers to the credential actively performing the login action transparently.

The FormsAuthentication class, which manages forms-authentication services for Web applications, resides in the System.Web.Security namespace. Namespaces like System.Net.Security, System.Data, and System.IO serve network, data access, and input/output purposes respectively.

In TPF (Transaction Processing Facility), data isolation is achieved through reentrancy - the ability for code to be interrupted and re-entered safely without affecting data integrity. Reentrant routines don't modify their own code, allowing multiple executions without interference. Data hiding and encapsulation are broader programming concepts not specific to TPF's isolation mechanism.

Common session tracking mechanisms in web applications include Cookies (storing session IDs), URL rewriting (appending session IDs to URLs), and SSL sessions (using SSL session IDs). The option 'sessions' is not a mechanism but rather the concept being tracked.

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.

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.