Information Security

Parameterized queries separate SQL logic from data, preventing injection by treating user input as literal values not executable code. SSL/TLS (A) encrypts transmission but doesnt stop injection. URL/HTML encoding (B) mitigates XSS, not SQLi. Directory restrictions (D) address information disclosure, not injection. Parameterized queries (also called prepared statements) are the primary defense.

Spiders, robots, and crawlers automate information gathering by traversing websites and cataloging content, links, and structure. This reconnaissance phase identifies targets, technologies, and potential vulnerabilities. Authentication (A) and authorization (D) testing focus on access controls. Session management (B) concerns maintaining user state. These tools primarily enable discovery and mapping.

CAPTCHAs specifically resist automated solving by design - they test humanity. Fuzzers like WebScarab send massive automated requests but cannot interpret visual/audio challenges meant for humans. Fuzzers can discover files (A), test lockout limits (B), and attempt passwords (C). CAPTCHA breaking requires human interaction or specialized AI, not simple request automation, making it unsuitable for fuzzing tools.

RSA encryption is named after its inventors: Ron Rivest, Adi Shamir, and Leonard Adleman. Option C correctly identifies these three cryptographers who developed this public-key cryptosystem.

The principle of least privilege means granting only the minimum necessary access. Option C correctly states this: define exactly what each role CAN do, deny everything else by default. Group-based access (A) is an implementation detail, not the principle itself. Consistent checking (B) is about execution, not privilege assignment. Logging failures (D) is auditing, not the principle itself.

TCS Security API is the TCS security library used for remediation of security vulnerabilities found during assessments. The other options (B, C, D) are plausible variations but not the correct product name.

Cross Site Scripting (XSS) attacks target the client's browser by injecting malicious scripts that execute in the victim's browser context. The attack exploits the browser's trust in content from a vulnerable website, not the server, database, or web application itself.

The Secure cookie flag ensures cookies are only transmitted over encrypted HTTPS connections, preventing their interception over insecure HTTP channels. The Domain flag specifies cookie scope, Expires sets cookie lifetime, and Static is not a valid cookie attribute.

The primary risk of XSS is user compromise - attackers can steal session cookies, credentials, or perform actions on behalf of victims. While data integrity and destruction are potential consequences, the core threat is compromising user accounts and sessions through script injection.

Administrator accounts require stronger authentication than normal users because they have elevated privileges that can cause greater damage if compromised. Trust assumptions are security vulnerabilities - admins must face stricter access controls.

Hard coding credentials means embedding passwords or API keys directly in source code, which is a serious security vulnerability. Credentials exposed in code can be easily discovered through version control history, decompilation, or unauthorized access to the repository. Options B, C, and D are incorrect because hardcoding credentials is never secure, regardless of application type or intended audience.

Cross-Site Scripting (XSS) attacks occur when an attacker injects malicious scripts into content from a seemingly trusted source, like a compromised link or reflected input. The script executes in the victim's browser context. Buffer overflows and command injection are different vulnerability classes that don't involve malicious links.

The most secure response to invalid input is complete rejection (option D) because sanitization (escaping or deleting characters) can be bypassed and attackers might craft malicious payloads that survive filtering. Simply accepting invalid input (B) is dangerous, and partial processing after modification (A, C) risks introducing vulnerabilities.

Salting (adding random data before hashing) prevents dictionary and rainbow table attacks by ensuring identical passwords produce different hashes. Hashing twice (A) adds negligible security. Private key encryption (B) isn't applicable to password storage. Custom encryption (C) violates Kerckhoffs's principle and is rarely secure.

Hard-coded IP access control is fundamentally insecure because IP addresses can be spoofed, are dynamic (especially for ISPs), and create inflexible, brittle security. Option D correctly identifies this as bad practice. Internal IPs (A) and IP conflicts (B) aren't the core issues.