A penetration tester is reviewing source code and wants to identify common hardcoded credentials and input validation gaps. Which three checks should the tester perform? (Choose THREE.)

Check for proper session timeout implementation

PT0-002 Vulnerability Discovery and Analysis Practice Question

Correct answer & explanation

✓

Identify usage of eval, exec, or system with user input

Hardcoded credentials, concatenated SQL queries, and dangerous functions like eval/exec/system are common vulnerabilities.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
Verify the use of HTTPS
Why it's wrong here
HTTPS verification is a transport-layer control that protects data in transit but does not reveal application-layer flaws in source code. The session's confidentiality relies on the server or proxy configuration and TLS termination, which are rarely visible in the application's code itself. Even with HTTPS enforced, injection vulnerabilities and hardcoded secrets remain fully exploitable, so this check would not satisfy the goal of identifying credential misuse or unsafe input handling.
✓
Identify usage of eval, exec, or system with user input
Why this is correct
Functions such as eval(), exec(), system(), and shell_exec() are extremely dangerous when they incorporate user-controlled data because they allow arbitrary code or OS commands to be executed. In a source review, you must trace every input that flows into these call sites, verify that proper allowlisting or input sanitization is in place, and consider replacing them with safer APIs. A single unguarded call can enable full command injection, making this a primary target for manual security review.
✓
Search for hardcoded passwords or API keys
Why this is correct
Hardcoded credentials like database passwords, API keys, or secret tokens embedded in the code are critical findings because they are often exposed through version control repositories, build logs, or code-sharing platforms. An analyst should scan for regular expressions matching assignment patterns (e.g., 'password', 'apiKey', 'secret') and then check if the values are real secrets versus placeholders. Any discovered secret must be rotated immediately and migrated to a secrets manager or environment variable to prevent unauthorized access.
✓
Look for SQL queries constructed with string concatenation
Why this is correct
SQL queries built by concatenating strings with parameters from HTTP requests or other user inputs are a classic SQL injection vector. The review should locate every occurrence of string concatenation, string formatting like sprintf(), or inline query construction and verify whether the values are safely parameterized. If dynamic SQL is unavoidable, the best defense is a parametrized query or prepared statement, ensuring the database engine treats input as data, not executable code.
✗
Check for proper session timeout implementation
Why it's wrong here
Session timeout enforcement is a session management control, not a code-level check for credential exposure or unsafe input handling. While a missing timeout can increase risk of session hijacking, it does not directly address hardcoded secrets, injection vectors, or unsafe function calls that this review intends to find. Moreover, timeout values are frequently configured in application properties or server settings, making them less discoverable and less relevant when focusing on source code patterns for injection and credential leaks.

PT0-002 Vulnerability Discovery and Analysis Practice Question

Why each option matters

Option-by-option breakdown

Related to this question