Htaccess headers non interprétés

Hello, Bonjour,

Il y a quelques temps, les tests de vulnérabilités que j'avais passé en ligne indiquaient que mon site était parfaitement secure. Aujourd'hui, en testant avec https://observatory.mozilla.org/
j'ai 0/20 !!! Pourquoi et quoi faire ? Merci.
PS: c'est un site avec extensions .php. Un rapport peut-être ?

Voici un extrait de mon .htaccess :

<IfModule mod_headers.c>
Header set X-XSS-Protection "1; mode=block"
Header set X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains"
Header set Referrer-Policy "same-origin"
Header set Feature-Policy "geolocation 'self'; vibrate 'none'"
Header set Content-Security-Policy "default-src 'self'; script-src 'self';"
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
</IfModule>

# Avec ceci, c'est pareil...
Header always set X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff
Header set Strict-Transport-Security "max-age=63072000; ;includeSubDomains;"
Header set Referrer-Policy: no-referrer
Header set Feature-Policy: "geolocation none"

Bonjour,

1) le rapport donne des mauvais points pour quelle raison ?
2) le site est hébergé comment ? serveur pour lui tout seul ? serveur mutualisé ?
3) le serveur est supposé fonctionner avec apache. Est-ce bien (toujours) le cas ?
4) le paramétrage du serveur est-il modifiable seulement par l'hébergeur ?
5) si oui, l'hébergeur donne-t-il des indications sur le paramétrage ?

Amicalement,

Bonjour,

1) Voici en image la réponse à la 1ere question.

// Quand je fais un :hover sur l'icône Infos, ça décrit le rôle joué par la règle.

2) Serveur mutualisé.
3) Oui, il fonctionne avec Apache.
4) Oui.
5) Non, uniquement pour forcer la connexion en https.
Le conseiller avec qui j'ai discuté au téléphone ne sait pas ce que sont les http headers.
Sur le site de l'hébergeur, à ce sujet, j'ai trouvé ceci, qui m'a été d'une grande aide....
https://www.ionos.fr/digitalguide/hebergement/aspects-techniques/http-header/


Merci
Modifié par Vape6 (20 Jan 2022 - 19:29)

Bonjour,

Tu n'as pas trop à t'inquiéter. Tu fais mieux que des tas de sites. Par exemple, orange.fr fait moins bien que toi.

Si tu n'as rien de très sensible, à mon avis, ça peut reste comme ça.

Mais si vraiment tu veux améliorer, regarde ce que ça donne pour quelques sites de référence que tu connais. S'ils ont traité certains points assez systématiquement, commence par ceux-là. Ce n'est pas juste une question de modifier un htaccess, donc avant de se lancer, mieux vaut vérifier si on en a vraiment besoin.

Amicalement,

Je fais mieux que orange.fr ? mdrrr ah ouais ??? Waoowww je me sens pousser des ailes !!! je suis flattée !!! Mais vite fait.

