Quelles mesures de sécurité conviennent à un site Web statique?
J'ai un site Web statique. Les utilisateurs ne peuvent pas se connecter ni effectuer d'autres actions. Lesquelles des mesures de sécurité HTTP courantes sont pertinentes pour mon site?
En ai-je besoin?
Les vecteurs d'attaque d'applications Web courants ne s'appliquent pas à un site Web strictement statique. Sans éléments interactifs, il n'y a pas de comptes à détourner ou de cookies à voler. Néanmoins, vous devez fournir à vos visiteurs un accès crypté - même si vous n'hébergez pas de contenu délicat.
TL; DR
Utilisez HTTPS avec HSTS pour garantir une certaine confidentialité et l'intégrité de votre contenu aux visiteurs. L'ajout de HPKP à un site statique peut être inutilement paranoïaque et vous devez être prudent lors de son déploiement. Les autres mesures de sécurité discutées ne sont généralement pas pertinentes pour un site statique, mais elles sont si simples à mettre en œuvre que vous pouvez toujours décider de les utiliser.
HTTPS
Oui, faites-le. Avec des fournisseurs de certificats SSL gratuits comme Let's Encrypt vous avez besoin d'une très bonne raison de ne pas changer. HTTPS protège la confidentialité et l'intégrité des données transmises, ce qui est souhaitable même avec un contenu statique.
Scénario pour une violation d'intégrité: si vous proposez des téléchargements, un attaquant du milieu pourrait altérer les fichiers pour livrer des logiciels malveillants. Exemple de violation de la vie privée: mon employeur, le propriétaire du hotspot WiFi auquel je suis connecté ou mon FAI peuvent tous voir quels articles exacts je lis et quel contenu je télécharge depuis votre site. Avec HTTPS cependant, j'exposerais principalement les métadonnées (l'adresse IP à laquelle je suis connecté, le nom d'hôte dû à SNI , etc. ).
HTTP Strict Transport Security
Oui, faites-le. HSTS aide à faire en sorte que les utilisateurs seulement utilisent HTTPS pour se connecter à votre site Web, empêchant ainsi - SSL stripping attaques. Si vous déployez HTTPS, il est très logique de faire un suivi avec HSTS. Il est facilement implémenté en ajoutant un en-tête de réponse supplémentaire, comme ceci:
Strict-Transport-Security: max-age=31536000
Étant donné que HSTS ne prend effet qu'à partir de la première fois, un utilisateur rencontre l'en-tête ( modèle TOF ) et jusqu'à ce que max-age le délai est atteint, vous pouvez même soumettre votre site à la liste de préchargement HSTS . Cela a pour effet que les utilisateurs commenceront à se connecter via HTTPS dès leur première visite.
Sachez que c'est gênant pour revenir au HTTP simple après avoir activé HSTS.
Épinglage de clé publique HTTP ("épinglage de certificat")
Cela dépend. Alors que HSTS indique au navigateur d'utiliser strictement HTTPS pendant un temps donné, un en-tête HPKP spécifie les certificats auxquels le navigateur doit faire confiance à l'avenir. L'épinglage de clés publiques de la chaîne de certificats protège les utilisateurs contre un attaquant remplaçant votre certificat par un autre non autorisé. Une telle attaque est très improbable car l'adversaire devrait compromettre une autorité de certification pour pouvoir émettre des certificats frauduleux (bien que ce qui s'est déjà produit ). De plus, vous devez être prudent lors de la configuration de HPKP car un déploiement défectueux pourrait rendre votre site indisponible aux utilisateurs précédents.
Detectify Labs a un excellent article sur HPKP avec une conclusion plus optimiste:
Alors, devriez-vous utiliser HPKP? Oui tu devrais. Si vous épinglez correctement, les chances que tout se dirige vers le sud sont assez faibles.
Politique de sécurité du contenu
Oui, mais vous n'en aurez peut-être pas vraiment besoin. Le CSP a été créé pour atténuer XSS et les attaques associées en limitant le type de ressource à partir duquel Origin est autorisé à être chargé par votre site. Comme vous avez un site Web purement statique et que vous n'incorporez probablement pas de sources externes du tout, il ne s'agit peut-être pas d'un véritable vecteur d'attaque. Une politique sensée dépend du type de ressources que vous chargez. Par exemple, cet en-tête de politique restrictif autorise uniquement le contenu de la même origine:
Content-Security-Policy: default-src 'self'
Protection contre le détournement de clics
Oui, pourquoi pas. Les attaques de détournement de clics incitent un utilisateur à interagir sans le savoir avec votre site Web à travers un cadre déguisé. Si vous n'avez cependant aucun élément interactif, il n'y a aucun dommage réel à faire. (Dans un monde meilleur, les cadres d'origine croisée seraient cependant une option opt-in.) L'implémentation est simple. Cet exemple interdit toute incorporation de cadre:
X-Frame-Options: Deny
Notez que l'en-tête XFO a été déclaré obsolète en faveur de frame-ancestors Directive CSP:
Content-Security-Policy: frame-ancestors 'none'
Protection contre le reniflement de contenu
Oui, pourquoi pas. Si vous ne déclarez pas correctement les types de contenu, les navigateurs peuvent deviner (renifler) le type (bien que ce comportement soit devenu moins courant) . Cela est particulièrement dangereux avec le contenu utilisateur qui est censé être non exécutable mais déterminé comme étant un format exécutable après avoir été reniflé en raison d'un type de contenu manquant. Avec votre site statique qui ne deviendra guère un problème. Juste pour être sûr, vous pouvez ajouter l'en-tête suivant pour éviter de renifler (mais ce n'est pas un remplacement pour les types MIME correctement déclarés):
X-Content-Type-Options: nosniff
Voir aussi: X-Content-Type-Options empêche-t-il vraiment les attaques de reniflement de contenu?
Jetez également un œil au OWASP Secure Headers Project pour plus de détails sur les en-têtes liés à la sécurité avec des exemples concrets.
- HTTPS
- Sécurité de transport stricte
- Épinglage de certificat
Ceux-ci protègent le transport des données contre le reniflement et contre la manipulation. Cette protection est non seulement pour la demande du navigateur mais aussi pour la réponse et est donc parfaitement logique même pour un site statique.
- Politique de sécurité du contenu
Si vous n'incluez pas de contenu d'un autre côté, cela n'est probablement pas nécessaire mais ne nuit pas non plus. Si vous incluez du contenu externe hors de votre contrôle comme des publicités, des images, des polices, des scripts, il est logique de le restreindre.
- Protection contre le détournement de clics
Si vous incluez des liens vers d'autres parties qui agissent ensuite sur la base d'un référent de confiance (c'est-à-dire votre site) ou si vous incluez des boutons de médias sociaux ou similaires, il est logique de restreindre le cadrage. Sinon, cela ne nuit pas à moins que vous ne souhaitiez explicitement que vos sites soient encadrables par d'autres.
- Protection contre le reniflement de contenu
Si vous diffusez du contenu qui pourrait être interprété différemment lorsque le reniflage de contenu est actif (par exemple, servir du HTML sous forme de texte/clair pour afficher le code source), il est logique d'activer la protection de reniflement de contenu. Sinon cela ne fait pas de mal.
Il y a tellement de choses à considérer lorsque vous planifiez un site Web et surtout quand il s'agit de votre site Web professionnel, vous devez toujours y prêter une attention particulière. Cependant, le site Web statique a tendance à avoir moins de risques que les autres sites, mais il aurait quand même dû suivre un aspect de sécurité important comme vous l'avez mentionné ci-dessus. Les détails fournis ici ne sont que pour partager des connaissances supplémentaires sur les problèmes de sécurité pour différents types de sites. Je n'ai pas besoin d'ajouter grand-chose ici, car @Arminius et @Steffen ont levé la plupart des doutes. Permettez-moi encore d'ajouter mes vues:
HTTPS:
Un certain nombre de sites Web ont cru que leurs sites statiques ne nécessitent pas de certificat SSL, mais ils considèrent maintenant le SSL comme un aspect important de leur site. La première raison est annonce de Google lors de l'augmentation du classement; une autre raison est le traitement des sites non HTTPS par les navigateurs.
HSTS:
HTTP Strict Transport Security ou HSTS est un protocole de sécurité pour protéger les sites Web contre détournement de cookies et l'attaque de déclassement indique simultanément le serveur Web pour autoriser uniquement une connexion HTTPS sécurisée sur le navigateur Web et d'autres agents. Cette politique ajoute une couche supplémentaire sur la sécurité HTTPS et aide les sites Web et leurs utilisateurs à rester en sécurité.
CSP:
Des attaques comme XSS ( cross site scripting ), l'injection de code nuisent non seulement aux performances du site Web, mais détruisent également la réputation en mettant du contenu intolérable. Qu'il s'agisse d'un site statique ou dynamique, l'injection de code malveillant peut mettre le site Web en difficulté. L'utilisation d'un logiciel anti-malware et une évaluation régulière de la vulnérabilité peuvent aider les sites Web à prévenir ces attaques indésirables.
HPKP:
HTTP Public Key Pinning (HPKP) est une méthode efficace pour éviter les attaquants en les restreignant à émettre un certificat frauduleux avec une intention malveillante. HPKP est souvent fallacieusement populaire en tant qu'épinglage de certificats, alors qu'il s'agit d'un mécanisme de sécurité permettant aux sites Web HTTPS de protester contre l'attaquant pour arrêter d'émettre des certificats frauduleux.
Détournement de clics:
Cette technique est très populaire sur les sites de films piratés où ils redirigent les utilisateurs vers une fausse page ou un téléchargement. Parfois, la technique de détournement de clics peut être utilisée sommairement avec Malwartising activité où les attaquants propagent des logiciels malveillants en usurpant l'identité de quelque chose.
Reniflage de contenu:
Le reniflage de contenu est un type de capture ou de surveillance du contenu qui réside dans l'octet et, par conséquent, l'attaquant peut supposer le type de fichier du contenu. Le reniflement de contenu fait référence à des métadonnées inexactes qui sont définies pour rendre le fichier à déduire correctement.
c'est juste mon opinion:
- HTTPS
- Sécurité de transport stricte
- Protection contre le reniflement de contenu
- Épinglage de certificat
Pourquoi auriez-vous besoin de vous protéger, sur un site statique, du reniflement si vous ne présentez pas d'informations personnalisées ou protégées? Je suppose que les informations sur un site statique sont publiques, donc pas besoin de couvrir cela.
- Politique de sécurité du contenu
Si vous n'incluez pas de contenu dynamique, ni de contenu externe (le site statique non). Ensuite, celui-ci n'est pas nécessaire. Comme il n'y a pas d'attaque XSS possible.
- Protection contre le détournement de clics
Comme Steffen Ulrich celui-ci n'est pas requis sauf si vous définissez explicitement votre site comme encadrable par d'autres.
Donc, en conclusion: si vous définissez un site Web strictement statique, vous n'avez besoin d'aucune de ces mesures de sécurité.
Dans tous les cas, si vous pensez que vous pouvez modifier ce site dans un proche avenir pour le rendre plus dynamique, ajoutez toutes les mesures de sécurité possibles.