Journal Des paiements non sécurisés ?

Posté par (page perso) .
Tags : aucun
27
4
oct.
2009
Cher journal,

On parle parfois ici de voyages-sncf.com et de Verisign quand leurs systèmes ne fonctionnent pas bien. J'ai un autre exemple à te proposer, qui a l'avantage d'être plus qu'un simple dysfonctionnement : un grave risque de sécurité des transactions financières, joyeusement ignoré depuis des semaines.

Ça se passe sur le site ouaibe des listes des mariage des Galeries Lafayette : http://fr2.lafayettelistes.com/bmgl/GL/gift/list_search.jsp . En HTTP simple, ça marche bien. Mais essayez donc en HTTPS…

Selon le navigateur – ou plutôt selon l'implémentation de SSL utilisée, je suppose –, cela donne deux résultats différents :
- le navigateur affiche un message d'échec de connexion ;
- le navigateur affiche une alerte de certificat non fiable.

En creusant un peu, on constate que :
- le premier cas est dû à un paquet anormal envoyé par le serveur (essayez avec « gnutls-cli -p 443 fr2.lafayettelistes.com ») ;
- le second cas est dû à un certificat auto-signé dans la chaîne de certification (essayez avec « openssl s_client -connect fr2.lafayettelistes.com:443 »).

Ce site en HTTPS est utilisé pour les transactions bancaires de paiement des cadeaux. Pour donner un numéro de carte bleue, devoir faire aveuglément confiance à un certificat SSL inconnu, c'est certes mieux que de n'avoir aucune sécurisation, mais ça la fout quand même mal, très mal.

Ce problème existe depuis au moins 3 semaines. Il a été signalé (par moi) :
- par le formulaire de contact du site des Galeries Lafayette, qui transmets le message à des employés de boutiques, qui n'en ont strictement rien à cirer ;
- au contact du WHOIS du domaine, donc l'adresse n'existe plus ;
- au bureau d'enregistrement du domaine – ainsi que l'obsolescence des information du WHOIS –, qui n'en a visiblement rien à cirer non plus.

