Best way to handle tons of "hacking attempts" that generates 404

@Sinnbeck Hackers are more clever than that ...

Last browsers used:

BLEXBot 1.0
CFNetwork
Chrome 106.0.0
Chrome 34.0.1866
Chrome 39.0.2171
Chrome 78.0.3904
Chrome 81.0.4044
Chrome 86.0.4240
Chrome 88.0.4240
Chrome 89.0.4389
Chrome 90.0.4430
Chrome 95.0.4638
IE 11.0
Other
Python Requests 2.27
curl 7.3.2

@skater yeah it's tricky to get zero false positives. It was to filter at least some. Another idea is to embed Javascript into the page that triggers the logger endpoint. This should filter those not reading Javascript

Or worst case add a button "report broken link"

@Sinnbeck I think you didn't understand the question. My problem is not detect a broken link (no need to add a button).

My problem is to handle all false positives 404 that are really hacking attempts. And it's a problem because I have a component that alerts me any 404 happening in the page (since it's very important to know where and when it's a 404 to solve it asap)

@skater is it because you want a different handler for 404 caused by urls that doesn't match anything? If that's the case, add this at the bottom of the web.php

Route::fallback(function () {
    return 'piss off hacker';
});

@Sinnbeck with that fallback, if my content manager fails in some content and wrote an incorrect link, I will never notice it

@skater yeah if it's not just due to a wrong ID. In that case trying to filter false positives is the best idea. For that I suggested 2 ideas.

@kokoshneta Thank you !

Wordpress is about 20% of all requests ... I have a list of about 650 different requests of hacking attempts ... My question is about what is the BEST way to handle this ... is creating a 650 rules set the best ?

@skater Perhaps you can whitelist your own URLs that should be notified. Assuming that they all start with some recognisable pattern.

The other option is to use cloudflare. Let them filter the known test urls.

@Snapey Again ... with a whitelisting, if my content manager writes /kontact-us insted of /contact-us, I will never notice of that.

That's the reason of my notification system of all 404 ... because I REALLY NEED to know about them

But in this case, I have tons of hacking attempts, merged with the 404 I want to get notified.

My question is if it's optimal to create 650 laravel routes ... I think it's not, that's why I'm asking other proposals ;-)

@skater no its not. But do they start with 650 different things? Or are they grouped like wp-?

Route::get('/vendor/{any?}', function ($any = NULL) {
    return 'piss off hacker';
})->where(['any' => '.*']); 

@Sinnbeck Thay are completely different ... maybe I can group some of them ... but literally have houndreds of different strings...

@skater So the only ones you really want to actually know about are ones where someone clicks on a page on your site that takes them to a 404 page?

Say if a content manager in a published post writes <a href="/kontact-us">Contact us</a> with a typo, and some user then clicks on the link in that post, then you want to be notified – but if someone opens their browser and types in www.yoursite.com/rbadudosbds, you don’t want to be notified?

If so, you can take advantage of the fact that most normal user agents set the HTTP_REFERER header when you click on a link, sending the URL of the page the user came from along with the request. You can then set a fallback route and only return a 404 if the HTTP referer is your own app:

Route::fallback(function(Request $request) {
	$referrer = parse_url($request->headers->get('referer'));
	$referrer = $referrer['scheme'] . '://' . $referrer['host'];

	if ($referrer == config('app.url')) {
		abort(404);
	} else {
		return 'piss off hacker';
	}
}

Even better, if you can manually trigger your notification plugin directly, you could disable automatic notification on all 404s and instead do this:

Route::fallback(function(Request $request) {
	$referrer = parse_url($request->headers->get('referer'));
	$referrer = $referrer['scheme'] . '://' . $referrer['host'];

	if ($referrer == config('app.url')) {
		notify404($request->path());
	}

	abort(404);
}

That way, everyone gets the correct 404 page, but you only get notified if the request has a referrer that matches your app URL.

@kokoshneta as I understand it, the content manager types urls manually

my content manager writes /kontact-us insted of /contact-us, I will never notice of that.

I don't know why this needs to be logged, but it does as I understand it

@Sinnbeck I think they mean that if a content manager types a URL that points to a nonexistent location (in the same app) as the href parameter to a link on a public-facing page in the app, then they want to be notified when someone clicks on that link and gets a 404 page. Such a notification will then alert the developer to a potential problem so they can check what the endpoint is and where the manually typed link to it is, so that they can get it fixed as quickly as possible.

Though it may be that you’re right, and they’re actually looking for a way to log a content manager typing the incorrect URL into the address bar in their browser and getting a 404. If so, I doubt there’s any way to filter out human-typed URLs from bot-/spammer-followed URLs.

@kokoshneta ah that might be. Good point :)

@skater You could have an ignore list in your 404 handler. This could be a plain text file that you maintain with known attack urls. Before reporting the 404, check if the URL is in that file. If so, just drop the 404.

However, it does seem like whack-a-mole.

@kokoshneta has a good idea with the referrer.