entenhausenconnection: JavaScript-Zugriff auf HTML-Quelltext

Hallo

Mein Problem mag zwar ein wenig theoretisch klingen, aber ich versuche Folgendes: Ich möchte in einem erste Scriptblock möglichst weit vorne in der Seite ein Array im Klartext definieren und mit Inhalt füllen. Dieses Array wird dann dazu verwendet um ein Objekt zu initialisieren, daß die Daten in einer privaten Variablen kapselt.

Soweit so gut. Problem ist nun, daß ich das eigentliche Array direkt nach der Objekterzeugung in einem zweiten Scriptblock löschen möchte und zwar so gründlich, daß ein später in der Seite definiertes Script (z.B. aus einem Cross-Site-Scripting-Angriff) keine Möglichkeit mehr hat an die ursprünglich in dem Array gespeicherten Daten zu kommen.

Bis jetzt sieht mein Ansatz so aus:

<script type="text/javascript" id="js:array">
    var myArray = new Array();
    myArray['daten'] = "mapping";
    var MyRandomizer = new Randomizer(myArray);
    myArray = new Array();
</script>

<script type="text/javascript" id="js:remove">
    var knoten = document.getElementById("js:array");
    var mutterknoten = knoten.parentNode;
    knoten.innerHTML="";
    mutterknoten.removeChild(knoten);
    knoten = "";
    mutterknoten = "";
</script>

Ich würde nun gerne Eure Meinung wissen, ob es für ein Script noch eine Möglichkeit gibt an den Inhalt von myArray oder an den Quelltext des Script-Blockes zu kommen. Die Menge der Möglickeiten für Zugriffe scheint mir so vielfältig zu sein, daß ich Angst habe etwas offensichtliches zu übersehen ;-) Der Browser zeigt unter 'Quelltext' bei meinem Ansatz übrigens noch den ursprünglichen Code mit den sensiblen Informationen an (das ist aber nicht schlimm, es geht hier ausschließlich um den Scriptzugriff). Der DOM-Inspector hingegen kennt den Script-Block js:array nicht mehr (das scheint mir vielversprechend).

