Erf

• [^]Re: Erf

  Posté par ploum (page perso, ) le 13/08/2008 à 16:39. (lien). Évalué à 5.

  Il semblerait que la correction dans la 1.5.6 soit :
  [code]
  if(strlen($token) != 32) {
  $this->setError(JText::_(’INVALID_TOKEN’));
  return false;
  }
  [/code]
  
  Cela me semble très bête parce qu'un simple '''''''''''''''''''''''' (32 fois ') permettrait de continuer à utiliser la faille.
  
  Enfin, ça ne me réconcilie pas avec Joomla parce ce que j'estime que ce genre d'erreur est vraiment évitable. (Bordel, on escape tous les formulaires qu'on reçoit avant de faire une requête quand même)

  • [^]Re: Erf

    Posté par Slainer (Jabber id, page perso, ) le 13/08/2008 à 18:40. (lien). Évalué à 2.

    Mouais.
    
    C'est le genre de choses qui arrive souvent dans les CMS qui ont été commencés y a des années, avec du code pas du tout objet, sans tests unitaires ni fonctionnels...

    • [^]Re: Erf

      Posté par Kerro () le 13/08/2008 à 19:35. (lien). Évalué à 7.

      qui ont été commencés y a des années
      Je ne vois pas le rapport :-)
      
      avec du code pas du tout objet
      Là non plus.
      
      sans tests unitaires ni fonctionnels
      Là par contre, je vois :-)

      • [+] [^]Re: Erf

        Posté par Elie () le 13/08/2008 à 20:29. (lien). Évalué à -1.

        Si si moi je le vois le rapport, railers en vues (:

        --
        abrutir son prochain deviens tellement commun.

  • [^]Re: Erf

    Posté par ben (page perso, ) le 13/08/2008 à 20:35. (lien). Évalué à 0.

    Ça doit pas être que ça parce que en mettant '''''''''''''''''''''''''''''''' (32*') je n'ai plus le formulaire Réinitialiser votre mot de passe. D'ailleurs, je me demande pourquoi ceci ne marche pas...

    --
    "I must create a system or be enslaved by another man's." William Blake

    • [^]Re: Erf

      Posté par benoar (Jabber id, ) le 13/08/2008 à 21:54. (lien). Évalué à 0.

      Peut-être parce que ça crée un erreur de syntaxe SQL ? En plus, ça fait au final un nombre impair de "'" (voir le 2e lien pour le code).
      Peut-être qu'un :
      ';xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
      marchera ?...

      • [^]Re: Erf

        Posté par ben (page perso, ) le 13/08/2008 à 22:35. (lien). Évalué à 0.

        Non, ça marche pas non plus. Ni '//xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

        --
        "I must create a system or be enslaved by another man's." William Blake

  • [^]Re: Erf

    Posté par André Rodier (page perso, ) le 13/08/2008 à 21:09. (lien). Évalué à 1.

    Bordel, on escape tous les formulaires qu'on reçoit avant de faire une requête quand même
    
    Il est primordial d'utiliser une fonction de validation et d'épuration des données saisies par l'utilisateur, avant de les soumettre à une base de données.

    • [^]Re: Erf

      Posté par Zenitram (page perso, ) le 13/08/2008 à 21:45. (lien). Évalué à 2.

      Oui, mais bon, ça me gonfle aussi les épuration à la con, genre interdire les mots de passe de plus de 8 caractère, ou les chiffres, ou les accents, ou les caractères spéciaux (exemples vécus, sur des sites "importants", et le plus rigolo est quand même un site de purs geeks programmeurs comme Sourceforge : "passwords should contain only letters and numbers. Inclusion of other characters in your password may result in inability to access some SourceForge.net systems" suivi, si tu ne suis pas le "may", à croire que je ne comprend plus l'anglais ce que je comprend comme un conseil n'étant alors pas un conseil, de "Please use only letters (A-Z, a-z) and numbers (0-9) in your password" si tu dévies de la recommandation. Super le mot de passe fiable...)
      
      Bref, il est primordial d'utiliser une fonction de validation et d'épuration des données saisies par l'utilisateur correcte et non limitative.

      • [^]Re: Erf

        Posté par PsychoFox () le 14/08/2008 à 11:51. (lien). Évalué à 0.

        euh autant une limitation du nombre de caractère est chiant, autant le fait de ne pas autorisé tous les caractères n'empêche pas de créer des mots de passe fiables. Il suffit qu'ils soient suffisemment long et non proches de nom communs.

  • [^]Re: Erf

    Posté par skud () le 14/08/2008 à 08:13. (lien). Évalué à 7.

    J'ai regardé le code de la faille, ça n'a rien à voir avec de l'échappement. En mettant # à la place de ' ça marche aussi, et en laissant une chaîne vide ça marche également (à condition de désactiver javascript dans le navigateur).
    
    Les requêtes SQL sont correctement échappées dans Joomla et les saisies de formulaires sont vérifiés.
    Le problème est que le fameux code qui être saisi est normalement composé que de lettres et de chiffres. Joomla nettoie ce code en supprimant tout ce qui n'est pas lettre ou chiffre puis effectue un échappement.
    
    Le déroulé de la faille est le suivant:
    o saisie par exemple du token: ###{{}{}
    o nettoyage par Joomla: le token devient une chaîne vide
    o échappement par Joomla de la chaîne vide
    o Le code SELECT id FROM #__users WHERE block = 0 AND activation = '.$db->Quote($token) devient SELECT id FROM jos_users WHERE block = 0 AND activation = ''
    o La colonne activation de la table SQL est vide pour un utilisateur n'ayant pas demandé la réinitialisation de son mot de passe, d'où le bug et son code de correction.
    
    Donc oui, la faille aurait du être évitée, mais ce n'est pas non plus aussi trivial que ça.

• [^]Re: Erf

  Posté par Matthieu C () le 13/08/2008 à 22:30. (lien). Évalué à 2.

  Pour ma culture, il y a vraiement des applis php qui n'ont pas/peu de faille de secu ?
  
  Parce que bon on retrouve toujours le même genre d'erreur ; pas de validation des données entrantes...

  • [^]Re: Erf

    Posté par Victor STINNER (page perso, ) le 14/08/2008 à 00:51. (lien). Évalué à 2.

    PHP est très souvent accompagné de MySQL. Or MySQL est mal configuré par défaut : tout est autorisé, même LOAD_FILE et INTO OUTFILE. De plus, échapper une chaîne d'octets (PHP ne gère pas Unicode) pour la passer à MySQL n'est pas toujours évidant car le charset du site web peut-être différent de celui de la base de données (il existe mysql_escape_string et mysql_real_escape_string ...) :
    http://www.abelcheung.org/advisory/20071210-wordpress-charse(...)
    
    Pour info, d'autres failles liées à Unicode :
    http://www.haypocalc.com/blog/index.php/2008/01/26/124-faill(...)
    
    Je pense que n'importe quelle application utilisant des fonctions haut niveau pour gérer l'accès à la base de données (MySQL ou autre), peut se protéger des injections SQL.
    
    Euh... on parlait de PHP ? Ah mince.
    
    Je pense que le « problème » de PHP est qu'il est trop facile à utiliser et que n'importe quel quidam sans aucune notion de sécurité peut écrire et publier son site web. La majorité des développeurs préfèrent réécrire leur CMS troué que d'utiliser un CMS testé et éprouvé.
    http://blog.halon.org.uk/geek/debian/security/php_clippy.htm(...)
    
    Au moins avec le C, on n'a pas ces problèmes.

    • [^]Re: Erf

      Posté par skud () le 14/08/2008 à 08:19. (lien). Évalué à 0.

      
Au moins avec le C, on n'a pas ces problèmes.

      
      Tu as parfaitement raison ! Regarde le noyau, dont une bonne partie est écrite en C par des débutants qui ne font aucun test unitaire, on n'y a jamais découvert la moindre faille.
      
      La morale est que toute application a des failles.

      • [^]Re: Erf

        Posté par ciol () le 14/08/2008 à 12:49. (lien). Évalué à 4.

        Je crois que c'était ironique.