[Résolu] Une idée pour des 4.4.21 à jour et toujours (re)bloqués par OVH

Bonjour,

Puisqu’OVH continue à identifier à tort des sites « hackés » dans le cache de SPIP, voici l’idée :
dans config/mes_options.php

define('_NO_CACHE', -1);

Et comme ça, pas de cache, pas de détection par OVH.
C’est néanmoins crade car ça ralentit le site.

Une piste à explorer pour limiter l’impact performance : ne faire ce define que si la page demandée est celle de résultat de recherche ?

Qu’en pensez-vous ?

Quelque chose comme :

if (isset($_GET['page']) && $_GET['page'] === 'recherche') {
    define('_NO_CACHE', -1);
}

C’est totalement insuffisant de chercher ‹ recherche › …

On va voir ce qu’on va pouvoir faire dans une prochaine version pour limiter ces éléments en cache

3 « J'aime »

Qu’est-ce qui est stocké de problématique exactement dans le cache ?

Du code php avec du base64_decode par exemple, suite à des tentatives d’attaque. En 4.4.21 elles sont bloquées mais OVH considère que ce sont des malwares.
fix: eviter de générer du cache avec des contextex empoisonnés par du PHP (!324) · Requêtes de fusion · spip / ecrire · GitLab va règler tout ça :slight_smile: merci la team !

2 « J'aime »

En attendant, j’ai ajouté ceci dans le .htaccess :

# Bloque les tentatives d'injection de code PHP dans la query string
RewriteCond %{QUERY_STRING} (%3C%3Fphp|<\?php|<%3fphp) [NC,OR]
RewriteCond %{QUERY_STRING} (base64_decode|file_put_contents|system\(|shell_exec|passthru|popen|eval\() [NC]
RewriteRule .* - [F,L]
3 « J'aime »

Belle config !
Pour nginx j’ai mis l’équivalent :

# Bloque les tentatives d'injection de code PHP dans la query string
if ($query_string ~* "(%3c%3fphp|<\?php|<%3fphp|base64_decode|file_put_contents|system\(|shell_exec|passthru|popen|eval\()") {
    return 403;
}
2 « J'aime »