Web Application Security Fundamentals

Secure configuration management is essential for all types of applications - commercial off-the-shelf software, custom-built applications, and in-house developments. All software requires proper hardening, patching, and secure configuration.

In asymmetric cryptography, the public key is designed to be shared freely without compromising security. It can only be used to encrypt data or verify signatures - decryption requires the private key which must be kept secret. Encrypted data, private keys, and symmetric keys must all be protected.

Data validation ensures that user input conforms to expected formats before being used in database queries, making it harder for attackers to inject malicious SQL code. Secure cookies, encryption, and exception handling are important security measures but they don't directly prevent SQL injection attacks. SQL injection specifically exploits unvalidated input concatenated into SQL statements.

Cookies should only contain a session identifier that references server-side session data. Storing sensitive information like passwords or account privileges in cookies exposes them to theft and manipulation. Usernames in cookies can also be used for session hijacking and should be avoided - the session ID alone is sufficient.

Hashing creates a fixed-size digital fingerprint that uniquely represents data. If even a single bit changes, the hash will be completely different, making it an excellent mechanism for detecting data tampering. Session validity and user authentication require different mechanisms like expiration tokens and credential verification.

CR (carriage return, %0D or %00 in some encodings) and LF (line feed, %0A) are line break characters used to separate HTTP headers. Attackers inject these characters into input to split the HTTP response and inject arbitrary headers or even content. This is the signature of HTTP Response Splitting (also called CRLF injection).

Forced browsing (or path traversal) attacks succeed when the application fails to check if a user is authorized to access a specific URL or resource. The attacker guesses or enumerates URLs and accesses them directly without proper permission checks. This is fundamentally an authorization failure - the application authenticated the user but didn't verify their right to access that specific resource.

All these protocol combinations are valid and commonly used together. SOAP is an XML-based messaging protocol that typically runs over HTTP for transport (SOAP + HTTP). SSL/TLS can secure the HTTP layer, creating HTTPS, which means SOAP can also run over SSL (SSL + SOAP). SAML is an XML-based authentication/authorization framework that can be used alongside SOAP-based services. Protocol layering allows these combinations.

Administrative pages offer highly privileged access and must be protected with strong multi-factor (2/3 factor) authentication to secure them against credential harvesting. Simple single-factor passwords, basic HTTP authentication, or disabling account lockouts introduce severe vulnerabilities, leaving administrative interfaces exposed to brute-force and credential stuffing attacks.

Session scope stores data that persists across multiple requests from the same user session, making it specific to that user. Page scope is for a single page, request scope lasts only for one HTTP request, and application scope is shared across all users and sessions. Session data typically includes user identity, shopping cart contents, or preferences.

SOAP is fundamentally stateless - each SOAP message contains all necessary information and doesn't rely on previous messages in the conversation. The protocol itself doesn't maintain session state between requests. Any stateful behavior must be implemented at the application layer using mechanisms like session IDs or tokens, not built into SOAP.

The key technical difference is where parameters are transmitted: GET sends data in the URL query string (visible in browser history and logs), while POST sends data in the request body (not visible in URL). GET requests should be idempotent and safe, while POST can modify server state. Both can be manipulated by attackers - option B is incorrect.

Detailed error messages like stack traces should be logged securely on the server for debugging, while users receive generic error messages. Storing sensitive debugging info in hidden fields (option A) exposes it to anyone viewing the page source. Simply destroying the information (option B) loses valuable debugging data needed to fix the underlying problem.

WSDL (Web Services Description Language) describes the service interface, SOAP (Simple Object Access Protocol) is the messaging protocol, and SAML (Security Assertion Markup Language) handles authentication/authorization in web services. Together these form a comprehensive web services stack: messaging (SOAP), description (WSDL), and security (SAML). WADL is for REST services, not SOAP.

Individual user accounts provide proper accountability by linking every action to a specific person. Shared accounts (groups or business units) make it impossible to determine who performed an action when multiple people share credentials. Security principle: one person, one account. This supports audit trails, non-repudiation, and access control.

A backdoor is a hidden method that bypasses normal authentication to gain unauthorized access. Option C correctly defines it as a security loophole using secret tokens or identifiers. Options A, B, and D describe legitimate features or connections, not security bypass mechanisms.

Hardcoded credentials that bypass normal authentication are a backdoor because they provide secret access without legitimate credentials. This is different from access control vulnerabilities (B) which are flaws in permission logic. Buffer overflow (C) and SQL injection (D) are completely different vulnerability types involving memory corruption and query manipulation.

90 days is traditionally recommended as the maximum interval for forced password changes in many security policies. Shorter intervals like 60 days may cause users to choose weaker passwords or write them down. Longer intervals like 180 days increase exposure time if passwords are compromised.

HTML comments can reveal sensitive information like server versions, file paths, developer names, or debug instructions that help attackers. Comments are sent to the client and visible in view source. Good practice (A) would be removing them before production deployment.

Web servers ship with default settings optimized for ease of use, not security. They often have unnecessary services enabled, default credentials, or verbose error messages. Options A, B, and C are incorrect because servers require deliberate hardening after installation to be secure.