1

In one of my PHP apps, I have a part where it scrapes the content of random links on the internet using file_get_contents, and then it runs a regex on this content to find all the email addresses in it. Now, these "links" it scrapes are generated by user preference.

I am sort of confused as to if it is secure or not. I mean, if a link turns out to be a malicious .exe file on the internet, and it scrapes the content, can it somehow harm my server? The script simply searches for emails found on those web pages and (at the moment) echoes them as output.

I'll shut my mouth up and give the code that actually does the web scraping and email filtering:

<?php

// Extracts emails from the linked sites.

if (isset($argv)) {
  $url = escapeshellarg($argv[1]);

  // fetch data from specified url
  $text = file_get_contents($url);

  // parse emails
  if (!empty($text)) {
    $res = preg_match_all(
      "/[a-z0-9]+([_\\.-][a-z0-9]+)*@([a-z0-9]+([\.-][a-z0-9]+)*)+\\.[a-z]{2,}/i",
      $text,
      $matches
    );

    if ($res) {
      foreach (array_unique($matches[0]) as $email) {
        echo $email . "<br />";
      }
    } else {
      echo "No emails found.";
    }
  }
}

// To run, type: php extract.php https://example.com/

Does this code make my server vulnerable? I am emphasizing the term "server" as I have taken proper measures when actually displaying the emails to the users, with htmlspecialchars, custom tag filters, etc.

6
  • I don't understand how this is a server? It looks like something you would run on your own machine locally, not something that responds to HTTP requests?
    – Anders
    Commented Dec 13, 2022 at 9:25
  • 1
    @Anders There is a separate file that the user visits, that file triggers this file to do the function. The code of that file is irrelevant as it does exactly what the "To run" example in my code does, but the "example.com" comes via user input. Commented Dec 13, 2022 at 9:29
  • By design your approach has server side request forgery (SSRF) as its intended feature. The other (irrelevant) script has the likely command injection vulnerability. Your regular expression is vulnerable to a denial of service condition, but PHP is special so if you're running in default config regular expressions aren't evaluated deeply and it likely won't matter.
    – wireghoul
    Commented Dec 14, 2022 at 3:55
  • @wireghoul I don't think it does, it properly uses escapeshellargs and those are unquoted in an irrelevant part of the script. Would it still have the command injection vulnerability? would it be okay If I edit in all my scripts or is it too late now? Commented Dec 14, 2022 at 6:51
  • In the above code you're escapeshelling an argument received to a script, that's the wrong place to do so, as it would execute after the command injection occurred. There is also the potential for argument injection as escapeshell doesn't prevent those. I wrote a blog about it a long time ago: baesystemsdetica.blogspot.com/2013/11/…
    – wireghoul
    Commented Dec 15, 2022 at 0:11

1 Answer 1

1

I don't think you need worry about an attacker pointing this tool to a malicious file. Even if used on an executable file, it will just search it for emails and not execute it. The risk here would be some kind of buffer overflow or exploit in the built in PHP functions, but if you take that into account any usage of PHP is unsafe.

What you need to think about instead is what information an attacker could gather using this tool. She might point it towards files on your machine, not on the internet, and thereby scan the local file system for email adresses. That sounds pretty useful to an attacker! She could also check what files exists or not, since the program will produce no output for a missing file. The solution here would be to make sure that $url is in fact an URL, and starts with http:// or https://.

Even doing that would not fully solve the problem, though. The attacker could still use this script to probe your local network. If you have a machine that is accessible on your local network from your server, but not from the internet, the attacker can use your tool to trick your server into sending request to the machine. This can be used to find out things about your IT environment, extract information, or anything that can be done with a GET request. The solution to this is to run all requests through a proxy that only has access to the internet and not your local network.

So while this might not be unsafe in the way you were worried about, it is still not a good thing to do without taking the precautions oulined above.

1
  • Hi, thanks for your answer. Thankfully, we already have a system that routes all the requests in a specific directory toward URLs that aren't on our own server. Regarding other precautions, I'll surely take them into consideration. I am in a bit of hurry right now so have to accept this answer (which is great of course), but if someone has an even better detailed answer, then I'd be happy to take a look at that later on. Commented Dec 13, 2022 at 9:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .