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

Discuss
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.

7

@im_a_teapot est-ce que ça ne vaudrait pas le coup d’ouvrir un ticket sur l’app concernée ? https://github.com/YunoHost-Apps/wordpress_ynh

Est-ce qu’une stratégie ne serait pas, de patcher le nginx.conf de wordrpress_ynh pour dire que dans le bloc location le plus général on active gzip et que dans le bloc spécifique au php, on le désactive.

Ainsi les fichiers statiques devraient être servis avec gzip, et les .php sans. Ça atteindrait ton but ça @im_a_teapot non ?

Si je comprends bien la logique dans ynh, c’est par défaut on désactive gzip, et les packageurs d’apps prennent la responsabilité de réactiver gzip sur ce qui est safe. C’est à dire, si on ne veut pas trop rentrer dans le détail, les vues dynamiques. J’ai bon ? (@Aleks ?)

8

Oui ça me parraît tout à fait ok d’avoir une règle custom dans la conf nginx d’une app qui dit que pour les fichiers statiques on active gzip …

(N.B. : si on a désactivé gzip entièrement, c’est aussi parce que nginx est stupide et zippe tous les fichiers html quoi qu’il arrive - même si on précise une liste de mime-types du genre fichiers css, js etc… (ce qui avait été fait précédemment dans ynh) il gzippera toujours les fichiers html, donc pas moyen de spécifier une configuration par défaut raisonnable qui ne soit pas vulnérable à BREACH - après on est d’accord : dans l’absolu, BREACH c’est pas la vulnérabilité du siècle non plus…)

1 Like