Journal Comment j'ai été piraté, mais en fait pas trop, mais un peu quand même.

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
65
17
mai
2024

Ça fait bientôt un an que je gère mon propre serveur mail. Et si j'avais dit au début "juste pour moi, et puis pour dépanner des gens qui fuient Gandi le temps de trouver mieux", au fil du temps mes quelques utilisateurs et organisations sont restées. Et c'est cool ; cela amène des problématiques que je n'aurais pas si je gérais uniquement mon mail perso rien qu'à moi.

J'en profite donc pour rassurer celles et ceux qui hésitent à se lancer dans l'aventure du mail : la complexité varie suivant vos besoins. Avoir son mail auto-hébergé juste pour soit, c'est plutôt facile, sans gros souci, et au pire ça n'impacte que nous, on peut réparer. Tant que je n'ai eu que mes propres mails, c'était vraiment facile ; un peu trop ! Avoir des utilisateurs, c'est découvrir les pratiques variés de gestion des mails et une gamme de bazar nouveau. Je ne suis pas prête à héberger plus pour le moment, c'est certain !

Je surveille régulièrement la santé de mon serveur mail ; j'adore voir défiler les logs et les bots qui se cassent les dents sur ma config, et puis recevoir les mails de Reaction et Fail2ban (ouais les deux ensemble, je n'ai pas encore traduit toutes les règles du dernier vers le premier) qui me disent qu'ils ont éjecté dans l'espace une poignée d'IP. Et je me disais "jusqu'ici tout va bien", avec plein d'idées pour améliorer les choses et pas le temps pour le faire. Parce qu'on ne va pas se mentir, c'est très largement améliorable, mon truc.

Tout cela pour en arriver à il y a quelques jours, quand un fournisseur bien connu me signale qu'il n'a pas pu délivrer un message, que je n'ai jamais envoyé, et pour la raison 550 5.7.1 "Blocked for spam". Je regarde le mail dans tous les sens, il semble légitime, réel, et je dois me résoudre à accepter l'inconcevable…

Horreur, catastrophe, un horrible pirate a trouvé comment rentrer !!!!

Et plus inquiétant : avec un compte qui ne devrait jamais être exposé publiquement. Pour comprendre ma frayeur, il faut que je détaille un peu une de mes bidouilles anti-crackers.

Quand j'ai quitté Gmail, il y des années, je voulais trouver d'où venait les spams pour m'en prémunir autant que possible. Ou du moins les filtrer à fond. J'avais donc créé plusieurs adresses mails, dont l'une utilisant abondamment les alias avec joker :
- Une adresse pour les proches
- Une adresse en nom.prenom pour les officiels, le travail…
- Une adresse avec mon pseudo pour laisser sur git et autres trucs de geek.
- une adresse avec des jokers pour s'inscrire sur tous les sites.

J'étais sûre que le spam venait avant tout de ces sites, donc je donnais un hello.magasin@mondomain.net ou yo.sitedouteux@mondomain.net. Cela m'a été utile une seule fois en plusieurs années, un de ces sites s'étant fait hacké et l'adresse mail se retrouvant alors dans la nature. Et au passage, cela m'a permis de contacter la boite, et d'avoir un chouette échange avec leur responsable informatique. Bref : en fait, les commerces en lignes et autres sites respectent les règles, suffisamment en tout cas, d'après mon expérience. Ça aide quand même à trier leur flood, mais ce n'est pas du spam : leurs envois sont légitimes bien que parfois trop nombreux.

Pour autant du spam, j'en ai eu, et il est venu des sources suivantes :
- Une fois, j'ai un proche qui s'est fait hacker sa boite mail, donc j'ai reçu des mails bizarres. Ça n'a pas duré, sans que j'ai rien à faire. Visiblement dans ce genre de cas, le pirate ne garde pas tout le carnet de contact ? En tout cas, pas là.
- Les gens avec qui j'ai pu avoir des échanges officiels… C'est horrible. Dans le lot il y a toujours des petits futés qui partagent tout leur carnet d'adresse avec cette app géniale ou ce site proposant de supers services. Résultat, l'adresse pro est un dépotoir. Et là c'est pas toujours facile de nettoyer…
- Et enfin, en grand gagnant : laisser son adresse traîner sur le web. Dans une page de contact, sur un profil, dans une entrée DMARC… C'est là qu'on ramasse la crasse la plus basse, les propositions les plus mauvaises.

