Ticket #341 (closed defect: fixed)

Opened 8 years ago

Last modified 21 months ago

403 errors because of wildcards in referrer spam list

Reported by: yodahome@… Owned by: unassigned
Priority: normal Milestone: 1.3.4
Component: administration Version: 1.1.6.2
Severity: normal Keywords: 403 referrer spam block unwanted
Cc:

Description (last modified by BrianKoontz) (diff)

Well, I consider this a bug but judge for yourself:

I just spend about 10 hours looking for a problem when certain pages and functions like /edit /info etc. on certain pages suddenly returned 403 errors. (I actually phoned my webhosters because I thought of it as a server problem) It turned out that all the pages didn't show up because I opened them from a Wikka page called "AssassinsKontakt". As you can see the magic word 'Kontakt' (=contact) caused the problem because the spamlist in .htaccess effectively blocks all connections from a referrer url that includes the listed words (e.g. 'Kontakt'). You might want to re-consider the words used in your list or whether only the name of the top level domain should be checked. This way it's much too strict for my taste and it's confusing although I (of course) understand the necessity to block spam.

Related tickets

#68 #1057 (Anti-spam tools)

Change History

Changed 8 years ago by DarTar

  • severity changed from major to normal
  • version set to 1.1.6.2
  • component changed from unspecified to administration
  • description modified (diff)
  • milestone set to 1.1.7

YodaHome, the current .htaccess-based filtering is really a quick and dirty hack to block spam. The list of bad words is supposed to be user-maintained, but I agree it's not a very 'usable' technique. I wouldn't consider this a major issue, though (precisely because it can be easily solved by editing the .htaccess file). In the future we should implement better (more effective/flexible) tools against spam. See #68

As for "Kontakt" I guess it was included in the list because of some previous spammer using this word in the hostname. I agree that we should review the list and make the filter more selective.

(Marking this ticket for 1.1.7)

Changed 8 years ago by yodahome@…

Sorry, wasn't meant to be a major. However, I only consider this a problem since it is the default behaviour and usually you wouldn't expect someone to find and actually control the list. A less experienced user might not even know that .htaccess could be the problem (and thus not change it). And you wouldn't exspect it to block requests from the same domain and server (although spammers could use this hole once known). However, I understand this is not meant to be a final solution but I thought it was worth a ticket.

Changed 8 years ago by steve@…

I want to thank yodahome@… for posting this. I just spent three hours researching the same problem, then found this post. Now at least I know I am not crazy. Thanks again, Steve

Changed 6 years ago by DarTar

  • milestone changed from 1.2 to 1.3

Retargeting to 1.3. Code for this ticket may have already been committed to trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

Changed 5 years ago by BrianKoontz

  • milestone changed from 1.3 to 1.4

Changed 2 years ago by BrianKoontz

(In [1881]) This one fell through the cracks. Agreed that this is a really antiquated way of dealing with spammers, probably just needs to be removed. Refs #341.

Changed 2 years ago by BrianKoontz

  • status changed from new to closed
  • resolution set to fixed

Changed 2 years ago by BrianKoontz

  • description modified (diff)

Changed 21 months ago by BrianKoontz

  • milestone changed from 1.4 to 1.3.4
Note: See TracTickets for help on using tickets.