known issue Direct attack on attachment URLs

[Thomas P]

Hi mates,

I am observing from the sytem log that we are experiencing attacks on single attachment URLs.
As it seems someone is hammering the attachment engine/URLs with random IDs:

The URLs itself look like this:

https://www.mcseboard.de/index.php?app=core&module=system&controller=ajax&do=attachmentInfo&attachIDs[14365]=true

Now what is bugging me is: Why are they hammering those attachment URLs and why do they do that as a guest user.
Case A: As guest an error is being thrown ("Sorry, there is a problem. Something went wrong. Please try again. Error code: EX0") in the frontend - thus the system log entry.

Case B: If a logged in user tries to reach such an URL the output of the a.m. one is:

Quote

{"14365":{"rotate":""}}

Not that isn't really exciting as a result or desirable output.

So I am wondering:

• why is this type of attachment URL being hammered?
  is there a known vulnerability or was there one in the past?
• what is the use of that URL, i.e. for what reason is the output presented to logged in users?
• and last not least:
  How to address it? Can those request be denied altogether?
  Or should I even bother as a valid error is presented to a guest user?

I ignored such pointless requests showing in the system log, but there are plenty of it.

Thanks,
Thomas

 

Edited February 21 by Thomas P

[Randy Calvert]

In the cases I've seen this happen, it's a search engine bot or another non-human/automated crawler that is trying to access it.  Someone most likely posted an attachment within a forum post that is not accessible to guests.  

You could block the IP addresses of the sources hitting your site, but the system is doing what it should...  it's not giving the actual content to people who should not have it.  You can't stop someone from ATTEMPTING to access it.  The software is already denying the attempt by what you see happening when a guest accesses it.  If you want to block it further up, that's a choice for you to make.  

[Marc Stridgen]

As mentioned, if you are bothered about it, you could block the IP if needed. Its very likely a crawler that is hitting these

[teraßyte]

@Marc Stridgen The error should still be fixed, though:

Call to undefined method IPS\core\extensions\core\EditorLocations\Contact::attachmentPermissionCheck()

 

Even if the ID being looked up doesn't exist, it shouldn't throw a PHP error but show a proper error page at least.

[Marc Stridgen]

16 hours ago, teraßyte said:

@Marc Stridgen The error should still be fixed, though:

Call to undefined method IPS\core\extensions\core\EditorLocations\Contact::attachmentPermissionCheck()

 

Even if the ID being looked up doesn't exist, it shouldn't throw a PHP error but show a proper error page at least.

Logged

[Thomas P]

Thanks guys, appreciated