[spip-dev] "Attaque" bizarre sur 2 sites que j'héberge

Dev
1

Bonjour,

Sur 2 sites que j'héberge, j'ai des milliers de requêtes de ce type :
urldusite/spip.php?page=recherche&page=recherche&recherche=http%3A%2F%2FuneURLdeSPAM
Et ça venant de plusieurs IP différentes en permanence.

Pour contrer ça, j'ai mis dans le .htaccess :
RewriteCond %{HTTP_HOST} ^(www\.|)urldusite\.tld [NC]
RewriteCond %{QUERY_STRING} recherche=http [NC]
RewriteRule .* - [F]

Pour produire des 403 forbidden
Et réduire la charge serveur

Si besoin, je peux envoyer à la team une liste d'url réelles.

2

Un(des?) bot(s) un peu bête(s) qui croi(en)t ainsi faire de l’injection d’URL dans du cache, parce que les pages de reponse qu’ils récupèrent contiennent l’URL mise en requete.
On les subit sur contrib depuis bien longtemps déjà…
De mémoire j’ai mis une règle dans l’écran de secu sur la double occurence de page=recherche pour le bloquer.

3

Cerdic a écrit le 12/04/2018 à 00:07 :

Un(des?) bot(s) un peu bête(s) qui croi(en)t ainsi faire de l’injection d’URL dans du cache, parce que les pages de reponse qu’ils récupèrent contiennent l’URL mise en requete.
On les subit sur contrib depuis bien longtemps déjà…
De mémoire j’ai mis une règle dans l’écran de secu sur la double occurence de page=recherche pour le bloquer.

Merci de ta réponse.
Je viens de chercher "recherche" dans l'écran de sécurité et je n'ai pas trouvé de code correspondant à ce que tu cites de mémoire.

C'est en tout cas un truc qui charge bien le serveur :frowning:

4

C'est dans l'écran de contrib seulement :

https://zone.spip.org/trac/spip-zone/browser/galaxie/www.spip-contrib.net/squelettes/2012/mes_options.php#L5

JL

5

Même chose la semaine dernière sur un site que je gère, même double occurence, ils nous ont saturé le serveur.
De mon côté j'ai désactivé la recherche en mode pompier ce week end.

Faudrait peut être reporter dans l'écran sécu générique ?

6

Ça ne bloque pas une url du type spip.php?page=recherche&page=recherche&recherche=http%3A%2F%2FuneURLdeSPAM

En retirant and _request('page')!='recherche' ça bloque bien.

7

Oui, cette restriction est étonnante.
Peut être est elle motivée par le pattern particulier du spam qui avait motivé cette protection à l'époque,
mais cette restriction me semble superflue dans le cas général.

Sauf que peut être faut il pouvoir chercher http sur certains sites ???

JL

8

Le bout de code auquel je pensais n’est pas dans le repo public, je vais remettre la main dessus

9

Carrément pas, une recherche qui commence par http peut être légitime.

10

hello,

je n'ai plus rien vu passer, le probléme est il résolu et si oui comment

merci

11

Même problème à l'instant sur un autre site.

J'ai mis ça dans mes_options pour bloquer et logger les IPs :

if (substr(_request('recherche'),0,4)=='http'){
  if ($GLOBALS['ip']) {
    touch('tmp/flood/'.$GLOBALS['ip']);
  }
  header("HTTP/1.0 403 Forbidden");
  header("Expires: Wed, 11 Jan 1984 05:00:00 GMT");
  header("Cache-Control: no-cache, must-revalidate");
  header("Pragma: no-cache");
  header("Content-Type: text/html");
  die("<html><title>Error 403: Forbidden</title><body><h1>Error 403</h1><p>You are not authorized to view this page.</p></body></html>");
}

j'ai mis tmp en dur dans le touch car _DIR_TMP n'était pas déclaré à ce moment là sur mes premiers tests (je ne sais pas pourquoi).