Web Application Security Fundamentals

Cross-Site Scripting (XSS) attacks inject malicious scripts into web pages viewed by other users. The attacker crafts a malicious link that appears to come from a trusted source (the vulnerable website), and when victims click it, the script executes in their browsers with the site's permissions. Buffer overflows (B), command injection (C), and path traversal (D) are different vulnerability classes.

Blacklist validation is weak because attackers can bypass it using various character encoding techniques: URL encoding, Unicode encoding, hex encoding, double-encoding, mixed encoding, and case variation. It's impossible to enumerate every possible malicious pattern. Options A and C are incorrect - the issue isn't about hard-coding or POST methods. Option D describes whitelist validation, not blacklist.

When input validation fails, the most secure response is to completely reject the input and return an error to the user. Options A (escape), B (accept and log), and C (delete) all continue processing potentially malicious data, which can lead to security vulnerabilities. Rejection prevents any chance of the attacker bypassing validation through edge cases or encoding tricks. Never try to fix invalid input - reject it entirely.

Buffer overflow occurs when a program writes more data to a buffer (variable) than the space allocated for it, overflowing into adjacent memory. This is a variable-level issue, not a system-wide RAM problem (B). Options A and C are too vague about memory allocation. The vulnerability exists because the program doesn't check input size against the variable's allocated size before writing, allowing attackers to overwrite adjacent memory and potentially control execution flow.

Directory traversal (also called path traversal) attacks manipulate URL parameters to access files outside the web document root. Attackers use sequences like '../' to navigate the filesystem and read or execute arbitrary files. Options A (XSS), B (SQL injection), and C (command injection) are different vulnerabilities. Directory traversal specifically targets file system access through path manipulation.

In a GET request, the query string (the part after '?' in the URL) is logged by web servers. This is standard behavior for access logs. Hidden tags (A) are in HTML forms, not URLs. Headers (C) and cookies (D) are sent in the HTTP request but are not part of the URL itself, though servers can optionally log them. The query string is always visible in server logs by default.

Salting adds unique random data to each password before hashing, which renders precomputed dictionary or rainbow table attacks ineffective since each hash must be cracked individually. Double hashing doesn't prevent dictionary attacks (it just adds computational cost), encrypting with private key is not how password storage works, and 'secret algorithms' (security by obscurity) is a dangerous practice.

To solve this question, the user needs to have a basic understanding of access control and network security.

Option A: Can be done as it is an internal IP

• This option is partially correct. Implementing access control based on a hard-coded IP address can be done for internal IPs, since they are less likely to change or conflict with other IPs on the network. However, this alone does not guarantee security, and other measures such as firewalls and intrusion detection systems should also be in place.

Option B: Can be done for internet-facing servers as there are no chances of IP conflicts

• This option is incorrect. Even for internet-facing servers, there are chances of IP conflicts, especially if the server is part of a larger network. Relying solely on hard-coded IP addresses for access control is not a good security practice.

Option C: Is a good security practice

• This option is incorrect. While hard-coding IP addresses for access control can be part of a larger security strategy, it is not a good practice to rely solely on this method. Attackers can spoof IP addresses or gain access to a trusted IP address through various means. A more comprehensive security approach is needed.

Option D: Is a bad security practice

• This option is partially correct. Relying solely on hard-coded IP addresses for access control is not a good security practice, as it is vulnerable to spoofing and other attacks. However, this does not mean that the practice is completely bad. It can be used in conjunction with other security measures, but should not be the only method of access control.

Therefore, the correct answer is:

The Answer is: D. Is a bad security practice

Temporary files in the web root are a security risk - attackers can guess their location or find them through directory traversal. Even without direct links or with renamed extensions, files in web-accessible directories can be discovered and downloaded. The only safe practice is to remove temporary files completely or store them outside the web document root.

CD-Rs provide write-once, read-many storage that creates tamper-evident audit trails - once burned, they cannot be modified without detection. Paper logs are impractical for digital systems, local copies lack disaster recovery, and CD-Rs were historically preferred for secure offsite backup. Modern alternatives like WORM storage or cloud with immutable retention serve the same purpose.

These major security vulnerabilities all stem from accepting untrusted user inputs without proper sanitization, validation, or escaping. Proper input validation mitigates the risk of execution or injection.

Configuration Management Security principles - version control, change approval, separation of duties, audit trails, and rollback procedures - apply universally across all software types. Whether commercial off-the-shelf, custom-built, or developed in-house, all applications require secure configuration management to prevent unauthorized changes and maintain system integrity.

In asymmetric cryptography, the public key is designed for distribution and encryption - revealing it doesn't compromise security. Encrypted data itself can be public without weakening the encryption. However, revealing the private key (asymmetric) or symmetric key would allow decryption, breaking confidentiality entirely.

Data validation (input whitelisting, type checking, length limits) is the primary defense against SQL injection - it ensures only expected input reaches the database. Secure cookies prevent theft but not injection, encryption protects data at rest (not query manipulation), and exception handling manages errors rather than preventing injection itself.

Only the Session ID should be stored in a cookie - it's an opaque reference to server-side session data. Storing privileges, username, or especially passwords in cookies exposes sensitive information to theft (XSS, sniffing, physical access) and violates the principle of storing only identifiers, not authoritative data, on the client.

Data hashing creates a fixed-size fingerprint that detects tampering - if even one bit changes, the hash will be completely different. Hashing doesn't validate sessions (that's session management), doesn't validate users (that's authentication), and 'all of the above' is incorrect because hashing only addresses integrity, not authenticity or authorization.

CRLF (%00%0A = Carriage Return + Line Feed) injection allows attackers to split HTTP responses by injecting malicious headers or content. This technique (HTTP Response Splitting) can lead to cache poisoning, XSS, or credential theft. XSS attacks inject scripts (not CRLF), phishing is social engineering, and SQL injection targets databases (not HTTP responses).

White-box testing (also called glass-box or clear-box) examines internal program structures, code, logic flows, and algorithms. Black-box testing treats software as a opaque box, testing only inputs and outputs without seeing internal code. The color refers to visibility - white means you can see inside, black means you cannot.

Scanning source code with regex patterns to identify suspicious functions, inputs, or outputs is inherently a white-box testing technique - it requires access to and analysis of internal code. Black-box testing examines only external behavior without code access, and gray-box testing combines partial internal knowledge with external testing.

A vulnerability assessment identifies and categorizes vulnerabilities without exploiting them - it's an inventory and risk evaluation. A penetration test actively exploits vulnerabilities to demonstrate impact and test defenses. They're complementary: assessment finds the weaknesses, penetration testing proves they're exploitable and measures real-world risk.