An application's forget password functionality is described below:
The user enters their email address and receives a message on the web page:
''If the email exists, we will email you a link to reset the password''
The user also receives an email saying:
''Please use the link below to create a new password:''
(Note that the developer has included a one-time random token with the 'userId' parameter in the link). So, the link seems like:
https://example.com/reset_password?userId=5298&token=70e7803e-bf53-45e1-8a3f-fb15da7de3a0
Will this mechanism prevent an attacker from resetting arbitrary users' passwords?
Correct : A
The password reset mechanism now includes a one-time random token alongside the userId in the reset link: https://example.com/reset_password?userId=5298&token=70e7803e-bf53-45e1-8a3f-fb15da7de3a0. Let's evaluate the effectiveness of this mechanism:
Analysis: The inclusion of a one-time random token (e.g., 70e7803e-bf53-45e1-8a3f-fb15da7de3a0) is a best practice for secure password reset mechanisms. This token should be unique, unpredictable, and tied to the specific user's reset request (e.g., stored in the database with an expiration time). When the user clicks the link, the application should verify that the token matches the one associated with the userId and that it hasn't been used or expired.
Preventing Arbitrary Resets: Without the token, an attacker could manipulate the userId (e.g., to 5299) to reset another user's password (as seen in Question 45). However, with the token, the attacker would need to guess the correct token for the targeted userId, which is computationally infeasible if the token is sufficiently random (e.g., a UUID or cryptographically secure random string) and properly validated. This prevents unauthorized password resets.
Additional Considerations: The link uses https://, ensuring a secure channel (unlike Question 45). The message 'If the email exists...' prevents username enumeration, as discussed previously.
Option A ('True'): Correct, as the one-time random token, if implemented correctly (e.g., validated server-side, single-use, time-limited), prevents an attacker from resetting arbitrary users' passwords.
Option B ('False'): Incorrect, as the mechanism is secure with the token.
The correct answer is A, aligning with the CAP syllabus under 'Secure Password Reset' and 'Token-Based Authentication.'
Start a Discussions
Which of the following hashing algorithms is considered to be the most secure amongst these?
Correct : D
Hashing algorithms are used to securely store passwords by transforming them into fixed-length strings. A secure hashing algorithm for passwords should be resistant to collision attacks, preimage attacks, and brute-force attempts, and should be slow to compute to deter attackers. Let's evaluate the options:
Option A ('SHA-0'): SHA-0 is the original version of the SHA family, published in 1993, but it was quickly withdrawn due to serious cryptographic weaknesses (e.g., collision vulnerabilities). It is not secure and should not be used.
Option B ('MD5'): MD5 is a widely used hash function but is cryptographically broken. It is vulnerable to collision attacks (e.g., practical attacks demonstrated since 2004) and is extremely fast, making it unsuitable for password hashing as it can be brute-forced easily.
Option C ('SHA-1'): SHA-1, part of the SHA family, is also considered broken for security purposes. It has known collision vulnerabilities (e.g., the SHAttered attack in 2017 demonstrated practical collisions), and like MD5, it is too fast for secure password hashing.
Option D ('Bcrypt'): Bcrypt is specifically designed for password hashing. It is a slow hashing algorithm with a configurable work factor (cost factor), making it resistant to brute-force attacks. It also includes a built-in salt to prevent rainbow table attacks. Bcrypt is widely recommended by security standards (e.g., OWASP, NIST) for secure password storage and is the most secure option among those listed.
The correct answer is D, aligning with the CAP syllabus under 'Password Hashing' and 'Cryptographic Best Practices.'
Start a Discussions
Which of the following is NOT an asymmetric key encryption algorithm?
Correct : A
Asymmetric key encryption (also known as public-key cryptography) uses a pair of keys: a public key for encryption and a private key for decryption (or vice versa for signing). Symmetric key encryption, on the other hand, uses the same key for both encryption and decryption. Let's evaluate the options:
Option A ('AES'): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, making it a symmetric algorithm, not an asymmetric one.
Option B ('RSA'): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt data and a private key to decrypt it, making it a classic example of asymmetric cryptography.
Option C ('Diffie-Hellman'): Diffie-Hellman is an asymmetric key exchange algorithm. While it is primarily used for key exchange rather than direct encryption, it relies on asymmetric principles (public and private keys) to securely establish a shared secret, so it is considered part of asymmetric cryptography.
Option D ('DSA'): DSA (Digital Signature Algorithm) is an asymmetric algorithm used for digital signatures. It uses a pair of keys (public and private) for signing and verification, making it an asymmetric algorithm.
The correct answer is A, as AES is the only symmetric algorithm listed, aligning with the CAP syllabus under 'Cryptography Fundamentals' and 'Symmetric vs. Asymmetric Encryption.'
Start a Discussions
Which of the following is NOT a symmetric key encryption algorithm?
Correct : D
Symmetric key encryption algorithms use the same key for both encryption and decryption, while asymmetric algorithms use a pair of keys (public and private). Let's evaluate the options:
Option A ('RC4'): RC4 is a symmetric key encryption algorithm. It is a stream cipher that uses a single key to both encrypt and decrypt data, though it is considered insecure due to known cryptographic weaknesses (e.g., biases in the keystream).
Option B ('AES'): AES (Advanced Encryption Standard) is a symmetric key encryption algorithm. It uses a single key (e.g., 128, 192, or 256 bits) for both encryption and decryption, widely regarded as secure when properly implemented.
Option C ('DES'): DES (Data Encryption Standard) is a symmetric key encryption algorithm. It uses a 56-bit key for both encryption and decryption, but it is now considered insecure due to its small key size and vulnerability to brute-force attacks.
Option D ('RSA'): RSA (Rivest-Shamir-Adleman) is an asymmetric key encryption algorithm. It uses a public key to encrypt and a private key to decrypt, making it an asymmetric algorithm, not a symmetric one.
The correct answer is D, as RSA is the only asymmetric algorithm listed, aligning with the CAP syllabus under 'Cryptography Fundamentals' and 'Symmetric vs. Asymmetric Encryption.'
Start a Discussions
In the screenshot below, an attacker is attempting to exploit which vulnerability?
Request
POST /dashboard/userdata HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) Firefox/107.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Cookie: JSESSIONID=7576572ce167b5634ie646de967c759643d53031
Te: trailers
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 36
useragent=http://127.0.0.1/admin
Pretty Raw | Hex | php | curl | ln | Pretty
HTTP/1.1 200 OK
Date: Fri, 09 Dec 2022 11:42:27 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 12746
Connection: keep-alive
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Request-ID: 65403d71e8745d5e1fe205f44d531
Content-Length: 12746
Admin Panel
Correct : D
The request is a POST to /dashboard/userdata with a parameter useragent=http://127.0.0.1/admin. The response is a 200 OK with an HTML page titled 'Admin Panel,' suggesting the server processed the request and returned content from http://127.0.0.1/admin. Let's evaluate the vulnerability:
Analysis: The useragent parameter contains a URL (http://127.0.0.1/admin), and the server appears to fetch content from this URL, as indicated by the response containing the 'Admin Panel' page. The URL 127.0.0.1 refers to the server's localhost, meaning the server is making an internal request to itself based on user input. This is a hallmark of Server-Side Request Forgery (SSRF), where an attacker can trick the server into making requests to arbitrary locations, including internal systems (e.g., 127.0.0.1) or external sites. SSRF can lead to accessing internal resources (e.g., admin panels, metadata endpoints) or performing unauthorized actions.
Option A ('HTTP Desync Attack'): HTTP Desync attacks exploit discrepancies in how front-end and back-end servers interpret HTTP requests (e.g., smuggling requests). This scenario involves a straightforward POST request with no evidence of desynchronization or smuggling, so this is incorrect.
Option B ('File Path Traversal Attack'): File Path Traversal involves manipulating file paths (e.g., ../../etc/passwd) to access unauthorized files on the server's filesystem. The useragent parameter contains a URL, not a file path, and the response indicates a web request, not filesystem access, so this is incorrect.
Option C ('Open URL Redirection'): Open URL Redirection occurs when the server redirects the client to a user-supplied URL (e.g., via a Location header). The response here is a 200 OK, not a redirect (e.g., 302 Found), and the server is fetching content server-side, not redirecting the client, so this is incorrect.
Option D ('Server-Side Request Forgery'): Correct, as the server is making a request to http://127.0.0.1/admin based on the useragent parameter, indicating an SSRF vulnerability.
The correct answer is D, aligning with the CAP syllabus under 'Server-Side Request Forgery (SSRF)' and 'OWASP Top 10 (A10:2021 - Server-Side Request Forgery).'
Start a Discussions