Non pour moi, résoudre ce problème a une très grande importance, pour 3 raisons :
* Je développe actuellement un site d'envergure dont vous entendrez parler d'ici peu / quelques mois
* Ce site est aussi e-commerce (codé main s'il vous plait !!!) donc je serais intransigeante sur son niveau de sécurité !!!
* et 3 - je propose (en tant que développeur d'expérience ) entre autres, des audits de sécurité > donc j'ai intérêt à ce que mes sites soit parfaitement secure eux-mêmes.

Qu'est-ce qui bugge sur mon htaccess ? Merci <3
Pour info, je parcours les sites stackoverflow ou plein d'autres pour trouver, mais jusqu'ici je n'ai pas vraiment de piste.

A te lire,
Modifié par Vape6 (20 Jan 2022 - 20:07)

Bonjour,

Vape6 a écrit :
je propose (en tant que développeur d'expérience ) entre autres, des audits de sécurité > donc j'ai intérêt à ce que mes sites soit parfaitement secure eux-mêmes.

Certes !

Bon, alors le rapport dit (à sa 1re ligne) qu'il n'y a pas de CSP en place. C'est la 1re chose à essayer de corriger.

Je ne connais pas ton "niveau", donc je fais un plan de marche relativement court. Si ça coince, tu reviens avec tes questions.

Pour faire un test, on créer un répertoire de test. Dedans on met un .htaccess avec une seule ligne minimale qui va mettre en place une CSP mais pour seulement faire un rapport. Par exemple :

Header set Content-Security-Policy-Report-Only "default-src 'self'; img-src *"

Ensuite, on crée évidemment une page de test où on met un peu ce qu'on veut (des images, des chargements de polices de caractère, du js). Y a pas besoin de beaucoup, il faut juste varier un peu en s'inspirant évidemment de ce qu'il peut y avoir comme code dans le site principal.

Ensuite on visite la page, on regarde ce qu'il y a dans la console (click-droit + inspecter), on essaie de comprendre tous les lignes qui s'affichent en rouge, et on essaie de modifier la CSP du .htaccess pour que ça retire les erreurs, tout en limitant le plus possible ce qui est autorisé.

Ensuite, une fois que tout marche, on remplace dans le .htaccess "Header set Content-Security-Policy-Report-Only" par "Header set Content-Security-Policy", et on regarde si ça continue de marcher avec la page de test.

Et enfin, on recommence avec les pages du vrai site.

Amicalement,

J'ai effectué ce test, et aucune erreur dans la console... (mais faut dire que j'ai mis mon fichier php contenant du js, du css, des images, etc dans ce même dossier "Test" > exact ou il fallait le mettre en dehors ?).


Développeur d'expérience oui, mais pas spécialement au niveau du htaccess et certainement moins que toi en règle générale !!! ça parait évident

Je commence à douter de ce mozilla observatory et autres outils de détection car, quand dans Network, je clique sur exemple.css (depuis ma page de test), je lis, entre autres : tout ça :

date: Thu, 20 Jan 2022 21:23:22 GMT
etag: "2e72-5cbe05ebdf2c6-gzip"
expires: Sat, 19 Feb 2022 21:23:22 GMT
feature-policy: geolocation 'self'; vibrate 'none'
last-modified: Mon, 13 Sep 2021 13:23:26 GMT  /// vieille page pourrie à moi [lol]
referrer-policy: same-origin
server: Apache
strict-transport-security: max-age=63072000; includeSubDomains
vary: Accept-Encoding
x-content-type-options: nosniff
x-frame-options: DENY     
x-frame-options: SAMEORIGIN
x-xss-protection: 1; mode=block

C'est mon htaccess cool !!!
avec un doublon sur // ok je note:)

x-frame-options: DENY    
x-frame-options: SAMEORIGIN

----

Es-tu d'accord sur

 vary: Accept-Encoding
// et sur 
etag: "2e72-5cbe05ebdf2c6-gzip" // 

?
Modifié par Vape6 (20 Jan 2022 - 22:48)

Si mon htaccess fonctionne correctement, d'après lecture dans la console, mais qu'il est retourné comme false par leurs algorithmes, c'est du à quoi ?


- En tous cas, ce que tu m'as dit à propos d'orange.fr me waooow DD sachant que je suis autodidacte, quel honneur !!!

Merci pour ton aide. Tu m'as épargné encore plus d'heures de recherches et de prise de tête peut-être pour rien - (?)
Modifié par Vape6 (20 Jan 2022 - 23:11)

Bonjour

Vape6 a écrit :
J'ai effectué ce test, et aucune erreur dans la console... (mais faut dire que j'ai mis mon fichier php contenant du js, du css, des images, etc dans ce même dossier "Test" > exact ou il fallait le mettre en dehors ?).

On met la page de test dans le même répertoire que le .htaccess de test. On met volontairement des ressources interdites (par exemple des images ou des polices qui sont "ailleurs" sur le web) dans la page de test pour voir si la CSP fait son travail. Et on ne fait pas une CSP trop permissive (car on aura peut-être les points lors du test, mais le site sera une passoire).

Une fois que tout marche, on peut se contenter d'une seule CSP qui sera dans le .htaccess à la racine du site.

Vape6 a écrit :
Je commence à douter de ce mozilla observatory et autres outils de détection car, quand dans Network, je clique sur exemple.css (depuis ma page de test), je lis, entre autres ...

C'est mon htaccess cool !!!
avec un doublon sur // ok je note:)

x-frame-options: DENY    
x-frame-options: SAMEORIGIN

Potentiellement, dans apache, on peut avoir des règles dans chaque .htaccess de chaque dossier, et aussi des règles au niveau du serveur. Et les règles s'appliquent non seulement dans le dossier dans lequel elles sont, mais aussi dans les sous-dossiers. En plus de ça, on a aussi des possibilités de spécification dans le html ou encore en php. C'est parfois très compliqué de déterminer d'où vient le problème, sans compter qu'on peut aussi avoir un proxy, docker, etc.

Dans ton cas, on ne peut pas savoir vraiment ce qui se passe avec des fragments d'information. Mais ce que tu obtiens montre bien quelle pagaille cela peut être.

En ce qui concerne l'ordre dans lequel les x-frame-options sont prises en compte, je ne sais pas vraiment. Il est possible que ce soit la plus restrictive qui soit pris en compte. Mais il faudrait surtout trouver pourquoi il y en a plusieurs, parce que là, on ne sait tout simplement pas laquelle a été "vue" en premier et pas plus celle qui a été "vue" en dernier (en supposant qu'elles n'étaient pas dans le même .htaccess sinon, ce serait abusé).

Vape6 a écrit :
Es-tu d'accord sur

vary: Accept-Encoding
// et sur 
etag: "2e72-5cbe05ebdf2c6-gzip" //

En ce qui concerne les optimisations de compression et de cache, beaucoup de choses se font (ou pas) déjà plus ou moins automatiquement à des tas d'endroits dans la chaine de traitement qui envoie les informations du serveur au navigateur de l'internaute. En plus c'est en perpétuelle évolution et les comportements sont différents d'un navigateur à l'autre, voire d'un serveur à l'autre ou même d'un réseau à l'autre. C'est de toute façon du cas par cas. Par exemple, les images, il ne faut surtout pas les compresser car elles le sont déjà et on les compresserait pour rien (en perdant du temps), et les petits fichiers, c'est peu clair qu'on y gagne. Et enfin, si la décompression ne coute quasiment rien, la compression, elle, peut ralentir pas mal le serveur.

C'est pourquoi ma philosophie est d'en faire le moins possible sur ces deux questions dans les .htaccess parce qu'on a vite fait de mettre le bazar et d'être en fin de compte contre-productif. Ceci étant, si tu as mis un truc au point et qu'il fait effectivement gagner du temps d'affichage, il faut le garder.

À noter aussi que pour js et css, voire le html, on se contente souvent de les minimifier, ce qui n'est pas une compression, mais ce qui en réduit pas mal l'utilité sans pénaliser les CPU du serveur ou de la machine de l'internaute.

En résumé : on ne met dans le .htaccess que ce que l'on comprend parfaitement. Et le reste, on laisse tomber.

Vape6 a écrit :
En tous cas, ce que tu m'as dit à propos d'orange.fr me waooow

Orange a d'autres moyens pour faire de la sécurité aussi (il n'y a pas que la CSP et les quelques points vérifiés par https://observatory.mozilla.org/ qui sont à prendre en compte)  !

Et ils ont probablement quelque part une tour si ce n'est plusieurs remplie d'informaticiens qui ne font que de la sécurité !

Vape6 a écrit :
Si mon htaccess fonctionne correctement, d'après lecture dans la console, mais qu'il est retourné comme false par leurs algorithmes, c'est du à quoi ?

La question n'est pas claire. Que veux-tu dire par "retourné comme false par leurs algorithmes" ?

Amicalement,

Bonjour,

gray_magic a écrit :
Pour bien faire, les CSP doivent être gérées au niveau du PHP.

Il y a souvent des ressources qui ne sont pas du php, même si le site lui-même est en php. Tu conseilles quoi pour ces ressources en complément des headers en php ?

Amicalement,

Hello Parsimonhi,

Typiquement, ça dépend pour beaucoup de l'analyse de ton modèle de menace et de ton application en elle-même, ainsi que de la puissance serveur dont tu disposes et de l’infrastructure réseau.

Si tu fais :
Serveur Proxy > répartiteur de charge > 1 à X serveurs
Ce n’est pas la même que si tu as juste un VPS.

Le modèle le plus sécurisé fait transiter 100% des requêtes (JS,Médias,CSS, résultat d’exécution d'un script bash,python, etc) par le PHP qui analyse la requête et définit si la ressource doit ou non être distribuée (même principe que le moniteur de référence que tu retrouves dans les noyaux d'OS). Sachant que ce que tu gagnes en sécurité, tu le sacrifies en temps de calcul serveur.

ça permet de centraliser les accès, de journaliser les demandes non autorisées, d'envoyer des alertes le cas échéant, voire même de réaliser des contre-mesures (black list auto d'ip, redirection sur un serveur de mitigation, suppression des clés de chiffrement des ressources critiques et exfiltration des logs #failsafe, pour garantir que même si l'attaque aboutie l'attaquant n'aura rien à se mettre sous la dent et ne pourra pas détruire les logs).

PS : Mais là on rentre totalement dans la problématique d'imbrication des connaissances (architecture, sécurité,IA , développement) qui ne sont que trop rarement toutes maitrisées par le développeur.

Bon WE !