auto_prepend_file et auto_append_file

auto_prepend_file définit un fichier que PHP charge, par une opération équivalente à require, avant le fichier principal. auto_append_file fait de même après le fichier principal, sauf lorsque l'exécution se termine par exit(). Les deux directives utilisent include_path.

Elles ne sont pas équivalentes aux include, require ou à l'autoload de Composer : elles s'appliquent depuis la configuration de PHP et peuvent affecter toutes les exécutions couvertes par cette configuration.

Par exemple, le pare-feu de Wordfence peut utiliser auto_prepend_file pour filtrer les requêtes avant de charger WordPress. Vérifiez sa valeur actuelle avant de la modifier : la remplacer par un script de diagnostic peut empêcher cette protection de s'exécuter.

Face à une réinfection, commencez par la source de diagnostic la plus restreinte : l'heure et le chemin indiqués par l'historique de sécurité, les horodatages et les différences du fichier concerné, et les journaux d'accès et de sécurité dans cet intervalle.

Une requête POST proche dans le temps n'est qu'une candidate : elle ne prouve pas que cette requête a modifié le fichier et n'identifie pas le plugin qui l'a traitée. Dans WordPress, de nombreux composants peuvent recevoir des requêtes via index.php, admin-ajax.php ou l'API REST.

Seulement si ces sources ne permettent pas de suivre l'exécution, auto_prepend_file peut être utilisé temporairement pour enregistrer des métadonnées précises des requêtes à venir. N'enregistrez jamais le corps POST complet.

Pas à pas

Créez d'abord /home/CPANEL_USUARIO/private avec les permissions 0700. Créez ensuite, en dehors de public_html, le fichier /home/CPANEL_USUARIO/private/request-debug.php avec ce contenu, en ajustant action, plugin et event aux seuls champs nécessaires à l'enquête :

<?php

(function (): void {

$logFile = '/home/CPANEL_USUARIO/private/request-debug.log';

if (($_SERVER['REQUEST_METHOD'] ?? '') !== 'POST') {
    return;
}

clearstatcache(true, $logFile);
$logSize = is_file($logFile) ? filesize($logFile) : 0;

if (is_int($logSize) && $logSize >= 5 * 1024 * 1024) {
    return;
}

$selectedFields = [];

foreach (['action', 'plugin', 'event'] as $field) {
    if (isset($_POST[$field]) && is_scalar($_POST[$field])) {
        $selectedFields[$field] = substr((string) $_POST[$field], 0, 200);
    }
}

$entry = [
    'time' => date(DATE_ATOM),
    'method' => $_SERVER['REQUEST_METHOD'],
    'path' => parse_url($_SERVER['REQUEST_URI'] ?? '/', PHP_URL_PATH),
    'fields' => $selectedFields,
];

$encoded = json_encode(
    $entry,
    JSON_UNESCAPED_SLASHES | JSON_INVALID_UTF8_SUBSTITUTE
);

if (is_string($encoded)) {
    $previousMask = umask(0077);
    try {
        if (file_put_contents($logFile, $encoded.PHP_EOL, FILE_APPEND | LOCK_EX) !== false) {
            chmod($logFile, 0600);
        }
    } finally {
        umask($previousMask);
    }
}
})();

Remplacez CPANEL_USUARIO par votre nom d'utilisateur cPanel.

Ce script n'enregistre que le chemin, la méthode et les champs sélectionnés, et vérifie un seuil de 5 Mio avant d'écrire. Ce n'est pas une limite stricte : des requêtes simultanées ou la dernière entrée peuvent la dépasser. Surveillez la taille pendant la fenêtre de diagnostic. N'ajoutez pas de champs de mot de passe, d'autorisation, de cookies, de jetons, de données personnelles ou de paiement ; si une valeur légitime peut contenir des informations sensibles, masquez-la ou remplacez-la par un hash avant de l'enregistrer. Le script et le journal doivent appartenir à l'utilisateur cPanel, et le journal doit conserver les permissions 0600.

Ce journal n'apporte que des métadonnées pour corréler une requête candidate. Il ne prouve pas que cette requête a causé la modification et ne constitue pas une preuve résistante aux manipulations : un attaquant disposant d'un accès en écriture au même compte pourrait le modifier ou le désactiver.

Ajoutez ensuite tout au début du fichier .htaccess de public_html :

php_value auto_prepend_file '/home/CPANEL_USUARIO/private/request-debug.php'

Là encore, remplacez l'utilisateur cPanel par le vôtre. La directive affectera les exécutions PHP couvertes par ce .htaccess, généralement aussi dans ses sous-répertoires. Validez d'abord le script avec la même version de PHP que celle du site.

Si une erreur 500 apparaît après l'ajout de php_value, retirez immédiatement la ligne et consultez le journal des erreurs. Seul un message indiquant que la directive n'est pas valide ou pas autorisée confirme que le gestionnaire ne permet pas de la configurer depuis .htaccess.

Avant de commencer, définissez une fenêtre de capture courte et une taille maximale. À la fin, supprimez immédiatement la ligne auto_prepend_file, effacez request-debug.php et détruisez le journal dès que les preuves ne sont plus nécessaires. Tant que vous le conservez, limitez son accès aux personnes chargées de l'analyse et appliquez une durée de conservation explicite ; ne le gardez pas indéfiniment.

Cette capture ne remplace pas la réponse à l'incident. Même si elle permet de relier une requête à une modification, il faut encore confirmer quel code l'a traitée, fermer le point d'entrée, rechercher les mécanismes de persistance, réinstaller les composants depuis des sources fiables, changer les identifiants concernés et vérifier qu'aucun autre fichier ou utilisateur n'a été altéré.

Conservez la valeur précédente de auto_prepend_file et restaurez-la à la fin. Si un pare-feu la gère, ne la remplacez pas sans préparer une intégration compatible sur une copie de test. Vérifiez aussi que le chemin lui-même et les champs sélectionnés ne contiennent pas d'identifiants personnels ; omettez toute donnée dont vous n'avez pas besoin. L'exemple restaure le masque de permissions après l'écriture pour ne pas modifier la façon dont l'application crée ses propres fichiers.