Question 1
You see a PHP app that includes files like include($_GET['page']);
. Which HTTP request is most likely to reveal an LFI vulnerability while minimizing noise in logs?
GET /index.php?page=../../../../etc/passwd
GET /index.php?page=%2e%2e%2f%2e%2e%2fetc/passwd
GET /index.php?page=php://filter/convert.base64-encode/resource=../config.php
POST /index.php { "page": "../../../../etc/passwd" }
Question 2
An LFI exists but allow_url_include
is disabled and you can’t write files. Which technique is the most realistic path to remote code execution (RCE)?
Include /etc/passwd
and use /proc/self/environ
to inject PHP with a User-Agent header.
Use file_put_contents()
via the include parameter to write a PHP file.
FTP upload a webshell and include it directly.
Use data:
URI with include('data://text/plain;base64,PD9waHAgZWNobyAnYSc7')
.
Question 3
Which single change gives the strongest immediate protection against typical LFI attacks in a PHP app that uses include($page)
?
Disable display_errors
in php.ini.
Use a whitelist mapping of allowed page keys to filenames.
Set open_basedir
to /var/www/html
.
URL-encode all user input before inclusion.
Question 4
You suspect a Broken Access Control bug where normal users can access admin-only data via a direct URL. Which test is most likely to confirm this without authentication brute force?
Try GET /admin/dashboard
and check for 302 redirect to login.
Modify an existing resource ID in the URL from id=123
to id=124
and check response codes.
Attempt login with admin credentials and compare response body.
Use SQL injection on the id parameter to list tables.
Question 5
An API uses JWT tokens and the server does not validate the alg
header properly. Which exploit is most likely?
Reuse expired token - server will accept because JWTs are stateless.
Change alg
to none
and remove signature — server accepts token.
Rotate the token key on client side and sign with new key.
Send token as cookie instead of Authorization header.
Question 6
Which practice most reduces the chance of object-level Broken Access Control (IDOR) across a large codebase?
Add is_admin
flags to client-side UI checks.
Enforce server-side authorization checks based on resource ownership in a centralized middleware.
Obfuscate IDs with client-side hashing.
Rely on obscure, unguessable UUIDs for resource IDs only.
Question 7
Server-side, centralized authorization is the robust approach. Client-side checks or obscurity (D) are weak. UUIDs help but don’t replace proper checks.
The web server has file descriptors exposed — check application logs.
phpinfo()
was enabled — check phpinfo output.
The process is running as root - check /etc/passwd.
STDIN was readable — check access logs and the last request headers (access.log).
Question 8
Which combination of controls most effectively addresses both LFI and Broken Access Control risks?
Server-side authorization, whitelist includes, and least-privilege file permissions.
Web Application Firewall + disable directory listing.
Input validation + output encoding.
Parameterized queries + TLS.
Question 9
An LFI vulnerability returns base64 content for included files. You find an uploaded image avatar.jpg
in /uploads/
and include it via LFI; base64 decodes to binary but contains embedded PHP code. Which attack vector is most likely being attempted?
PHP code disguised in image - trying to get the app to execute it via LFI (image-then-include attack)
SQL injection via image headers
Cross-site scripting through EXIF data
Directory traversal into /etc/shadow
Question 10
Your organization detected multiple IDOR findings in a product. What is the best first change to the development lifecycle to prevent future regressions?
Add OWASP Top 10 training for devs.
Hire more security engineers to manually review every PR.
Block public access to the application until fixed.
Add automated authorization tests (unit/integration) and include them in CI.
There are 10 questions to complete.