1

Let's say that an attacker wants to search websites for RFI/LFI vulnerability with a script, he's fuzzing the URL with a list of remote/local files. And he prints the headers that return from the request. How can the attacker know when the RFI/LFI was successful?

Is the content-length header can tell us something?

If RFI/LFI does not work on one (valid) file, does that mean there is no chance of this attack at all? Or can I keep trying other files?

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • Usually, attacks include some kind of a test to determine if it was successful. What that test is will depend on the application being tested. – schroeder Jul 25 '20 at 20:20

2 Answers2

1

Is the content-length header can tell us something ?

It may depend on the particular server and application. In many cases, the HTTP response will contain the contents of the requested file itself, or the output of executing it. So usually, you'd just confirm that a file was returned.

If the content length for an invalid file is 0, and a valid file is > 0, then that could work. I don't know if it would be that cut and dry, however, but maybe you can identify a baseline value vs a valid file hit. But maybe instead the particular application instead returns an HTTP 500 code if the file is invalid. It's probably good to try files that you know exist, so you can calibrate the expected response based on how the server responds.

If RFI/LFI does not work on one (valid) file, does that mean there is no chance of this attack at all?

Depends how you define "valid". If the file exists but you do not have permission to read it, then you will probably get a negative response. There also may be path filtering or a forced file extension; in these cases you may only be able to view certain files.

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • Sorry but I'm not so satisfied with the answer, I'd love for you to bring more headers that would hint to me that the attack did work. –  Jul 24 '20 at 16:00
  • 1
    @nakE well, that's the crux of it isn't it? LFI/RFI behavior is going to depend on the application code. It may have nothing at all to do with HTTP headers. – multithr3at3d Jul 24 '20 at 18:19
0

LFI/RFI is code execution attacks (due to the code being executed from insute the PHP include or require function calls. Thus you can make the code perform any action you can measure.

  • For remote file include you should be able to observe the incoming web request to the URL and get a shell.
  • For local file include you should get shell or print a specific string.

If by any chance you're confusing RFI/LFI with the SSRF/LFD bug classes then you can still tell by watching the incoming URL for SSRF or for LFD requesting a file with known content and look for that content in the response (f.ex /etc/passwd should match root:)

wireghoul
  • 5,745
  • 2
  • 17
  • 26