Compression gzip dans nginx, faille BREACH et perfomance : rechreche d'un compromis pour site Wordpress

#1

Bonjour,

Suite à la version 3.5 de yunohost gzip est désormais complètement désactivé dans nginx pour remédier au problème de sécurité posé par BREACH. Or cela généré tout de même de gros problème de performances, notamment pour des sites vitrine régulièrement visités.

Qu’en est t’il de l’impacte réel de cette faille de sécurité (ce qui me surprend c’est qu’elle semble exister depuis 2012) ?

Si on se fie à ce fils de discutions, notamment ce post, l’utilisation de cookies Same-Site suffirait à rendre la faille inopérante mais de manière surprenante Wordpress semble ne pas Same-Site sur ces cookies de session… Une autres solution que j’envisage est de désactiver gzip uniquement pour les utilisateur connecter avec un truc du genre :

gzip on;
if ($http_cookie ~* "wordpress_loged_in") {
    gzip off;
}

Après test la solution proposé ci dessus ne fonctionne pas, pour un raison inconus ngnix ignore la directive gzip dans un block if pourtant selon la doc on devrais pouvoir le faire.

dans la config Wordpress. Cela vous parait t’il viable ?

Quel solution pourrait t’on envisager pour limiter l’impacte sur les performance du site sans le rendre vulnérable à BREACH ?

#2

Salut,

naivement j’essayerais de jouer sur la mise en cache des fichiers statics (css, js) … meme si ca n’a reelement d’effet qu’apres la premiere visite.

Est-ce que tu sais quel est le gain de perf reel pour une page gzippee vs. non-gzipee ?

#3

20 point sur le test google pagespeed. C’est le premier point de blocage.

#4

Quelque chose comme :

if ($http_cookie !~* "wordpress_loged_in") {
    gzip on;
}

ne fonctionne pas du tout (les directive gzip ne sont pas prise en compte à l’intérieur d’un block if), par contre une solution très simple et plutôt efficasse est d’ajouter ceci dans sa config wordpress :

location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ {
    gzip_types text/css application/javascript text/javascript;
    gzip on;
    expires max;
    log_not_found off;
}

les texte composant le css et javascript représentant la majorité du poids des données pouvant être compressé dans une page (du moins sur une page généré par Wordpress).

#5

Et niveau sécurité qu’est-ce que ça donne ?

#6

Je précise pour les lecteur du post à la recherche d’une solution pour le même problème que le mien que ne suis pas du tout un expert dans le domaine, il ne faut pas prendre comme contant ce que je dit sans plus de vérification, ma seul prétention est de trouver une piste pour améliorer les performance d’un site Wordpress sans nuire à la sécurité du site.

Pour ce que j’ai compris, pour réaliser l’éxploit BREACH il faut que le corps de la page renvoyé par le serveur reflète des donnée précédé-ment saisi par l’utilisateur et que le serveur compresse la réponse en utilisant gzip. L’attaquant mesure les changement de taille des données compressé et tente d’en déduire des information secrètes (dsl je suis pas bon en anglais voici ce que j’en ai compris).

Normalement aucune page statique n’est concerné par BREACH et dans les fait désactiver gzip sur les requêtes POST devrait suffire mais normalement si le site utilise un mécanisme de jeton CSRF l’attaquant de devrait pas pouvoir poster des donnée sur le site via ce genre d’attaque.