Okay, this is a silly section… Unpredictable IDs can’t, well, be predicted. You can still see if you have an IDOR by creating two accounts, performing some actions in parallel, and then seeing if you can view resources from one account while logged in as another. This process can help you determine if a system has an IDOR vulnerability, but unfortunately doesn’t really help you get at any information using it.
Also check API endpoints, and see if those endpoints accept additional (undocumented) parameters that allow you to access information beyond your normal scope.
Burp Suite is, as usual, pretty useful for uncovering API endpoint activity. I honestly find it more intuitive to work with for this purpose than the actual browser developer tools.
Basically, if an application is including a file based on some user-defined input, then there may be an opportunity to trick it into including a malicious file, or a system file we shouldn’t have access to.
The trick here is that you can’t be including your file in a fashion that would trigger your browser to request it, since that will be limited by what can be represented as a URL for the application. Rather, you need to find a parameter that specifies a file the application will incorporate directly into the page data being pushed to the browser.
File inclusion vulnerabilities are a species of input validation errors.
“Path traversal” and “directory traversal” are the same thing. This is about using LFI to access system files; this often occurs when improperly sanitized user input is passed to PHP’s
Common files to check:
C:\boot.ini- boot options on Windows systems)
Windows systems are also vulnerable to LFI attacks via PHP. In fact,
file_get_contents() will happily use UNIX slashes on Windows.
More potentially hazardous PHP functions:
LFI is also common in ASP, JSP, and Node.js apps.
Remember that PHP terminates strings with the null byte (
0x00). This can be passed in as
%00, though this will often need to be URL-encoded as
%2500. The use of the poison null byte allows us to bypass file inclusion that appends extensions or other information to the string we’re passing, by causing string parsing to halt before it reaches the appended information. The poison null byte can also be used to bypass simple keyword filters.
Unfortunately, the poison null byte only works in PHP < 5.3.4.
If the poison null byte doesn’t work, another trick relies on the fact that for some bizarre reason PHP allows files to be referenced with
. notation just like directories. In other words,
/etc/passwd/. will return the contents of
....// can bypass filters that replace
../, as PHP search-and-replace only does a single pass through a string (it should be obvious how to extend this if a developer tries to just run a search and replace twice).
Remote file inclusion only works when PHP’s
allow_url_fopen option to be turned on. If
allow_url_include is also on, then
require() functions (and friends) can be leveraged. This creates a vulnerability similar to the recent log4j vulnerability in Java, where arbitrary code can be passed into the application. RCE!
Remember that form requests sent via POST need to have
Also, remember to add in an appropriate