Forte de cette expérience, et ayant accompagné aussi quelques particuliers dont la boite mail a été piratée, j'ai revu ma copie en hébergeant mes propres mails, pour faire très simple :
- Une adresse perso
- Une adresse de sysadmin.

Et c'est tout, en gros… Mais la subtilité est que ces deux adresses ne sont jamais visibles ; j'écris toujours en utilisant un alias, et évidement je donne des alias à tout le monde. Ce n'est pas inutile ; j'ai rapidement vu les bots tenter de se connecter à mon serveur en utilisant comme identifiant admin@mondomain.net (haha, vous me prenez pour qui ? L'adresse peut recevoir et envoyer, mais elle ne permet pas de s'identifier !) et toute la litanie de mes alias. Au passage, un autre avantage de gérer son propre mail : les envois à alias_compromis@mondomain.net sont directement envoyés à la poubelle.

La vraie adresse n'est pas complètement cachée avec ma config, elle reste visible dans la source du mail, mais jusqu'ici personne ne regarde ça avec des intentions malveillantes. C'est limité, puisque je dois envoyer un mail à quelqu'un. Les personnes que je connais et qui sont des tanches sur la vie privée vont juste partager et utiliser l'alias visible ; et les bot qui parcourent le web à la recherche d'adresses qui traînent ne vont pas pouvoir faire plus que de m'envoyer un spam facile à filtrer. Certes, les moules trouveront sans mal le "vrai" mail… mais ce serait tordu d'aller le chercher pour me spammer. À noter, pour celles et ceux qui veulent être vraiment discrets, que quand on passe par un service comme addy.io (que j'utilise aussi, mais pas partout), l'adresse primitive semble bien complètement cachée. Jusqu'ici, très clairement, ces deux vraies adresses ne sont pas visés par les tentatives d'intrusions, et c'est rassurant.

Je me croyais maligne, et donc quand j'ai vu que l'envoi du spam se faisait avec l'adresse real_admin@, je me suis sentie vraiment mal. Comment, mais comment ? D'où l'indélicat avait trouvé ça ??? Et surtout, après avoir regardé le mail et sa source, je n'avais pas la moindre idée d'où chercher et comment corriger. En tout cas, ma conclusion était : je suis compromise à mort, et je ne sais pas jusqu'où, parce que cette adresse n'est pas simple à récupérer, et que le pirate semble se connecter avec tout ce qu'il faut.

Heureusement que j'ai d'autres mesures antispam sur mon serveur et entre autre : impossible d'envoyer trop de mails à la minute (pour être précis, 10/minutes, c'est déjà énorme mais comme je relaie des messages de notifications d'un forum, il a fallu que j'augmente un peu). Si bien que mon ip ne s'est pas trouvé blocklisté, ouf ; et que je n'ai pas trop envoyé d'horreurs à mon insu.

Le travail pour remonter d'où ça venait a été assez laborieux ces derniers jours. J'ai fouiné partout au petit bonheur, sans rien trouver. Grâce à un ami, j'ai enfin compris que dans mon mail, j'avais l'adresse ip de l'émetteur de base, qui n'était pas mon relai mail. C'est qui cette ip ? Ha… Un autre de mes serveurs. C'est pour ça que ça passait bien SPF, DKIM et DMARC. Un pauvre petit serveur que j'ai oublié de mettre à jour depuis trop longtemps parce que pas le temps… Je parie que le pirate a trouvé une faille dans ssh, et l'a transformé en forteresse zombie ou un truc du genre…

Mais en fait, non. Le serveur semblait assez sain, en dehors du fait qu'il avait servi de relai à du spam.

Je cherche, je cherche… comment ce spam a pu être envoyé ? Pour me guider, j'ai le mail que le pirate propose pour la réponse, et cette chaine de caractère doit bien être "quelque part". Je cherche dans /var/log, je cherche avec "journalctl -g maildouteux", rien…