Danke schonmal...

  1. hi,

    Problem ist nun, daß ich das eigentliche Array direkt nach der Objekterzeugung in einem zweiten Scriptblock löschen möchte und zwar so gründlich, daß ein später in der Seite definiertes Script (z.B. aus einem Cross-Site-Scripting-Angriff) keine Möglichkeit mehr hat an die ursprünglich in dem Array gespeicherten Daten zu kommen.

    Wäre es da nicht sinnvoller, anstatt so einen Zirkus zu veranstalten, sich darum zu kümmern, dass man XSS vermeidet?

    gruß,
    wahsaga

    --
    /voodoo.css:
    #GeorgeWBush { position:absolute; bottom:-6ft; }
    1. Wäre es da nicht sinnvoller, anstatt so einen Zirkus zu veranstalten, sich darum zu kümmern, dass man XSS vermeidet?

      Hi

      Da hast Du sicherlich Recht, aber Ziel meiner Arbeit ist es momentan, die Auswirkungen von potentiellen XSS-Schwachstellen einzugrenzen. Die Realität zeigt doch leider, daß eine komplette Vermeidung von XSS-Lücken kaum möglich ist und für sicherheitsrelevante Anwendungen weitere Maßnahmen wünschenswert sind.

      Gruß,
      Entenhausenconnection

      1. hi,

        Da hast Du sicherlich Recht, aber Ziel meiner Arbeit ist es momentan, die Auswirkungen von potentiellen XSS-Schwachstellen einzugrenzen. Die Realität zeigt doch leider, daß eine komplette Vermeidung von XSS-Lücken kaum möglich ist und für sicherheitsrelevante Anwendungen weitere Maßnahmen wünschenswert sind.

        Was passiert denn mit den Daten, die da zum Client übertragen werden - auf welche Weise werden sie dort genutzt?

        Irgendeine clientseitige Bedeutung müssen sie ja haben - sonst würden sie ja gar nicht erst dorthin übertragen.

        Wenn du sie aber bspw. dynamisch irgendwo ins Dokument schreibst - dann hole ich als XSS-Bösewicht sie mir eben von dort, anstatt aus deinem <script>-Block ...

        gruß,
        wahsaga

        --
        /voodoo.css:
        #GeorgeWBush { position:absolute; bottom:-6ft; }
        1. Hallo

          Was passiert denn mit den Daten, die da zum Client übertragen werden - auf welche Weise werden sie dort genutzt?

          Irgendeine clientseitige Bedeutung müssen sie ja haben - sonst würden sie ja gar nicht erst dorthin übertragen.

          Wenn du sie aber bspw. dynamisch irgendwo ins Dokument schreibst - dann hole ich als XSS-Bösewicht sie mir eben von dort, anstatt aus deinem <script>-Block ...

          gruß,
          wahsaga

          Auf clientseite findet damit ein Mapping von einer URL auf die gleiche URL mit einer vorgehängten Subdomain statt. Da ein XSS diesen Subdomain-Wert möglichst nicht erfahren soll, findet das Mapping dann in dem initialisierten Randomizer-Objekt statt

          <script type="text/javascript" id="js:randomizer">
          function Randomizer(urlarray) {
              var arrayOfURLs = urlarray;

          this.go = function(addr) {
                  alert(arrayOfURLs[addr]);
                  document.location = arrayOfURLs[addr];
              }
          }
          </script>

          Ist alles eine etwas wilde Angelegenheit und zugegebenermaßen auch etwas undurchsichtig, aber es müsste vom Prinzip her funktionieren. Die bisher geposteten Scriptblöcke sollen den Aspekt verhindern, daß ein boshaftes Script ein Browser-Hijacking durchführt. Also sind immer nur bestimmte URLs auf Serverseite gültig und die will ich vor dem Script geheimhalten. Der Clientseite muss die URL aber leider trotzdem irgendwie bekannt sein, sonst wird das nichts mit der Navigation ;-)

          Gruß,
          entenhausenconnection

          1. hi,

            Auf clientseite findet damit ein Mapping von einer URL auf die gleiche URL mit einer vorgehängten Subdomain statt.

            Zu welchem Zweck?

            Da ein XSS diesen Subdomain-Wert möglichst nicht erfahren soll

            Wo läge der Schaden?

            gruß,
            wahsaga

            --
            /voodoo.css:
            #GeorgeWBush { position:absolute; bottom:-6ft; }
            1. hi,

              Auf clientseite findet damit ein Mapping von einer URL auf die gleiche URL mit einer vorgehängten Subdomain statt.

              Zu welchem Zweck?

              Der Wert der Subdomain ist zufällig gewählt und damit ändern sich die gültigen Adressen mit jeder Anfrage. Kennt ein XSS die Adressen nicht, kann es sie nicht aufrufen.

              Da ein XSS diesen Subdomain-Wert möglichst nicht erfahren soll

              Wo läge der Schaden?

              Kennt ein XSS die Adressen kann es sie aufrufen und damit wäre ein Hijacking des Browsers möglich wie es z.B. beim MySpace.com Wurm stattgefunden hat (http://namb.la/popular/tech.html)

              Gruß,
              Entenhausenconnection

              1. hi,

                Der Wert der Subdomain ist zufällig gewählt und damit ändern sich die gültigen Adressen mit jeder Anfrage. Kennt ein XSS die Adressen nicht, kann es sie nicht aufrufen.

                Du versuchst also, eine Art Übergabe irgendeines geheimen Wertes zu realisieren, indem du dafür eine "Subdomain" missbrauchst?

                Kennt ein XSS die Adressen kann es sie aufrufen und damit wäre ein Hijacking des Browsers möglich wie es z.B. beim MySpace.com Wurm stattgefunden hat (http://namb.la/popular/tech.html)

                Sorry, ich halte das immer noch für sehr weit hergeholt.

                Die erfolgreiche Absicherung gegen XSS hat m.E. wenig damit zu tun, Seitenadressen durch "randomizing" zu verstecken.
                Und die Nachteile dürften die Vorteile bei weitem überwiegen. Zum Beispiel das Caching wiederholt aufgerufener Elemente düftest du damit ziemlich zunichte machen.

                gruß,
                wahsaga

                --
                /voodoo.css:
                #GeorgeWBush { position:absolute; bottom:-6ft; }
                1. Hi

                  Du versuchst also, eine Art Übergabe irgendeines geheimen Wertes zu realisieren, indem du dafür eine "Subdomain" missbrauchst?

                  Daß ich dafür die Subdomain missbrauche hat weitere Gründe. Für einige andere Verfahren muss ich das Same-Origin-Prinzip ausnutzen und dafür brauche ich halt verschiedene Subdomains. Der Einfachheit halber habe ich das mal kombiniert.

                  Und die Nachteile dürften die Vorteile bei weitem überwiegen. Zum Beispiel das Caching wiederholt aufgerufener Elemente düftest du damit ziemlich zunichte machen.

                  Das sehe ich genauso. Bookmarks, Back-Button, Reload, etc. sind hinüber... Aber es geht mir für meine Diplomarbeit momentan mehr um eine Abschätzung des Machbaren mit Vor- und Nachteilen. Ich glaube benutzen möchte ich das selber auch nicht ;-)

                  Gruß,
                  Entenhausenconnection

  2. var myArray = new Array();
        myArray['daten'] = "mapping";

    ^^^^^^^
    Im Gegensatz zu anderen Programmiersprachen gibt es in JavaScript keine assoziativen Arrays.
    (Übernommen von Objektreferenz)

    1. Hi

      var myArray = new Array();
          myArray['daten'] = "mapping";
                    ^^^^^^^
      Im Gegensatz zu anderen Programmiersprachen gibt es in JavaScript keine assoziativen Arrays.
      (Übernommen von Objektreferenz)

      Das stimmt wohl, aber ich glaube das hängt davon ab wie man ein assoziatives Array sieht. Obige Schreibweise funktioniert auf jeden Fall wunderbar, da auch ein per Array() erzeugtes Array ein Object ist und sich somit assoziativ verhält. Genaugenommen hast Du aber Recht.

      Gruß,
      Entenhausenconnection