Je pense que la plupart des internautes qui veulent offrir des cadeaux de mariage par les Galeries Lafayette ignorent simplement l'avertissement de sécurité, ce qui revient à nier toute précaution pour ses transactions bancaires. À votre avis, on fait quoi, face à un truc aussi énorme, et dont les responsables se moquent éperdument ?
  • # au contact du WHOIS du domaine, donc l'adresse n'existe plus ;

    Posté par (page perso) . Évalué à 4.

    "au contact du WHOIS du domaine, donc l'adresse n'existe plus ;"

    Ça veux dire qu'on peux récupérer le domaine non ? ;)

    « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

  • # Sécurité

    Posté par (page perso) . Évalué à 8.

    Qu'est-ce que la sécurité des transactions pour toi ?

    1/ le fait que la session soit cryptée pendant l'échange des informations ?
    2/ le fait que tes données bancaires soient traitées de manière sécurisée *après* que
    tu les aient fournies au site ?
    3/ le fait que tu soit sûr de "causer" aux galleries lafayettes ?

    Dans ton cas le 1 est toujours assuré, mais le 3 ne l'est "pas". Problème: les politiques
    d'attributions des certificats font que l'AC va vérifier que le certificat est bien émis aux
    propriétaires du domaine, pas que le domaine "lafayettelistes" appartient bien aux "galleries lafayette".

    Le gros soucis dans tout ces sites n'utilisant pas les offres de TPEV des banques est le point 2, et ça quelque soit la validitée du certificat, certes il y a des audits mais comment dire ...
    • [^] # Re: Sécurité

      Posté par (page perso) . Évalué à 5.

      Là, il y a deux problèmes :
      - on n'a aucune certitude que seul le site auquel on croit s'adresser reçoit les informations (il peut les recevoir ainsi qu'un homme au milieu) ;
      - dans le meilleur des cas, on donne son numéro de carte bancaire non pas à une banque pour qu'elle confirme aux Galeries qu'on a bien payé, mais aux Galeries pour qu'elles se servent.

      Le second point est hors du propos de mon journal, et explique que je refuse d'acheter quoi que ce soit chez Amazon, à la Fnac en ligne ou chez LDLC par carte bleue. Donne mon numéro de carte bancaire, ok, mais à une banque, pas à un magasin qui l'enregistrera pour des achats ultérieur ou pour Dieu sait quoi (oui, Amazon et la Fnac, ils l'enregistrent).

      Quant aux vérifications par les AC, il me semble qu'elles demandent tout de même des justifications comme des relevés de compte, pour intégrer le nom de la personne dans le certificat. De toute façon, pour le moment, ce que j'ai vu de plus sérieux comme vérification, c'était CAcert. La façon dont SSL est actuellement utilisée est complètement anormale, je trouve. Vérifier l'identité des gens, c'est le boulot des États.
      • [^] # Re: Sécurité

        Posté par . Évalué à 5.

        En général j'utilise la solution de carte virtuelle proposée par ma banque. Tu vas sur le site de ta banque, tu demandes un numéro de CB valable pour 1 transaction avec un montant fixé. Tu donnes ce numéro au site marchand, comme ça ils peuvent toujours l'enregistrer si ça les chante, ils ne pourront rien en faire après la transaction.
        • [^] # Re: Sécurité

          Posté par (page perso) . Évalué à 2.

          C'est une bonne chose. Dommage que ce soit inutilisable, en tout cas avec la Société Générale : il paraît qu'il faut Flash, et puis Windows ou MacOS X. Comme c'est payant, je ne vais pas m'amuser à tester si je risque de ne pas pouvoir l'utiliser.
          • [^] # Re: Sécurité

            Posté par (page perso) . Évalué à 8.

            Inutilisable par un libriste, pardon.

            Et même si j'étais équipé, si ce truc nécessite Flash, il exécute sur mon poste du code que je ne peux pas lire, pas question que je fasse confiance à un dispositif de sécurité que je ne peux pas vérifier.
            • [^] # Re: Sécurité

              Posté par . Évalué à 8.

              Pouvoir lire le code ne te garantie pas la sécurité, même si j'admets que c'est un plus.

              cf. http://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thomps(...)

              Ensuite le code du serveur auquel tu envoies tes données, tu ne peux pas le lire non plus de toute façon. Entre faire confiance à Adobe et faire confiance à une banque pour ne pas faire n'importe quoi avec tes données, je ne sais pas ce qui est le plus raisonnable, à mon avis c'est pareil.
      • [^] # Re: Sécurité

        Posté par . Évalué à 2.

        oui, Amazon et la Fnac, ils l'enregistrent

        Comment est-ce possible ?

        Je croyais que justement, le système de paiement sécurisé fait que seule la banque reçoit les données que je saisis...
        • [^] # Re: Sécurité

          Posté par (page perso) . Évalué à 6.

          Certains systèmes de paiement, oui. Typiquement, ceux qui te redirigent vers le site d'une banque le temps de payer, puis redirigent vers le site marchand.

          La Fnac, Amazon et quelques autres, pour payer, te demandent directement le numéro de ta carte, la date d'expiration et le prétendu « cryptogramme de sécurité », enregistrent ces informations, puis vont se servir auprès de la banque. Et ensuite, conservent ces informations dans leurs bases de données pour pouvoir se servir à nouveau la prochaine fois qu'ils le voudront.
          • [^] # Re: Sécurité

            Posté par (page perso) . Évalué à 2.

            C'est possible qu'ils stockent ces données en version chiffrée avec le mot de passe, et que le mot de passe soit stocké dans la base de données en somme de hachages.

            Mais ça m'étonnerais.

            Envoyé depuis mon lapin.

            • [^] # Re: Sécurité

              Posté par . Évalué à 9.

              Ca leur est contractuellement interdit - tous les contrats entre Merchants et Acquirer (je ne connais pas les termes français appropriés) imposent le repect de PCI/DSS ( [http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu(...)]

              Pour les Merchants ayant un gros volume, un audit externe est même imposé régulièrement.

              En pratique, c'est en général plutôt appliqué.
              • [^] # Re: Sécurité

                Posté par (page perso) . Évalué à 3.

                D'accord, je pensais que c'était fait comme le commerçant le voulait. Si c'est régularisé, c'est pas plus mal.

                Envoyé depuis mon lapin.

            • [^] # Re: Sécurité

              Posté par . Évalué à -3.

              Ca leur est contractuellement interdit - tous les contrats entre Merchants et Acquirer (je ne connais pas les termes français appropriés) imposent le repect de PCI/DSS ( [http://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Secu(...)]

              Pour les Merchants ayant un gros volume, un audit externe est même imposé régulièrement.

              En pratique, c'est en général plutôt appliqué.
              • [^] # Re: Sécurité

                Posté par . Évalué à -2.

                D'accord, je pensais que c'était fait comme le commerçant le voulait. Si c'est régularisé, c'est pas plus mal.
          • [^] # Re: Sécurité

            Posté par . Évalué à 2.

            Je sais pas pour la Fnac, mais amazon conserve bien une trace (peut être un hash).

            Du coup si quelqu'un utilise ta carte avec un autre compte tu reçois un mail (et je crois qu'ils bloquent la transaction), ça permet de détecter les fraudes (c'est déjà arrivé à une connaissance).
            • [^] # Re: Sécurité

              Posté par (page perso) . Évalué à 1.

              Une trace de quoi ? Que quelqu'un utilise ma carte bleue avec un autre compte Amazon, c'est un problème qui n'a rien à voir avec celui que je décris. Là, ce qui m'ennuie, c'est qu'Amazon conserve dans ses bases de données de quoi se servir sur mon compte. Le jour où ils se plantent, ou un de leurs programmes déconne, ou tout simplement s'ils se font pirater, c'est fichu.

              Ce système absurde peut être évité, en utilisant une banque comme intermédiaire, comme ça se fait sur les sites marchants sérieux.
              • [^] # Re: Sécurité

                Posté par . Évalué à 8.

                Là, ce qui m'ennuie, c'est que tu fasses aveuglement confiance à des banques, instituts qui par ailleurs viennent de nous foutre dans la pire crise financière depuis 1929, ruinant des millions de gens.

                les croire infaillibles ou incorruptibles me fait assez rire
              • [^] # Re: Sécurité

                Posté par . Évalué à 1.

                Là, ce qui m'ennuie, c'est qu'Amazon conserve dans ses bases de données de quoi se servir sur mon compte. Le jour où ils se plantent, ou un de leurs programmes déconne, ou tout simplement s'ils se font pirater, c'est fichu.

                Pas tout à fait, ils sont responsables, donc te doivent réparation de tous les dommages qu'ils ont pu te causer.
                • [^] # Re: Sécurité

                  Posté par (page perso) . Évalué à 3.

                  Peut-être, mais ça n'empêche pas des emmerdes en tout genre. De toute façon, ils n'ont pas besoin de retenir mon numéro de carte : ils ont choisi de le faire, moi je choisis de ne pas acheter chez de tels vendeurs, c'est plus sûr.
                • [^] # Re: Sécurité

                  Posté par (page perso) . Évalué à 3.

                  Pas tout à fait, ils sont responsables, donc te doivent réparation de tous les dommages qu'ils ont pu te causer.

                  Euh... non.

                  responsables, oui, mais je doute qu'ils soient reconnus comme tels au tribunal, et je doute encore plus qu'ils te donnent quelque compensation que ce soit !

                  C'est l'assurance de VISA (ou autre carte, ne soyons pas sectaires) qui prendra, pour le plus grand bonheur des payeurs de primes...

                  ... et ça, c'est nous \o/
                  • [^] # Re: Sécurité

                    Posté par . Évalué à 3.

                    mais je doute qu'ils soient reconnus comme tels au tribunal
                    Moi aucun doute.
                    et je doute encore plus qu'ils te donnent quelque compensation que ce soit !
                    Bien sur que si.


                    C'est l'assurance de VISA (ou autre carte, ne soyons pas sectaires) qui prendra, pour le plus grand bonheur des payeurs de primes...
                    L'assurance visa c'est quand ta cb est piraté, et elle se retourne vers les auteurs du piratage, qui sera (entre autre) amazon.
      • [^] # Re: Sécurité

        Posté par (page perso) . Évalué à -1.

        on n'a aucune certitude que seul le site auquel on croit s'adresser reçoit les informations (il peut les recevoir ainsi qu'un homme au milieu)

        Tu m'explique comment tu fais un MitM sur une connexion SSL sans voler la clé privée ?
        • [^] # Re: Sécurité

          Posté par (page perso) . Évalué à 8.

          Facile :
          1. tu génère un faux certificat avec les informations administratives de la vraie AC ;
          2. tu génères un sous-certificat, signé avec cette fausse AC ;
          3. tu génères un certificat pour le site, signé avec cette fausse sous-AC ;
          4. tu montes un proxy, qui déchiffre ce qui sort du vrai site et le chiffre avec ton faux certificat avant de l'envoyer au client.

          Vu du client, on voit alors un site chiffré, avec un certificat signé par ce qui ressemble à une AC, mais qui n'est pas dans la liste. D'où une alerte du navigateur. Exactement celle qui s'affiche avec le site des listes de mariage des Galeries.
          • [^] # Re: Sécurité

            Posté par (page perso) . Évalué à 1.

            Tu as l'alerte de sécurité justement, donc ça ne passe pas. Firefox est super chiant dans ce cas, mais ils ont parfaitement raison.

            Et non, il n'y a pas d'alerte de ce type concernant le site des galeries. La seule alerte qu'il y a est que seule une partie de la page bénéficie de la connexion SSL. Rien à voir avec une histoire de MitM.
        • [^] # Re: Sécurité

          Posté par . Évalué à 1.

          Si le certificat que tu reçois est auto-signé, tu n'a aucune idée que l'identité de l'émetteur du fameux certificat, qui peut aussi bien être les galeries lafayette, qu'un petit malin qui a fait du dns spoofing pour te rediriger vers sont site proxy enregistreur (Le fameux Man In The Middle).
          • [^] # Re: Sécurité

            Posté par (page perso) . Évalué à 0.

            Oui, mais en l'occurence, il ne l'est pas.
            • [^] # Re: Sécurité

              Posté par (page perso) . Évalué à 2.

              Il peut être signé par une fausse autorité.
              • [^] # Re: Sécurité

                Posté par (page perso) . Évalué à 1.

                En l'occurence, ce n'est pas le cas. Les signatures sont correctes, et le certificat de l'AC racine utilisé correspond bien à celui publié par AddTrust.
                • [^] # Re: Sécurité

                  Posté par (page perso) . Évalué à 2.

                  Maintenant, oui. Il y a quelques heures et depuis des semaines, non.
                  • [^] # Re: Sécurité

                    Posté par (page perso) . Évalué à 3.

                    L'effet magique linuxfr - acharnes toi des plombes pour montrer un problème à quelque prestataire... autant pisser dans un violon. Viens en causer sur linuxfr... le problème se règle.

                    En théorie.

                    Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

                    • [^] # Re: Sécurité

                      Posté par . Évalué à 10.

                      il faudrait essayer de faire un journal sur le site voyages-sncf
  • # dasn ton cas

    Posté par . Évalué à 10.

    Tu serre les fesses pour ne pas être attaquer en justice, pour terrorisme informatique. De temps en temps moi aussi je croise des petits probleme de securité un peu comme toi, des graves des pas graves. Un peu comme tout le monde je pense

    depuis moultes affaires judiciaires, de personnes qui souhaitent aider mais qui se trouve en garde a vue et dans les emmerdes judiciaires, j'ai pris le partie de ne rien faire et de fermer les yeux \o/

    bien evidemment je n'utilise plus du tout ces sites et ne donne jamais mon numero de carte bancaire avec eux.

    pour ton probleme je pense que le plus gros est de trouver un gars dans la société que tu as contacter qui comprenne de quoi tu parle. Le fils du directeur qui a été propulsé directeur informatique cherche encore dans "je monte mon site web pour les nuls" ce que veux dire WHOIS et certificat autosigné, peut etre bien https aussi (c'est plusieurs adresse http ?)
  • # Précision

    Posté par (page perso) . Évalué à 6.

    En fait, l'échec de connexion avec certaines implémentations vient de ce que le serveur envoie un bout de données en clair. Donc c'est doublement anormal, avec en plus le certificat qui est invalide.
    • [^] # Re: Précision

      Posté par . Évalué à 4.

      Il y a de plus en plus de site dont Firefox me signale qu'une partie de la page est en clair. (sfr par exemple)

      Je n'y connais rien mais je trouve ça dingue que ça puisse être possible !
      Quel est l'intérêt ? Avoir moins de donner à chiffrer ? S'ils mettaient moins de trucs à la con (genre pub flash) sur des pages qui devraient être simple et intelligible pour l'utilisateur, ils n'auraient pas à faire ça.
      Parce que là en attendant on ne sait pas ce qui est crypté et ce qui ne l'est pas.
      • [^] # Re: Précision

        Posté par (page perso) . Évalué à 3.

        Une pub flash, contrairement à une image avec un lien est comme une iframe. Il lui est tout à fait possible de regarder régulièrement ce qu'il y a dans le formulaire, et de le communiquer à d'autres serveurs.

        Peut-être que firefox est sécurisé, mais j'avais testé l'ouverture d'url à partir de flash du type javascript:code, et ça fonctionnait avec safari à une époque.

        Envoyé depuis mon lapin.

        • [^] # Re: Précision

          Posté par . Évalué à 7.

          flashblock \o/
        • [^] # Re: Précision

          Posté par (page perso) . Évalué à 3.

          Que ce soit en clair ou non ne change rien, pour le transfert d'infos à un tiers. C'est juste que la pub en flash NON SEULEMENT elle peut envoyer tes formulaires à la CIA si elle veut, mais EN PLUS, n'importe qui sur le chemin peut lire :-)

          Perso, sur mon site (cocorico), j'ai toutes les images en ''http'' et le data en https. (media.* n'est pas géré en https, car apache m'a grondé quand j'ai essayé de faire du virtualhost sur https... me suis pas acharné non plus, mais cela semblait ''mal''... bien que ça marchât....)
          • [^] # Re: Précision

            Posté par . Évalué à 7.

            Tiens, pour du virtualhost + https derrière une seule IP toute en respectant les standards :
            http://wiki.cacert.org/VhostTaskForce
            • [^] # Re: Précision

              Posté par (page perso) . Évalué à 1.

              Merci pour l'URL !

              [mode jepenseahautevoix]
              Mais philosophiquement, n'est-ce pas ''mieux'' de laisser ce qui est confidentiel de ce qui est ''public'' ?

              C'est vrai que les URLS sont normalement codées, et là, l'adresse media publie ces adresses via le referer...
              [/mode]

              Bon, donc re-merci pour l'URL !
  • # Chez Orange

    Posté par . Évalué à 10.

    Chez Orange c'est pas mal non plus, tu recharges ton compte avec CB via l'interface WEB, Orange t'assure que c'est sécurisé, mais mon Firefox il est pas trop de cet avis. (pas de HTTPS, pas de cadenas d'affiché...) : http://boris.geekjide.com/orange.jpg

    Je leur avait déjà envoyé un mail pour leur signaler que la connexion n'avait pas l'air chiffrée et savoir si ils pouvaient m'expliquer. Comme réponse ils ont dit que je pouvais recharger via mon mobile aussi...

    Ça à l'air grave quand même...
    • [^] # Re: Chez Orange

      Posté par (page perso) . Évalué à 0.

      J'ai reçu l'explication. Les responsable sécurité a été promu, il traite les appels de Madame Michu, cliente very super satisfaite, qui comprend pas pourquoi elle n'arrive pas à télécharger le dernier tube à la mode avec OpenOffice (une histoire de parefeu qui bloque son internet, qui depuis est passé au rouge au lieu d'orange preuve que ça ne marche pas...).

      D'ailleurs un certain Didier L. envisage de le sanctionner car il parait qu'il est pas satisfait le bougre...
    • [^] # Re: Chez Orange

      Posté par (page perso) . Évalué à 9.

      L'admin s'est suicidé...
    • [^] # Re: Chez Orange

      Posté par (page perso) . Évalué à 4.

      L'important, c'est que le form pointe vers une adresse en https, le formulaire lui-même n'a pas besoin d'être sécurisé, seulement l'envoi des données.

      Sur quoi pointe ce formulaire ?
      • [^] # Re: Chez Orange

        Posté par . Évalué à 3.

        Bien vu, effectivement, l'action du form est sécurisé :

        https://webclients.orange.fr/EcareAsGenerator/.....

        Mais ça reste quand même déstabilisant quand tu lis "Vous êtes en zone sécurisée" et que t'es en HTTP simple.
      • [^] # Re: Chez Orange

        Posté par . Évalué à 10.

        J'ai aussi déjà constaté ce problème et effectivement le formulaire contacte une page https. En plus le site d'orange abuse des frames (ce site est une calamité, entre le flash et les frames...), donc l'URL affiche toujours http dans le navigateur. Bref niveau ergonomie on fait mieux, obliger l'utilisateur à vérifier le code source pour s'assurer que la connexion est bien chiffrée ne me semble pas très sérieux.
      • [^] # Re: Chez Orange

        Posté par . Évalué à 4.

        L'important, pour l'aspect chiffrement de ssl uniquement, la partie authentification du serveur web... ben tu l'a une fois cliqué le bouton valider, donc trop tard.
      • [^] # Re: Chez Orange

        Posté par . Évalué à 10.

        La page n'étant pas authentifiée*, tu ne sais pas si une fois sur deux l'action du formulaire ne se transforme pas en pirate.example.com/.

        Si tu sais que des données en claire peuvent être interceptées, tu devrais aussi savoir qu'elles peuvent être modifiées (donc le formulaire peut l'être).

        Donc sauf si tu vérifies le paramètre action du formulaire à chaque fois que tu envois un formulaire, le formulaire lui même DOIT avoir été envoyé via SSL.

        SSL ça chiffre, mais ça sert aussi à identifier/authentifier, sinon ça sert à rien.
        • [^] # Re: Chez Orange

          Posté par . Évalué à 2.

          Vraiment très pertinent, je ne m'étais jamais posé la question sous cet angle. Au final quels sont les aguments pour ne pas chiffer le formulaire lui-même ?
          • [^] # Re: Chez Orange

            Posté par . Évalué à 5.

            C'est surtout la certification qui nous intéresse pour le formulaire. Sinon dans la pratique rien n'empêche un attaquant de proposer un formulaire vérolé pour récupérer son contenu puis de rediriger vers la vraie page https pour que l'utilisateur ne se doute de rien.
          • [^] # Re: Chez Orange

            Posté par . Évalué à 10.

            l'incompetence
            • [^] # Re: Chez Orange

              Posté par (page perso) . Évalué à 4.

              Quand ton formulaire est en page d'accueil, par exemple un formulaire de login, ça coûte du CPU/RAM/BP en plus d'être en SSL par rapport à la version non sécurisée, or tout le monde qui vient sur ton site ne va pas se logguer.

              C'est la même raison qui fait que certains services comme Gmail n'utilisent SSL que pour le login. (Oui, je sais, on peut être en SSL tout le temps avec Gmail, mais par défaut, c'est juste le login).

              Dans le cas présent, vu qu'il faut cliquer pour arriver à ce formulaire, oui, ils auraient pu le mettre aussi en SSL.
              • [^] # Re: Chez Orange

                Posté par (page perso) . Évalué à -1.

                Pour des boites de cette taille, il me semble qu'il y a des solutions matérielles de cryptage... pour ce qui mérite d'être crypté, ils pourraient le faire.

                Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

    • [^] # Re: Chez Orange

      Posté par (page perso) . Évalué à -2.

      Quelle est l'URL pointée par le formulaire?

      Parce que bon, on s'en fou un peu de la page où tu rentres les info soit protégée ou pas, il n'y a pas d'informations sensible qui sont envoyées (le serveur envoie juste le formulaire). Certes, c'est pas rassurant, car rien n'indique que la suite sera sécurisée alors que si tu passes de HTTPS à HTTP le navigateur te préviendra, pas si tu passes de HTTP à HTTP. Néanmoins, voir le sigle de sécurité sur la page que tu affiches n'est pas un gage de sécurité (c'est un "faux" sentiment de sécurité), c'est le "POST" qui vient ensuite qui est important.

      Bref, c'est quoi l'adresse appelée quand tu cliques sur "valider"? HTTP ou HTTPS?
      • [^] # Re: Chez Orange

        Posté par . Évalué à 9.

        c.f. http://linuxfr.org/comments/1070992.html#1070992

        > c'est le "POST" qui vient ensuite qui est important

        Il peut très bien y avoir un keylogger injecté dans la page (ou dans un des scripts de la page, ou dans un flash, etc), tu ne t'en rendra même pas compte.

        Les formulaires DOIVENT être en HTTPS au même titre que la cible du formulaire. Et c'est aussi le cas pour toutes les données de la page : Javascripts, Flash, etc. sinon le HTTPS est inutile.
        • [^] # Re: Chez Orange

          Posté par . Évalué à 1.

          HTTPS ne protège pas des keyloggers…
          • [^] # Re: Chez Orange

            Posté par (page perso) . Évalué à 4.

            Non, mais si tu es certain de t'adresser à Orange et que ta communication est chiffrée avec une clef symétrique qui n'a pu être déchiffrée qu'avec la clef privée d'Orange (bref, si tu es sur HTTPS correct), s'il y a un keylogger dans la page, ou si les informations fuient d'une façon ou d'une autre, tu es sûr que c'est la faute d'Orange.

            D'une façon générale, avec les systèmes de chiffrement et de signature, on n'est jamais sûr qu'on s'adresse à la bonne personne ou qu'elle est seule à pouvoir déchiffrer : ce dont on est sûr, c'est que si ce n'est pas le cas, c'est sa faute.
            • [^] # Re: Chez Orange

              Posté par . Évalué à -2.

              asymétrique
              (petite correction pour ceux qui n'auraient pas corrigé d'eux mêmes)
              • [^] # Re: Chez Orange

                Posté par (page perso) . Évalué à 5.

                Non, désolé, je persiste. Chiffré avec une clef symétrique générée par un échange utilisant une clef asymétrique du site.
                • [^] # Re: Chez Orange

                  Posté par . Évalué à 2.

                  Ok ça m'apprendra à parler d'un sujet que je ne maîtrise pas =)
                  La "clé symétrique" suivit de "clé privée" m'a enduit d'erreurs.
                  Toutes mes excuses.
    • [^] # Re: Chez Orange

      Posté par (page perso) . Évalué à 7.

      Comme tu peux le voir dans l'url de ta capture d'écran, le site d'orange FORCE à passer par une frame en HTTP en clair pour afficher le formulaire (qui est donc en HTTPS mais dans une FRAME en HTTP). C'est du grand n'importe quoi, car rien ne dis que la frame parente ne change pas l'url du formulaire au dernier moment ou autre truc rigolo.

      Mais ça semble être la mode, y'a un autre truc encore plus horrible, c'est la connexion soi-disant chiffrée dans un widget flash, par exemple : http://anothertime.skyrock.com/2153775481-Gadget-Pepita-Stor(...)

      On peut payer en CB, directement dans le widget flash, qui nous assure qu'il est bien sécurisé et tout, mais bon aucun moyen pour le client de le vérifier. C'est une vraie plaie. Ces clowns feraient mieux de retourner à faire de la VPC par minitel...

      « Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)

    • [^] # Re: Chez Orange

      Posté par . Évalué à 5.

      Chez Orange / France Telecom, les bon vieux techniciens sont recyclés dans les plateformes d'appels. Tout va bien.
    • [^] # Re: Chez Orange

      Posté par . Évalué à 2.

      J'ai fait la même remarque à Orange qui m'a répondu ....
      avec des instructions pour me connecter à mon espace sécurisé.

      BeOS le faisait il y a 15 ans !

  • # Journaliste

    Posté par . Évalué à 6.

    Tu fais un article sur Rue89 (c'est possible ?) ou bien tu en contactes un journaliste. Une fois le problème publié, ils vont vite corriger.
    • [^] # Re: Journaliste

      Posté par . Évalué à 8.

      ... et attaquer en justice juste après (cf l'affaire Zataz récemment).
    • [^] # Re: Journaliste

      Posté par . Évalué à -2.

      J'ai pensé à la même chose... Envoyer un petit mail à Rue89, je pense qu'il se feront un plaisir de publier ce genre de trucs !
      Par contre, tu as tout intérêt à te débrouiller pour envoyer ce mail de manière anonyme (genre exim derrière tor). Dans ce cas, ce n'est pas sur que Rue89 accepte d'endosser la responsabilité, mais ça vaut le coup d'essayer.

      C'est quand même assez affligeant de voir où on en est rendu. Pas étonnant que les gens soient suspicieux face au paiement sur Internet. Mais c'est dommage que ce soit à cause de la totale incompétence technique de certains administrateurs...
      • [^] # Re: Journaliste

        Posté par (page perso) . Évalué à 3.

        Pour envoyer un message à Rue89, je devrais me rendre anonyme ? Ils sont du genre balance ?
        • [^] # Re: Journaliste

          Posté par (page perso) . Évalué à 1.

          Mais surtout, n'oublie pas dans ton courrier anonyme de citer le fil de discussion, ils pourraient y trouver martère pour l'article :-)

          Python 3 - Apprendre à programmer en Python avec PyZo et Jupyter Notebook → https://www.dunod.com/sciences-techniques/python-3

      • [^] # Re: Journaliste

        Posté par . Évalué à 5.

        Enoyer un mail anonyme, proxy toussa en laissant le journal indexé entre autre par google avec son nom sur dlfp ? Ça m'a l'air utile ...
  • # Les galeries de l'insécurité ?

    Posté par (page perso) . Évalué à 10.

    Décidément, les galeries ne font pas dans la sécurité ...

    Il y a peut, de temps, j'étais tombé sur un lien, via Twitter. Les galeries Lafayette laissent en ligne le front controller de développement d'une application Symfony.

    cf : http://www.galerieslafayette.com/carnetmode/frontend_dev.php

    Je vous laisse admirer les requêtes sql etc ;)
    • [^] # Re: Les galeries de l'insécurité ?

      Posté par . Évalué à 4.

      Han, mais c'est du hacking ça, tu vas aller en prison ;)
    • [^] # Re: Les galeries de l'insécurité ?

      Posté par . Évalué à 2.

      C'est d'autant plus fabuleux que le front controller de développement d'une application Symfony n'est accessible par défaut que depuis l'hôte local.
      • [^] # Re: Les galeries de l'insécurité ?

        Posté par . Évalué à 1.

        En même temps, quand on développe le site des Galeries Lafayette, on ne doit pas être tout seul sur son WAMP...
        Donc c'est normal que le front controller soit accessible depuis une autre machine.
        Accessible publiquement depuis Internet par contre, je suis d'accord que ce n'est pas normal.

        C'est un peu comme MySQL... par défaut, le serveur n'est accessible que depuis l'hôte local.
        Mais généralement on ouvre son accès depuis n'importe quelle machine, et on contrôle les accès au niveau du pare-feu du réseau.
        • [^] # Re: Les galeries de l'insécurité ?

          Posté par . Évalué à 5.

          En même temps, quand on développe le site des Galeries Lafayette, on ne doit pas aller le faire directement en prod...

          Le coup du frontend_dev accessible uniquement depuis localhost c'est récent je crois (1.2), là c'est un Symfony 1.0 qui est déployé. Pour ma part j'avais même pas remarqué que ça se faisait, je viens tout juste d'aller voir le bout de code qui le fait.
    • [^] # Re: Les galeries de l'insécurité ?

      Posté par (page perso) . Évalué à 3.

      là aussi c'est joli
      http://fr2.lafayettelistes.com/
      on peut (à priori) rien faire avec, mais c'est pas fort sérieux ... et il faut même pas chercher pour tomber dessus
  • # Va en justice

    Posté par . Évalué à 2.

    A ta place, je leurs collerais un procès tout de suite.

    A cause d'eux, tu t'es introduit dans un système de données automatisé (certes, dans le but de comprendre d'où venait le problème) sans en avoir l'autorisation préalable.

    Hé oui, cela s'appelle de l'incitation à commettre un délit, et c'est sévèrement puni en France.

    Faut se couvrir. On est jamais assez trop prudent, de nos jours.
    • [^] # Re: Va en justice

      Posté par (page perso) . Évalué à 2.

      Introduit ? Je me suis introduit dans quoi ? J'ai été voir un site web, avec Iceweasel, avec Epiphany, avec wget, links, telnet, openssl s_client puis gnutls-cli. C'est consulter des informations publiques, ça.

      Si ça, c'est un délit, alors consulter quelque site web que ce soit en est un aussi. Allez hop, tous en prison.
      • [^] # Re: Va en justice

        Posté par (page perso) . Évalué à 4.

        En revanche, ce qui est un délit, et un vrai, c'est de ne pas sécuriser les données qu'on détient. :-)
      • [^] # Re: Va en justice

        Posté par . Évalué à 6.

        Oui, bon, tout ça, c'est pas très internet© d'Orange, de loin on dirait des outils de pirate.

        (Je fais juste un peu d'humour, c'est tout. Le prends pas mal !)
      • [^] # Re: Va en justice

        Posté par . Évalué à 4.

        Cela dit, consulter un FTP public est un délit.
        Et pour le coup, n'importe quelle madame michu peut le faire, simplement avec son Firefox, en cliquant sur un lien.

        Les gnutls et autres outils... vas-y expliquer au juge...
        Il va voir une ligne de commande, il va paniquer et t'envoyer à Guantanamo, te prenant pour un dangereux pirate, comme ceux qu'on voit dans les films.
  • # Aucun problème de certificat

    Posté par (page perso) . Évalué à 3.

    le second cas est dû à un certificat auto-signé dans la chaîne de certification

    Oui, et ?

    Les Autorités de Certification (AC) fonctionnent sur un principe hiérarchique. On a :
    1. une AC racine forcément auto-signée (ici AddTrust External Root) ;
    2. une sous-AC signée par l'AC racine (ici UTN - DATACorp SGC) ;
    3. le certificat du site (fr2.lafayettelistes.com).

    Il est parfaitement normal que le certificat de l'AC racine apparaisse auto-signé. C'est la définition même d'une AC racine. Ce n'est en aucun cas une erreur.

    Le message d'openssl vient du fait que tu n'indique aucune liste de certificats de confiance (liste qui devrait contenir le certificat, comme Firefox le fait par exemple).

    Beaucoup de bruit pour rien.
  • # Problème réglé

    Posté par (page perso) . Évalué à 3.

    Autant que j'ai pu le voir, ce problème est maintenant réglé. J'espère que c'est suite aux messages que j'ai finalement pu (laborieusement) leur adresser.

    Un truc étrange, ceci dit :
    % gnutls-cli --port 443 --insecure fr2.lafayettelistes.com
    Resolving 'fr2.lafayettelistes.com'...
    Connecting to '195.6.224.39:443'...
    *** Fatal error: A TLS packet with unexpected length was received.
    *** Handshake has failed
    GNUTLS ERROR: A TLS packet with unexpected length was received.
    • [^] # Re: Problème réglé

      Posté par . Évalué à 2.

      j'ai souvent ce genre d'erreur avec gnutls-cli, alors que ça passe parfaitement avec openssl s_connect....

      Cela dit je n'ai jamais bien compris pourquoi ;-)
  • # Le cas Virgin

    Posté par . Évalué à 1.

    Un mail reçu ce matin pour mon abbo mobile :

    Votre facture N° XXXXXXXXXXXXXX du 06/10/09 concernant votre ligne XXXXXXXXXX vient d'arriver dans votre Espace client, rubrique " Ma formule". Vous pouvez la consulter en cliquant ici.

    Le montant de XX,XX euros sera prélevé à partir du 09/10/09

    Votre facture est à l'abri des regards indiscrets: munissez-vous de votre numéro d'appel Virgin Mobile et de votre mot de passe, le XXXX , pour consulter vos factures, mais aussi pour suivre vos consommations, vos points VIP, modifier vos coordonnées, etc.... Bref, pour gérer votre compte en quelques clics.


    Les infos de connections (n° de tel et mot de passe) sont tous précisés dans ce mail qui est bien sûr transmis en clair.

    Avec ces infos on a accès au nom de l'abonné, son adresse, ses infos bancaires...

Suivre le flux des commentaires

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