Journal C'est pas une faille d'IE ça ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
4
fév.
2006
Je suis tombé ce soir sur http://www.securityfocus.com/bid/5798/info
Je ne me souviens pas que cette faille nous ait été signalée à l'époque mais bon passons...

J'ai regardé de plus près. Ce qui est reproché est que l'on acceptait des dépêches contenant <IMG SRC="javascript:alert('unsecure')">.

Je me suis dit, les navigateurs n'exécuteraient quand même pas un tel code ? Et bien Internet Explorer le fait. Ça résulte toujours en une image cassée bien sur.

En cherchant un peu, il semble que ça serve très souvent à exploiter d'autres failles. Ca n'a l'air de déranger personne...

La faille serait donc dans tout les sites qui laissent passer ce code que IE exécute alors qu'il ne peut que créer une image invalide (à moins bien sur de mettre javascript:this.src=uneurl mais ça ne sert pas à grand chose...) et non pas dans IE ?

J'ai un peu de mal à comprendre...

  • # Tien, une idée...

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

    Merci de cette petite idée...

    Maintenant je vais pouvoir pourrir la vie de mes utilisateurs qui osent encore venir avec IE sur mon site ;)



    Amis utilisateurs de IE copain...

    Remarque a sois-même, ça pourrais servir a mettre un logo anti-ie ou d'autre truc qui marchent a chaque coup...

    • [^] # Re: Tien, une idée...

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

      Oui, enfin il y a des méthodes plus simples, hein...

      <input type crash>

      • [^] # Re: Tien, une idée...

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

        Je viens de l'essayé au boulot et c'est marrant, quand j'enregistre le fichier, j'ai une alerte de norton:
        Type d'analyse : Analyse Auto-Protect
        Evénement : Menace trouvée !
        Menace : Trojan.CrashIE


        Une autre qui marche bien aussi:

        <html>
        <STYLE>
        .supp IMG {
        VERTICAL-ALIGN: middle
        }
        </STYLE>
        <P><A <It>.</P>
        <DIV class="supp"> <A><IMG>
        </html>

  • # Question existentielle

    Posté par  . Évalué à 3.

    Es-ce que ça marche aussi pour le VB-script ?

    =>[]

  • # vbscript

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

    ça passe aussi avec du vbscript...
    Sinon, cette faille XSS a été corrigée dans les versions récentes de Templeet, le module cuthtml en particulier, et ce code est directement nettoyé. (Ok, on parle de daCode, mais comme c'est un morceau de daCode repris par Templeet)

    • [^] # Re: vbscript

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

      Ok, on parle de daCode, mais comme c'est un morceau de daCode repris par Templeet

      Non, cuthtml a été codé par Pascal à partir de rien. Mais qui effectue une fonction qui fait la même chose se rendra compte du nombre d'emmerdes potentielles quand on écrit un bout de code pareil, en gros avoir la possibilité d'afficher un nombre de caractères affichables d'une longueur spécifié, sans compter les caractères non affichables, sans compter les &...; comme plusieurs, etc.

  • # Journal : C'est pas une faille d'IE ça ?

    Posté par  . Évalué à 10.

    Journal : C'est pas une faille d'IE ça ?


    Non, c'est une feature.

  • # XSS et consorts

    Posté par  . Évalué à 4.

    Disons que désormais, dès lors que tu autorises du HTML dans un formulaire, la chose apparaît comme une faille aux yeux de certains. Parce qu'avec du HTML, on peut amener certains navigateurs à donner tout et n'importe quoi et transmettre tout et n'importe quoi

    Évidemment, on peut se demander si corriger les navigateurs ne serait pas une solution. Mais comme souvent, corriger le fautif client n'est pas vraiment possible, question de proportion et de volonté. Donc la seule solution est... d'interdire tout HTML.
    Aussi pénible que ça puisse paraître, il faut inventer une surcouche au HTML pour au final autoriser le HTML, pour être sur que le HTML ne contienne que des éléments que les navigateurs n'exploitent pas n'importe comment.

    C'est plus ou moins la conclusion que pour Savane on a tiré de https://gna.org/forum/forum.php?forum_id=1067 pour en arriver à https://gna.org/task/?func=detailitem&item_id=2874

    • [^] # Re: XSS et consorts

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

      Filtrer des éléments simples tels que b, u, s, em est très simple et pas un problème en soit. Et même avec une syntaxe comme [url=javascript:alert('XSS')] tu peux tomber dans des failles de XSS (phpBB...).
      La surcouche au HTML est donc absolument redondante, à moins d'offrir une syntaxe différente et plus agréable pour une catégorie d'utilisateurs, par exemple la syntaxe wiki.

      • [^] # Re: XSS et consorts

        Posté par  . Évalué à 2.

        Filtrer des éléments simples est peut-être simple mais ça ajoute une opération supplémentaire. Au final, ça reste une surcouche. Quand au fait qu'elle soit plus agréable, ça se discute.

      • [^] # Re: XSS et consorts

        Posté par  . Évalué à 2.

        Je ne vois pas trop en quoi la syntaxe wiki est plus agréable. On pourrait faire exactement la même chose en utilisant des < et > plutot que des [ et ] avec l'avantage que ça ressemble un peu plus à du HTML.

        En prime, la syntaxe wiki n'est pas très claire; comment fait-on pour mettre du texte entre crochets ? Pour représenter un < en html, on sait clairement ce qu'il faut faire.

  • # Pourquoi IE ?

    Posté par  . Évalué à 1.

    En quoi est-ce une faille d'IE ?

    IE affiche la page qui arrive, que la page ait ete creee par l'administrateur de linuxfr.org(qui pourrait ecrire ca lui-meme) ou un utilisateur n'y change rien. Mettre du javascript dans IMG SRC ne cause aucun probleme connu que je sache, bref, l'utilisateur pourrait mettre n'importe quel javascript, il s'executera tout comme si IE avait visite une autre page avec ce javascript ailleurs, rien de tres important.

    Au pire, c'est une faille du site web permettant au jour d'aujourd'hui du cross-site scripting(permet a l'utilisateur d'injecter son propre code sur le site et faire croire aux autres utilisateurs qu'ils sont sur un autre site ou autre, ...)

    Le coup du IMG SRC donne en exemple n'est qu'un exemple, il y a problablement d'autres cas, il voulait simplement signifier l'absence de filtrage a mon avis.

    • [^] # Re: Pourquoi IE ?

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

      Il n'y avait en effet pas de filtrage sur le src des img, et il aurait fallu verifier que c'est une url valide. Ca n'empeche pas que je ne vois pas pourquoi IE execute du code la ou il devrait y avoir l'url d'une image.

      Tu peux me citer un exemple où il est utile d'executer du code à cet endroit là (à part la majorité des exploits d'autres failles) ?

      • [^] # Re: Pourquoi IE ?

        Posté par  . Évalué à 1.

        Attention, je dis pas que c'est une fonctionnalite utile, ou autre.

        Si ca se trouve, c'est meme peut-etre un bug de fonctionnalite d'IE(qui sait, peut-etre que la RFC l'interdit), cependant ce n'est pas une _faille_ d'IE.

        Que le javascript soit execute en etant place en IMG SRC ou autre, pour IE ca ne change rien, la javascript a le meme acces et permissions, raison pour laquelle ce n'est pas une faille de securite d'IE.

        Le gars se plaint du fait que qq'un pourrait injecter du code javascript dans une page DaCode si sa depeche est acceptee(si j'ai bien compris), il se plaint pas que ce soit place dans IMG SRC ou autre.

        • [^] # Re: Pourquoi IE ?

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

          Ben si, il se plaint que l'on ne filtre pas la balise src de l'img.
          Accepter d'executer du code à un endroit ou il ne devrait pas y en avoir est pour moi une faille. Après que l'appli ne vérifie pas qu'il n'y en ait pas la ou il ne doit pas y en avoir, c'en est une aussi mais moins grave puisque le code n'est pas censé etre executé. Le pire c'est que ce code est executé sans action de l'utilisateur...

          Pourquoi IE accepte javascript: dans le src d'une image, et pas par exemple dans un style=, ou tout autre attribut ? Ca aurait aussi peu de sens dans les différents cas, donc pourquoi avoir codé celui la qui est aussi inutile que les autres et tout aussi dangereux ?

          Cela revient pour moi au même que si j'avais appris que <tt>javascript:...</tt> était executé comme si <tt> avait été <script>...

          • [^] # Re: Pourquoi IE ?

            Posté par  . Évalué à 2.

            Ben ce n'est pas une faille parce que :

            Que le javascript soit dans un IMG SRC= ou ailleurs dans la page, il a le meme effet.

            Bref, si IE devait interdire le javasrcipt dans IMG SRC= pour se premunir d'une quelconque attaque, ca serait totalement inefficace vu que le javascript peut etre ailleurs et etre execute automatiquement.

            Bref, du point de vue de IE, que le javasrcipt soit dans IMG SRC= ou ailleurs ne fait aucune difference du point de vue securite, c'est la meme chose que si le code etait ailleurs.

            • [^] # Re: Pourquoi IE ?

              Posté par  . Évalué à 1.

              Bref, du point de vue de IE, que le javasrcipt soit dans IMG SRC= ou ailleurs ne fait aucune difference du point de vue securite, c'est la meme chose que si le code etait ailleurs.


              Le problème n'est pas là.

              Si un utilisateur d'un site réussis à placer javascript:quelquechose dans le code HTML et que ce code est éxécuté, il peut récupérer le cookie des autres utilisateurs ou le contenu de la page par exemple => faille XSS.

              Donc les sites en général n'autorisent pas le HTML, utilisent des tags genre [url=http://url] ou [img=http://img] et en filtrent le contenu.

              Mais comme un code javascript n'est pas censé s'exécuter dans une balise IMG, le site ne filtre pas forcément le contenu de [img=], et les utilisateurs de IE sont vulnérables à ce genre d'attaques.

              ça n'empêche pas le site de corriger le problème, mais c'est une faille de IE.

              • [^] # Re: Pourquoi IE ?

                Posté par  . Évalué à 5.

                Ben je suis alle jeter un oeil au w3c : http://www.w3.org/TR/WD-script-970314

                Et parmis les exemples donnes :

                This last example shows how SGML CDATA attributes can be quoted using single or double quote marks. If you use single quotes around the attribute string then you can include double quote marks as part of the attribute string. Another approach is use " for double quote marks, e.g.

                < IMG SRC="&{logo(manufacturer("widget"))};" >

                Bref, confirmation qu'IE ne fait rien de faux. Javascript est visiblement autorise dans IMG SRC

                • [^] # Re: Pourquoi IE ?

                  Posté par  . Évalué à 1.

                  Je ne suis pas vraiment d'accord avec toi, ici on parle d'utilisation de Script Macros, avec une syntaxe précise, et le paragraphe commence par "This specification reserves syntax for the future support of script macros in HTML CDATA attributes." Et la syntaxe semble être précise :
                  The processing of CDATA attributes proceeds as follows:

                  1. The SGML parser evaluates any SGML entities, e.g. ">"
                  2. Next the script macros are evaluated by the script engine
                  3. Finally the resultant character string is passed to the application for subsequent processing.

                  Donc le résultat est < IMG SRC="&{logo(manufacturer("widget"))};" >
                  Et pas

                  Maintenant je n'ai pas le temps de tout lire pour savoir si c'est extensible au javascript, si la source des macro sont limités aux domaines...

                  • [^] # Re: Pourquoi IE ?

                    Posté par  . Évalué à 0.

                    voila puisqu'il parait que certain n'ont pas compris ce qu'il manquait alors que c'était visible dans la preview mais à du sauter à cause du filtrage html, le code mis sans les '<' '>'
                    img src="javascript:alert('test');"

                    En espérant que certain vont me répondre et enfin m'expliqué pourquoi mon interprétation est erronnée

                    • [^] # Re: Pourquoi IE ?

                      Posté par  . Évalué à 1.

                      C'est tres simple, tu as mis toi-meme la liste des elements :

                      The processing of CDATA attributes proceeds as follows:

                      1. The SGML parser evaluates any SGML entities, e.g. ">"
                      2. Next the script macros are evaluated by the script engine
                      3. Finally the resultant character string is passed to the application for subsequent processing.

                      1), le parser s'occupe de tout ce qui est HTML avec des < et des >

                      2) Les scripts sont executes, pour avoir la valeur du IMG SRC entre autres

                      3) Le resultat de l'execution(normalement le nom d'une image dans ce cas la) est passe au browser pour qu'il aille prendre l'image et l'afficher


                      L'exemple "&{logo(manufacturer("widget"))};" c'est du script, tout comme "javascript:alert('test');"

                      Il n'y a aucune difference entre les 2.

                      La page specifie clairement :

                      This specification extends HTML to support locally executable scripts including JavaScript, VBScript, and other scripting languages and systems.

              • [^] # Commentaire supprimé

                Posté par  . Évalué à 1.

                Ce commentaire a été supprimé par l’équipe de modération.

                • [^] # Re: Pourquoi IE ?

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

                  Et les chemins relatifs ?

                  L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire

                  • [^] # Commentaire supprimé

                    Posté par  . Évalué à 1.

                    Ce commentaire a été supprimé par l’équipe de modération.

                    • [^] # Commentaire supprimé

                      Posté par  . Évalué à 0.

                      Ce commentaire a été supprimé par l’équipe de modération.

            • [^] # Commentaire supprimé

              Posté par  . Évalué à -1.

              Ce commentaire a été supprimé par l’équipe de modération.

              • [^] # Re: Pourquoi IE ?

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

                Je suis entièrement d'acoord qu'il faut vérifier dans l'appli, mais je suis tout aussi convaincu que c'est une fonctionnalité qui est une faille en elle même. Il semble en effet inutile de discuter donc restons en là.

                • [^] # Commentaire supprimé

                  Posté par  . Évalué à 0.

                  Ce commentaire a été supprimé par l’équipe de modération.

                  • [^] # Re: Pourquoi IE ?

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

                    que le code soit exécuté dans une balise IMG ou dans un bloc SCRIPT, ça ne change strictement rien
                    Ca change qu'il y a plein de raisons d'accepter des images fournies par l'utilisateur, par contre aucun site n'a de raison de laisser passer un <script>. A cause de cette faille, un site qui vérifie juste qu'il n'y a que des image et l'attribut src (donc une simple url vers une image) laisse passer du code qui sera éxécuté par IE. Qu'il execute du code dans onClick, onLoad, <script>, ... ca ne me dérange pas. Qu'il éxecute du code dans ce qui devrait être des données me dérange. Ca me dérange autant que les softs qui executent du code sur la pile...

                    SecurityFocus désigne la faille comme étant dans DaCode, et non pas dans Internet Explorer

                    C'est ce qui m'étonne et le sujet de ce journal. Me le donner comme argument n'avance donc à rien :)

                    • [^] # Re: Pourquoi IE ?

                      Posté par  . Évalué à 1.

                      Alors c'est cette spec qui te dérange. Et elle vient du w3c comme pBpG l'a montré plus haut.
                      C'est p'tet une mauvaise idée à tes yeux, mais MS n'y est pour rien.

                      Cette fois au moins, IE respecte les specs du w3c. On ne va pas leur reprocher quand même ?

Suivre le flux des commentaires

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