PHP Risk Assessment & Management 5 — Questions and Answers
Question 1: Which PHP function should replace file_get_contents() when fetching user-supplied URLs to prevent SSRF (Server-Side Request Forgery)?
- There is no drop-in replacement; input must be validated against an allowlist of permitted hosts (Correct answer)
- curl_init() with CURLOPT_FOLLOWLOCATION disabled
- fopen() with the b flag
- stream_get_contents() with a timeout
Correct answer: There is no drop-in replacement; input must be validated against an allowlist of permitted hosts
SSRF prevention requires validating and allowlisting target URLs before any HTTP client is used, not just switching the HTTP function.
Question 2: A risk register entry notes that a PHP application writes user-supplied data directly to a log file. What attack does this enable?
- Log injection, potentially forging log entries or enabling log poisoning for LFI exploitation (Correct answer)
- SQL injection through log queries
- Path traversal via the log filename
- CSRF through log viewing interface
Correct answer: Log injection, potentially forging log entries or enabling log poisoning for LFI exploitation
Unescaped newlines in user input can forge log entries, and if logs are later included as PHP files, this escalates to remote code execution.
Question 3: What is the risk when a PHP application compares user passwords with the == operator instead of password_verify()?
- Type juggling may cause '0e...' hash strings to compare as equal due to PHP's loose comparison (Correct answer)
- password_verify() is slower and causes denial of service
- == performs a byte-for-byte comparison that is more secure
- The risk is only theoretical and has no practical exploit
Correct answer: Type juggling may cause '0e...' hash strings to compare as equal due to PHP's loose comparison
PHP's == operator treats strings beginning with '0e' as scientific notation floats; two different hashes can evaluate as equal, bypassing authentication.
Question 4: During a PHP application risk assessment, you find that error_log points to a file inside the web root. What is the risk?
- An attacker can request the log file and read error details including file paths and SQL queries (Correct answer)
- The log file blocks write access to the application
- Error logging causes PHP to crash on high traffic
- Log rotation will delete the web root
Correct answer: An attacker can request the log file and read error details including file paths and SQL queries
A log file in the web root is publicly accessible via HTTP, leaking sensitive internal details that aid further attacks.
Question 5: What residual risk remains after patching a known SQL injection vulnerability in PHP code if the database backup strategy is not addressed?
- Data loss risk persists because historic exploits may have exfiltrated or corrupted data before the patch (Correct answer)
- No residual risk remains once the code is patched
- The patch reintroduces CSRF vulnerabilities in the same code path
- Performance risk from parameterized queries
Correct answer: Data loss risk persists because historic exploits may have exfiltrated or corrupted data before the patch
Fixing the injection vector does not undo any data theft or corruption that occurred prior to patching, so data integrity and backup recovery must also be assessed.
Question 6: Which PHP security mechanism helps mitigate risk from path traversal attacks when reading files based on user input?
- Using realpath() to resolve the canonical path and verify it starts with an approved base directory (Correct answer)
- Using dirname() on the input string
- Calling file_exists() before reading
- Setting open_basedir to the web root
Correct answer: Using realpath() to resolve the canonical path and verify it starts with an approved base directory
realpath() resolves ../ sequences to the true path; comparing that against an allowed base directory prevents traversal outside the intended directory.
Question 7: A PHP risk assessment flags that the application uses outdated third-party libraries with no update process. Which risk treatment approach directly addresses this?
- Establish a dependency management policy with regular composer update cycles and automated vulnerability scanning (Correct answer)
- Switch all external libraries to home-grown implementations
- Accept the risk because updating may break existing features
- Mitigate by adding a WAF in front of all endpoints
Correct answer: Establish a dependency management policy with regular composer update cycles and automated vulnerability scanning
A formal patch management process with automated scanning (e.g., composer audit in CI) reduces the window of exposure to known library vulnerabilities.
PHP Risk Assessment & Management 5
Which PHP function should replace file_get_contents() when fetching user-supplied URLs to prevent SSRF (Server-Side Request Forgery)?