Sur ce serveur, j'avais installé msmtp. J'aime beaucoup ce petit logiciel, qui permet de recevoir les mails systèmes et de faire fonctionner les scripts php, le tout sans trop de complexité. C'est évident qu'il est incriminé, puisque là, oui, dans la config, c'est bien précisé que c'est real_admin@ qui envoie (puisqu'il doit se connecter). Mais où se cachent les logs de msmtp ? J'ai déclaré ~/.msmtp.log comme chemin mais quel user a été compromis ? Je regarde tout ce qui est dans /home/*, dans /root/… rien de probant.

Je finis par lancer une recherche sur l'ensemble de la machine pour trouver tous les logs msmtp possibles. L'un après l'autre, ils me disent qu'il n'y a rien à déclarer. Et enfin… le dernier… "/var/www/.msmtp.log". Logique. Je n'ai pas pensé que www pouvait le stocker là. Et ça se confirme, c'est via www que ça spamme ! Grâce au log, je prend aussi conscience d'un truc étrange (mais rassurant) : il n'y a qu'une seule adresse mail visée par le spam, du type contact@site.org.

Ça sent le formulaire foireux. Et en effet en cherchant cette adresse mail là, je tombe rapidement sur un formulaire php avec un captcha moisi sur un des sites d'une personne avec qui je partage le serveur. Mon cher ami recevait pas mal de de spam depuis quelques mois, sans avoir vu que ça venait de chez nous. Forcément, vu les titres des mails dans un alphabet même pas latin, il n'a pas regardé loin et a juste classé ça en spam… faisant monter le score de mon relai chez son fournisseur, jusqu'à être déclaré personna non grata.

Là, j'ai recommencé à respirer. Parce qu'au final, ouais, ok, y'a eu un exploit, mais dont l'impact a été très limité. Du spam sur UNE adresse mail précise (et donc un seul fournisseur qui a finit par dire "hey, vous allez arrêter ?" ; je suis sacrément moins poli et patiente sur mon propre serveur avec les indésirables), en utilisant uniquement les faiblesses du web et sans réellement pénétrer la machine. Enlever le script php suffit… pour le moment. Et non, mon adresse real_admin@ n'a pas été réellement compromise, le pirate ne la connaît pas, pas plus que le mot de passe associé. J'ai quand même changé le tout (en premier, dans l'affaire)…

Plus de peur que de mal, donc, même si maintenant, il faut que je m'occupe de mettre ce serveur à jour avant que ce soit plus grave, et que je trouve un formulaire de contact moins exposé. Pour ce dernier point, je ne sais pas encore quelle piste explorer : les captchas se font toujours déborder, ça ne va pas s'améliorer avec les IA, et au final ça rend chèvre les humains sans vraiment épuiser la patience des bots.

Voilà pour mon aventure de la semaine. Il me reste encore à bien faire le tour du serveur pour être certaine de ne pas être passée à côté de quelque chose, mais… ça va mieux que quand j'ai reçu ce mail disant que j'étais une affreuse spammeuse.

En conclusion ? Ouais, ça occupe bien, le mail, par moment, et d'autant plus quand on partage avec d'autres…

  • # Toujours le web

    Posté par  (site web personnel) . Évalué à 5.

    C'est marrant, mais en lisant, je me suis dit "zyva, je suis sur que c'est un souci de wordpress". J'étais pas loin.

    Vu que tu as déjà du filtrage en sortie, le plus simple ne serais pas de s'interfacer à ce niveau ?

    J'imagine que tu as toutes les infos pour ça, l'IP du client, l'heure, etc, le nombre de mail envoyés, la connaissance du format du mail envoyé (donc l'encodage du titre du commentaire, etc).

    • [^] # Re: Toujours le web

      Posté par  (site web personnel) . Évalué à 3.

      C'est une excellente idée. Mon installation mail est encore imparfaite, et je n'avais jusque là pas pensé à filtrer ce qui pouvait ressembler à du spam en sortie. Je vais corriger ça :)

  • # On est dans le même club

    Posté par  . Évalué à 8.

    Pour l’instant je suis le seul utilisateur de mon serveur de mail, mais je ne ferme pas la porte.
    J’ai commencé a m’auto-hébergé depuis 2010 … 14 ans déjà !!!

    Au départ je n’ai pas mis en place toutes les protections «classiques» recommandés (fail2ban / amavis), j’étais plutôt permissif sur ce qui m’était envoyé et je n’ai mis en place que le greylisting. J’ai changé plusieurs fois de plateforme et de logiciel de serveur de mail, sans que ça change quelque chose.

    Je parle au passé mais même maintenant je n’ai rien mis en place … j’ai même enlever le greylisting. La différence est extrêment faible, j’ai du passer de 1 spam par mois à … 2 spam par mois.

    Mais ce qui me rapporte le plus de spam, c’est d’avoir ouvert mon entreprise et je reçoit pas mal de mail pour de la prospection.
    Le plus gros du travail était de me faire accepter par les gros fournisseur de mail, qui discutent bien entre eux, mais font la fine bouche au mail des «petits». Finalement prendre un VPN pour avoir une IP «propre» à été le plus efficace pour éviter d’être trop rejeter. Seul GMX est encore problématique.

    Bref, personnellement je trouve que une fois en place, les mail ça tourne pas mal tout seul. Je suis en train de tester NixOS et surtout «NixOs-mailserver» et je suis stupéfait de la facilité du truc. C’est pas encore idiot-proof, mais c’est quasiment du clé en main coté serveur, seul le coté DNS oblige a quelques manipulations qui peuvent paraître obscure, même si le manuel est pas mal fait.

    Coté «piratage», je n’ai eu que des mails qui me disaient que je l’était et que je devait payer en bitcoin rapidement. Mais rien de plus.

  • # Très chouette journal !

    Posté par  (site web personnel, Mastodon) . Évalué à 8. Dernière modification le 18 mai 2024 à 12:46.

    Merci pour ce chouette journal.

    J’en profite pour faire de la pub pour simplelogin.io, un logiciel qui permet de gérer les alias de son adresse mail.

    J’ai un domaine consacré à simplelogin qui me permet de donner une adresse différente à chaque fournisseur (de type fournisseur_année@mondomaine.net) et de désactiver au besoin afin de ne plus recevoir les myriades de mailings-listes et de "votre avis compte".

    Mes livres CC By-SA : https://ploum.net/livres.html

  • # Compte de service

    Posté par  . Évalué à 5.

    Chouette retour, merci !

    Comme ça je dirais que mettre en place un compte par service hébergé, genre "www-lepote-que-tu-herberges" pour un site web ou le fameux formulaire de contact, permet de remonter la chaîne plus facilement, et changer le mot de passe ou bloquer le compte en urgence n'impacte qu'un service.

  • # Authenticated sender

    Posté par  . Évalué à 5.

    La vraie adresse n'est pas complètement cachée avec ma config, elle reste visible dans la source du mail.

    Si tu parles de "Authenticated sender" et que tu utilises postfix tu as peut-être activé smtpd_sasl_authenticated_header. En le désactivant, cette information disparaît.

    • [^] # Re: Authenticated sender

      Posté par  (site web personnel) . Évalué à 3.

      Merci pour l'astuce ! Il y a tellement de possibilités dans postfix… je suis loin de maîtriser l'animal. je vais regarder ça, ce serait un petit plus sympa.

  • # SRSLY !

    Posté par  (site web personnel) . Évalué à 3.

    WTF !

    mon compte s'est fait hacker (en vrai ce serait cracker) !

    • [^] # Re: SRSLY !

      Posté par  . Évalué à 9.

      Je crois qu'en vrai ce serait cracké ;)

      • [^] # Re: SRSLY !

        Posté par  . Évalué à 0.

        Pour le coup, c'est plutôt raté

        • [^] # Re: SRSLY !

          Posté par  (site web personnel) . Évalué à 3.

          autant pour Voisin<, tant participe passé qu'infinitif pourraient conviendre^W convenir, autant aiolos< n'a jamais comprite la règle afférente :/

          en vrai, j'aurais mis crackaÿ :p

          • [^] # Re: SRSLY !

            Posté par  . Évalué à 2.

            C'est vrai, ça ! Autant (au temps) pour moi… Et en plus, je me suis fait plusser, au lieu de me faire pourrir ;)

  • # Contact

    Posté par  (site web personnel) . Évalué à 6.

    Pourquoi ne pas mettre un outil de ticketing plutôt qu'un formulaire de contact?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Contact

      Posté par  (site web personnel) . Évalué à 2.

      Je ne suis pas sûre de voir ce dont tu parle.

      Là on est sur des sites statiques, pur html sauf la page "contact" qui proposait un formulaire pour le contact en question. Est-ce que tu aurais des exemples d'alternative ?

      • [^] # Re: Contact

        Posté par  . Évalué à 2. Dernière modification le 25 mai 2024 à 10:39.

        Peut-être un lien mailto qui pointe sur une adresse dédiée ? Ça tu devrais pouvoir l'oublier quelques décennies

        https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Donner le bâton PHP pour se faire battre ?

    Posté par  (site web personnel) . Évalué à -5.

    Ça fait longtemps que je n'utilise pas PHP, ni en pro, ni en perso, autant pour des raisons de sécurité que de modernité.

    Pour les adresses email temporaires, je n'ai encore rien automatisé, du coup, je crée manuellement des alias jetables ou non, mais j'avoue que j'aimerais bien faire quelque chose d'un peu plus intelligent.

    Petit coup de pub au passage : https://homebox.space/

    • [^] # Re: Donner le bâton PHP pour se faire battre ?

      Posté par  (Mastodon) . Évalué à 10.

      Je vais jeter un caillou dans la mer, mais ça fait deux mauvaises raisons.

      • PHP n'est pas en soi mal sécurisé, pas moins que plein d'autres trucs, comme node.js pour n'en citer qu'un.
      • La modernité n'a du bon que si elle apporte quelque chose de bon.

      Si tu connais PHP, il n'y a aucune raison valable de ne pas l'utiliser pour tes propres besoins, en dehors de l'esprit de découverte.

      • Yth.
      • [^] # Re: Donner le bâton PHP pour se faire battre ?

        Posté par  (site web personnel) . Évalué à -5.

        PHP EST un language d'amateur, qui a évolué de façon chaotique, et qui traîne des erreurs de conception flagrantes pour des raisons de compatibilité.

        Si je devais aujourd'hui utiliser un framework, j'opterai pour un language comme Go ou Rust, qui ont un typage fort.

        Nodejs est basé sur JavaScript, à peine mieux que PHP, ou pire, selon le point de vue.

        • [^] # Re: Donner le bâton PHP pour se faire battre ?

          Posté par  (Mastodon) . Évalué à 10.

          Non.

          PHP est un langage de templating HTML qui a évolué - pour le meilleur et certainement pour le pire aussi - en langage d'application web.

          Alors que Javascript est un langage d'édition de contenu HTML/CSS directement dans le navigateur, et qui a évolué - pour le meilleur et certainement pour le pire aussi - en langage d'application web.

          Go et Rust ont un typage fort ce qui ne t'empêchera absolument pas d'écrire de la merde bourrée de faille de sécurité.

          Il n'y a rien qui t'empêche aujourd'hui (ou même il y a 15 ans en vrai) d'utiliser PHP correctement et efficacement.
          Au moins tu connais les défauts et tu sais t'en prémunir.
          Si tu connais PHP, mais ne va pas forcément l'apprendre si tu n'y connais rien, il y a de meilleurs choix à faire.

          • Yth.
        • [^] # Re: Donner le bâton PHP pour se faire battre ?

          Posté par  (site web personnel, Mastodon) . Évalué à 8.

          Petite correction, avec un PHP moderne, tu peux reformuler:

          Si je devais aujourd'hui utiliser un framework, j'opterai pour un language comme PHP, Go ou Rust, qui ont un typage fort.

          Le typage en PHP est une réalité de nos jours, on n'est plus bloqué avec PHP 5.3 ;)

        • [^] # Re: Donner le bâton PHP pour se faire battre ?

          Posté par  . Évalué à 9.

          On peut tout aussi bien dire "(GNU)Linux est un (OS)noyau d'amateur, qui a évolué de façon chaotique, et qui traîne des erreurs de conception flagrantes pour des raisons de compatibilité."

          Le fait est que PHP reste un outil utilisé de manière professionnelle, qui a énormément évolué depuis sa conception et que tu peux même utiliser un typage fort. Faire du crade en GO ou Rust est tout aussi possible.

        • [^] # Donner le bâton Web Form pour se faire battre ?

          Posté par  (site web personnel, Mastodon) . Évalué à 7.

          Mon petit doigt me dit que si tu implémentes le même algo et formulaire en Go ou en Rust on aurait le même souci. Le doigt voisin me dit que si tu sais faire correctement la page de contact en question, elle peut facilement se traduire en PHP par toute personne connaissant bien (j’insiste sur ce point) le langage honni et qui au passage a un typage très fort et plein de chouettes trucs pro depuis belles lurettes. Mon autre main me dit qu’il est plus facile de taper sur les outils que de remettre en cause les artisans, car c’est connu, avec super-tournevis Kevin-40deQI devient automagiquement expert

          “It is seldom that liberty of any kind is lost all at once.” ― David Hume

          • [^] # Re: Donner le bâton Web Form pour se faire battre ?

            Posté par  (site web personnel) . Évalué à 10.

            Mon petit doigt me dit que si tu implémentes le même algo et formulaire en Go ou en Rust on aurait le même souci.

            Absolument… Ici le souci ne vient pas du langage mais de la méthode d'implémentation, et ça se résume à ceci : avec les progrès techniques, le captcha et autres mécanismes anti-bot proposés dans le formulaire ont été dépassés.

            J'ajouterais quand même, à l'honneur du concepteur de ce petit script php, qu'il a tourné un moment sans aucun souci. L'erreur ici est celle de la sysadmin qui n'a pas mis de filtrage sortant sur ses mails pour bloquer le spam et en être avertie, et aussi celui du mainteneur du site web qui n'a pas mis la méthode à jour au fil du temps (mais à sa décharge, pour un site "vitrine", le but était un peu de l'oublier dans un coin tant qu'il permet aux gens de le trouver quand une recherche est faite). J'aimerais d'ailleurs bien trouver un remplaçant dans ce genre d'usage mais pour le moment tout ce que je trouve est trop complexe à mettre en place par rapport au besoin (je ne vais pas installer et maintenir un cms complet pour 3 pages quasi statiques) et a priori déficient par design (parce que ça s'appuie sur les captchas et que ça, je trouve que c'est dépassé).

            Et pour défendre php, ici on est pour moi dans le cas d'usage où, ben… si, c'est un langage adapté… Parce que l'usage est du "Personnal Home Page", pas un gros site gérant des milliards de vue avec des contraintes fortes. Du coup php c'est facile à mettre en place et maintenir (quand on s'en occupe un peu !). Ça ne m'embête pas de mettre autre chose, mais la question est "quoi" ? Et "est-ce que mon utilisateur peut appeler le bout de code au bon endroit sans devoir passer 5 ans à apprendre un langage ?". Ensuite je suis absolument agnostique sur le langage tant que ce dernier ne me rajoute pas trop de travail.

            • [^] # Re: Donner le bâton Web Form pour se faire battre ?

              Posté par  . Évalué à 8.

              Que ce soit dans la mauvaise expérience relatée dans le billet ou le commentaire ci dessus, je ne peux que retrouver mon propre itinéraire dans ce fameux bazar.

              PHP est le seul langage de programmation avec lequel je me sens relativement à l'aise, mais il faut dire que je l'ai abordé dès la version 4.0 soit en 2001 (je viens de regarder son historique sur sa page Wikipedia, j'y ai vu aussi qu'en 2022 PHP, c'était 78% de part de marché des langages de programmation côté serveur) en commençant d'abord par un CMS (Mambo en l'occurrence).

              J'ai eu, moi aussi, à subir les affres des formulaires pourris (spam du formulaire de contact, ou du "guestbook", incontournable à l'époque et, bien plus grave, plusieurs piratages/défaçages).
              Donc: apprentissage à la dure … Et prise de conscience: "il faut prendre la main".
              Passage par différents frameworks à partir de 2010 environ pour développer d'abord de petits sites +ou- dynamiques (pour des associations essentiellement) puis des trucs un peu plus costaud (toujours bénévolement). RAS, le Captcha ça le faisait bien.

              Aujourd'hui, surtout pour 3 pages quasi statiques, je ferais ça en PHP natif, je me passerais d'un ORM et écrirais les requêtes à la mano, utiliserais sqlite comme base de données, avec une appli publique (et que des requêtes GET) et une appli d'admin dans un répertoire protégé par un simple htacces+htpasswd … un truc KISS quoi

              "Si tous les cons volaient, il ferait nuit" F. Dard

              • [^] # Re: Donner le bâton Web Form pour se faire battre ?

                Posté par  (Mastodon) . Évalué à 4.

                Je te rejoins complètement :)
                Et ce qu'il peut se passer de pire, c'est que le petit truc dans un coin grossisse et que tu recommences tout avec peut-être une autre techno.

                Mais au moins, tu n'auras pas perdu de temps et d'énergie avec la version initiale simple et efficace.

                • Yth.
            • [^] # Re: Donner le bâton Web Form pour se faire battre ?

              Posté par  . Évalué à 5.

              Et pour défendre php, ici on est pour moi dans le cas d'usage où, ben… si, c'est un langage adapté… Parce que l'usage est du "Personal Home Page", pas un gros site gérant des milliards de vue avec des contraintes fortes.

              Pas comme wordpress.com, qui lui, a besoin d'un langage de programmation insérez un buzzword :).

              Une bande dessinée qui se moque gentiment des développeurs web qui veulent utiliser le dernier joujou

            • [^] # Re: Donner le bâton Web Form pour se faire battre ?

              Posté par  (site web personnel, Mastodon) . Évalué à 3.

              Ça ne m'embête pas de mettre autre chose, mais la question est "quoi" ? Et "est-ce que mon utilisateur peut appeler le bout de code au bon endroit sans devoir passer 5 ans à apprendre un langage ?".

              Appeler du code au sens programme/script qui fait des choses et envoie du résultat ? On peut revenir à CGI : ce n’est pas toujours plus compliqué (sauf si l’usager doit apprendre autre chose…) mais pas mieux non plus.

              Appeler du code au sens où on ne fait que de l’assemblage ? On pourrait regarder du côté des Server Side Include …si ton démon http supporte la fonctionnalité.

              (mais à sa décharge, pour un site "vitrine", le but était un peu de l'oublier dans un coin tant qu'il permet aux gens de le trouver quand une recherche est faite). J'aimerais d'ailleurs bien trouver un remplaçant dans ce genre d'usage mais pour le moment tout ce que je trouve est trop complexe à mettre en place par rapport au besoin (je ne vais pas installer et maintenir un cms complet pour 3 pages quasi statiques)

              Si c’est (quasiment ?) statique et qu’en plus il n’y a pas beaucoup de pages à maintenir, on peut s’orienter vers un Générateur de Site Statique : un quasi CMS local (donc le souci de gestion est déporté chez le/la webmestre) qui pond les fichiers statiques finaux (et du coup tu peux avoir un démon web qui fait moins —donc prend moins de place et a une surface d’attaque potentiellement plus réduite)

              Restera (que ce soit SSI ou SSG) la question du formulaire pour lequel je vois beaucoup de gens renoncer à la liberté de gérer le truc en déléguant. (dans cet esprit, il y a par exemple les gens qui branchent leurs pages sur Discuss pour la gestion des commentaires)

              “It is seldom that liberty of any kind is lost all at once.” ― David Hume

    • [^] # Re: Donner le bâton PHP pour se faire battre ?

      Posté par  (Mastodon) . Évalué à 4.

      Si je compends bien, seul le destinataire du formulaire de contact recevait le SPAM? Du coup il n'y avait pas vraiment de problème de sécurité lié au formulaire PHP selon moi.

      Le problème selon moi est:
      - que le destinataire du formulaire n'utilise probablement pas une addresse email dédiée pour cela.
      - qu'au lieu de simplement supprimer les spam, il les "marquait" comme SPAM.
      - qu'il n'y a pas de filtre en sortie de spam en sortie.

      Là où ça aurait été compliqué, c'est si le formulaire avait pu servir de relay pour n'importe quel destinataire. Pour cela du whitelisting de destinataires pourrait être mis en place sur le serveur postfix sur lequel tourne le formulaire.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.