Sécurité, phishingRésolu/Fermé

Question

Bonjour,

Je fais appel aux webmasters pour, non pas une aide technique, mais plutôt une stratégie de sécurité à adopter.

Un hébergeur du web a signalé au mien que le site web que je maintenais avait été utilisé pour faire du phishing. Réaction de mon hébergeur : il a désactivé la visibilité du site, m'a immédiatement prévenu et m'a demandé de vérifier complètement mon site avant d'en réactiver la visibilité. Cela a été fait.

Je suis maintenant à la recherche d'un moyen, d'une stratégie qui empêcherait cette nuisance ; genre un quelque chose qui serait affiché sur mon site et qui permettrait au visiteur de vérifier qu'il n'a pas été abusé (ou un MD5 ou un ROT13 de quelque chose, une signature PGP ou tout autre moyen imaginable et "relativement" sûr).

J'ai imaginé la suivante :

NB: Ce site peut servir à faire des tests en ligne et, si le visiteur le demande, à envoyer le résultat par mail à l'adresse qu'il aura bien voulu indiquer (adresse non conservée).

Je pense aussi, par exemple, à la possibilité de signer le mail-résultat avec PGP et indiquer en page d'accueil du site que :
1) ce site n'enverra jamais aucun autre mail que les mails-résultats de tests ;
2) la clef publique PGP se trouve à tel endroit afin de la télécharger et vérifier qu'un mail reçu émane bien du site (donc un mail-résutat et pas un autre) et ne provient pas d'une tentative de phishing.

Je ne sais si c'est la bonne méthode mais toute (autre) idée est la bienvenue et parmi les solutions proposées, il s'en trouvera bien une qui ne servira pas qu'à moi mais à tous les webmasters soucieux de la sécurité afin d'éviter ces désagréments. Vos réponses intéressent tout le monde.

Merci pour vos conseils.

Windows / Firefox 103.0

avion-f16 · Answer

Bonjour,

Un hébergeur du web a signalé au mien que le site web que je maintenais avait été utilisé pour faire du phishing. Réaction de mon hébergeur : il a désactivé la visibilité du site, m'a immédiatement prévenu et m'a demandé de vérifier complètement mon site avant d'en réactiver la visibilité. Cela a été fait.

Était-ce le cas, as-tu constaté ledit contenu frauduleux ? d'ailleurs tu parles de phishing et de courriels, ce n'est pas clair s'il s'agit d'un problème concernant l'envoi de spams depuis ton compte, ou l'hébergement d'un site d'hameçonnage sur ton domaine.

Avant de rechercher une solution, il faut tout d'abord comprendre comment cela a pu arriver.

Ce type de problème se pose souvent lorsque l'application PHP du client (l'abonné au service d'hébergement) contient des vulnérabilités. Il s'agit d'une faille au niveau utilisateur et non une faille au niveau serveur.

Je ne vois pas de quelle façon la solution que tu proposes permet de résoudre l'origine du problème. Le fait que tu fournisses une signature pour tes pages ou les courriels que tu envoies n'empêche pas d'exploiter une vulnérabilité qui serait présente dans le script PHP afin d'altérer tes pages, en ajouter d'autres, ou envoyer des courriels (non signés) vers d'autres destinataires au hasard qui ne connaissent pas ton site.

Le site d'hameçonnage placé par la hacker n'a généralement pas pour cible tes propres visiteurs. Le site de phishing est souvent publié dans un sous-dossier et n'altère pas nécessairement le fonctionnement du site légitime. Le hacker peut transmettre le lien du site frauduleux, dans un sous-dossier, par courriel. Les gens qui recevront le lien n'ayant pas connaissance de ton mécanisme de chiffrement, ils n'y verront que du feux. Sauf s'ils prennent la peine de regarder l'URL, en 2022, ça devrait être un réflexe depuis le temps que le problème est connu (mais des gens se font encore avoir avec les PCS...). Ta méthode nécessite aussi que le visiteur ait déjà visité / utilisé ton site. Comment un visiteur qui viendrait pour la première fois pourrait connaître ta clé publique ?

Une solution qui vient de me traverse la tête serait de publier la clé publique via les DNS, l'authenticité (mais pas le chiffrement) des réponses DNS pouvant déjà être assurée par DNSSEC, c'est donc désormais un moyen sûr de communiquer une information (l'information est authentifiée mais pas chiffrée, j'insiste là-dessus). Chaque page https://example.com/page.html pourrait avoir sa signature à l'adresse https://example.com/page.html.sig et le navigateur pourrait automatiser la vérification :

Le visiteur demande https://example.com/page.html
	Le visiteur télécharge
	
		https://example.com/page.html
		https://example.com/page.html.sig
		L'entrée TXT pour __sig.https.example.com = la clé publique
		Compare page.html avec page.html.sig et la clé publique
		Fait de même pour chaque élément (image, css, js, ...)

Les avantages :

Automatique : le visiteur ne doit rien faire
	Il s'agit d'une solution « E2E », un peu comme Signal mais sans le chiffrement, entre le visiteur et le webmaster, qui ne dépend pas du serveur Web, et qui permet de s'assurer que le contenu demandé correspond bien à celui émit par le titulaire du domaine. À l'inverse du chiffrement de transport (TLS) qui dépend de la confiance que tu accordes au serveur.
	La clé privée peut rester sur l'ordinateur du webmaster, personne d'autre que lui ne peut signer une page.
	En cas de serveur compromis, par des hackers (faille niveau serveur), par une vulnérabilité au niveau du script PHP, volontairement par l'administrateur du serveur, ... toute altération au contenu du site sera détectable. Admettons que quelqu'un publie son site via un proxy inversé comme CloudFlare, alors ce mécanisme empêcherait de proxy inversé d'injecter du contenu dans le site (script JS ...). Cela n'empêchera toujours pas la lecture du trafic HTTP par ce proxy car c'est une authentification, pas un chiffrement, et dans le cas de CloudFlare, c'est lui qui gère la couche TLS entre le visiteur et ses serveurs (oui oui, CloudFlare peut lire les mots de passe de tes visiteurs). Le hacker devrait donc pirater le serveur, mais aussi le DNS, qui peut (et devrait) être indépendant du serveur Web.

Désavantages :

Les requêtes DNS et HTTP supplémentaires pourraient ralentir le chargement des sites.
	- DNS permet de joindre des informations non demandées (champ "additional"), on pourrait donc "pousser" la clé publique lors de la résolution DNS de example.com.
	- Les versions récentes de HTTP (HTTP/2) permettent aussi de joindre des ressources supplémentaires avec la page demandée avant même que ces ressources soient demandées.
	Malgré cela, la quantité de données à transférer sera augmenté, et la validation de la signature peut aussi entraîner une charge CPU côté utilisateur.
	Valable uniquement pour les sites statiques. En effet, les pages dynamiques étant générées côté serveur, il faudrait que la clé privée soit donnée à l'application PHP afin qu'elle génère la signature, ce qui détruit tout l'intérêt de la solution dans le cas où le problème est justement causé par une faille dans le code PHP.

Je ré-insiste sur le fait qu'on parle d'authenticité et pas de chiffrement, le chiffrement de bout en bout des pages Web entre le visiteur et le créateur de la page nécessiterait que le créateur de la page connaisse la clé de chiffrement publique du visiteur, or le but du site est qu'il soit accessible par tout le monde.

Sécurité, phishing

1 réponse

Discussions similaires

Newsletters