The SecOps Group secops-CAP 問題集 練習問題・模擬試験｜日本語版＆英語版対応

Explanation: Salting is a security technique used in password hashing to enhance protection against specific types of attacks. A salt is a random value added to a password before hashing, ensuring that even if two users have the same password, their hashed outputs will differ. The primary objective of salting is to defend against dictionary attacks and rainbow table attacks. Dictionary attacks involve trying common passwords from a precomputed list, while rainbow table attacks use precomputed tables of hash values to reverse-engineer passwords quickly. By adding a unique salt to each password, the hash becomes unique, rendering precomputed rainbow tables ineffective, as an attacker would need to generate a new table for each salt, which is computationally impractical. Option B ("To slow down the hash calculation process") is incorrect because while techniques like key stretching (e.g., using PBKDF2 or bcrypt) intentionally slow hashing to counter brute-force attacks, salting itself does not primarily aim to slow the process―it focuses on uniqueness. Option C ("To generate a long password hash that is difficult to crack") is a byproduct of salting but not the primary objective; the length and difficulty come from the hash function and salt combination, not salting alone. Option D ("To add a secret message to the password hash") is incorrect, as a salt is not a secret message but a random value, often stored alongside the hash. This aligns with best practices in authentication security, a key component of the CAP syllabus. Reference: SecOps Group CAP Documents - "Secure Coding Practices," "Authentication Security," and "Cryptographic Techniques" sections

Explanation: Clickjacking is an attack where a malicious site overlays a transparent iframe containing a legitimate site, tricking users into interacting with it unintentionally (e.g., clicking a button). The Content-Security-Policy (CSP) HTTP response header is used to mitigate various client-side attacks, including clickjacking, through specific directives. The frame-ancestors directive is the correct choice for preventing clickjacking. This directive specifies which origins are allowed to embed the webpage in an iframe, <frame>, or <object>. For example, setting frame-ancestors 'self' restricts framing to the same origin, effectively blocking external sites from embedding the page. This is a standard defense mechanism recommended by OWASP and other security frameworks. Option A ("script-src") controls the sources from which scripts can be loaded, addressing XSS (Cross-Site Scripting) vulnerabilities but not clickjacking. Option B ("object-src") restricts the sources of plugins or embedded objects (e.g., Flash), which is unrelated to iframe-based clickjacking. Option D ("base-uri") defines the base URL for relative URLs in the document, offering no protection against framing attacks. The use of CSP with the frame-ancestors directive is a critical topic in the CAP syllabus under "Security Headers" and "OWASP Top 10" (UI Redressing). Reference: SecOps Group CAP Documents - "Security Headers," "OWASP Top 10 (A07:2021 - Identification and Authentication Failures)," and "Client-Side Security" sections.

Explanation: Cross-Site Scripting (XSS) is a vulnerability that allows attackers to inject malicious scripts into web pages viewed by other users. These scripts execute in the context of the victim’s browser, enabling various exploitations. Let’s evaluate each option: Option A ("Steal the user's session identifier stored on a non HttpOnly cookie"): This is possible with XSS. If a session cookie is not marked as HttpOnly (preventing JavaScript access), an attacker can use a script to access document.cookie and steal the session ID, leading to session hijacking. Option B ("Steal the contents from the web page"): This is also possible. An XSS payload can manipulate the DOM, extract content (e.g., via innerHTML), and send it to the attacker, such as through a GET request to a malicious server. Option C ("Steal the contents from the application's database"): This is not possible with XSS alone. XSS operates on the client side within the browser’s sandbox and cannot directly access the server-side database. Database access requires server-side vulnerabilities (e.g., SQL injection), which is a separate attack vector. Thus, this exploitation is not feasible through XSS. Option D ("Steal the contents from the user's keystrokes using keyloggers"): This is possible. An XSS script can inject a keylogger (e.g., using onkeydown events) to capture keystrokes and transmit them to the attacker, especially on pages where sensitive data (e.g., forms) is entered. Therefore, the correct answer is C, as XSS cannot directly exploit the database. This distinction is crucial in understanding attack vectors, a core topic in the CAP syllabus under "OWASP Top 10 (A03:2021 - Injection)" and "XSS Mitigation." Reference: SecOps Group CAP Documents - "OWASP Top 10," "Cross-Site Scripting (XSS)," and "Client-Side Attack Vectors" sections.