Einige Klarstellungen bezüglich XSS [geschlossen]

8

Ich lese zufällig über XSS und wie man es vermeidet. Aus dem, was ich gelesen habe, habe ich erfahren, dass wir Eingabefilterung, korrekte Handhabung von Anwendungscode und Ausgabecodierung benötigen, um die Webanwendung etwas XSS-sicher zu machen. Nach Durchlaufen mehrerer Artikel bestehen noch einige Zweifel.

  • Wenn ich jQuery.text ("nicht vertrauenswürdige_Daten") oder element.text = nicht vertrauenswürdige_Daten ausprobierte, wurde die Browser scheint den Inhalt perfekt zu kodieren, aber ich habe irgendwo gelesen, dass die clientseitige Kodierung nicht vertrauenswürdig sein sollte und Sie müssen " immer " auf dem Server kodieren Seite. Warum wird die clientseitige Codierung nicht als sicher betrachtet?

  • Immer wenn ich versuchte, Werte mit jQuery.val (nicht vertrauenswürdige_Daten) oder element.value = nicht vertrauenswürdige_Daten festzulegen, scheint dies sicher genug zu sein. Ist es wirklich XSS-sicher oder habe ich hier einen Fehler übersehen?

  • Außerdem habe ich irgendwo gelesen, dass jQuery.setAttribute (attrName, nicht vertrauenswürdige_Daten) und setAttribute (attrName, nicht vertrauenswürdige_Daten) im Allgemeinen nur dann als sicher gelten, wenn die Attributnamen nicht stimmen keine URL Context basierten Attribute (src, href etc) oder Event Handler (onClick, onMouseOver etc). Wenn das der Fall ist, wie soll ich ein href-Attribut setzen, indem ich setAttribute ("href", nicht vertrauenswürdige_Daten) verwende? Ist encodeForHtmlAttribute (nicht vertrauenswürdige_Daten) von der Serverseite her die richtige Herangehensweise?
  • Wie sollte ich mit der dynamischen HTML-Erstellung umgehen? Betrachten Sie das folgende Beispiel
  

<div id="divName1" onClick="copyData()">untrusted_data</div>    <div id="divName2"></div>

%Vor%

Was ich hier erreichen möchte, ist, den Text von divName1 zu holen und ihn in den Inhalt von divName2 einzufügen. Der Code, den ich oben geschrieben habe, ist XSS-anfällig. Ich kann das zu

ändern
  

jQuery ("# ​​divName2"). text (divValue)

Damit wird die Kodierung sichergestellt, aber wie ich verstanden habe, sagen wir, dass die clientseitige Kodierung unsicher ist und nur serverseitige Kodierung verwendet werden sollte. Wie soll ich dies schreiben, um XSS-sicher zu sein, ohne clientseitige Kodierung zu verwenden? Ich bin hier etwas verwirrt :(. Bitte helfen Sie mir, diese Zweifel auszuräumen.

    
Ebbu Abraham 20.11.2012, 07:59
quelle

1 Antwort

8

Das sind viele Fragen auf einmal.

  

Warum wird die clientseitige Codierung nicht als sicher betrachtet?

Die clientseitige Codierung ist in Ordnung, solange sie ordnungsgemäß und konsistent erfolgt. Die clientseitige Codierung hat oft einen niedrigeren Balken, da sie sich nicht mit Angriffen auf Zeichencodierungsebene wie UTF-7-Angriffen befassen muss.

  

Immer, wenn ich versuchte, Werte mit jQuery.val (nicht vertrauenswürdige_Daten) oder element.value = nicht vertrauenswürdige_Daten festzulegen, scheint es sicher genug zu sein. Ist es wirklich XSS-sicher oder habe ich hier einen Fall übersehen?

Wenn untrusted_data eine Zeichenkette ist und das Element, dessen Wert gesetzt wird, ein normaler Textknoten in einem Fluss- oder Blockelement ist, ist alles in Ordnung. Es kann zu Problemen kommen, wenn der Knoten, dessen Wert zugewiesen wird, ein Textknoten in einem <script> -Element oder ein URL-, Event-Handler- oder style-Attributknoten oder irgendetwas im Zusammenhang mit <object> ist.

  

Außerdem lese ich irgendwo, dass jQuery.setAttribute (attrName, nicht vertrauenswürdige_Daten) und setAttribute (attrName, nicht vertrauenswürdige_Daten) im Allgemeinen nur dann als sicher betrachtet werden, wenn die Attributnamen keine auf dem URL-Kontext basierenden Attribute (src, href etc) enthalten Ereignishandler (onClick, onMouseOver usw.). Wenn das der Fall ist,

Das ist teilweise richtig. Andere Attribute haben scharfe Kanten wie style und viele Dinge, die mit <object> und <embed> und <meta> zusammenhängen.

Wenn Sie nicht viel über das Attribut wissen, dann stellen Sie es nicht ungesicherten Daten aus. Dinge, die im Allgemeinen sicher sind, sind Attribute, die Textinhalt wie title enthalten oder die Werte wie dir=ltr und dir=rtl haben.

Sobald Sie mit Attributen arbeiten, die komplexere Werte annehmen, besteht die Gefahr, dass Angreifer obskure Browsererweiterungen wie -moz-binding in style attributes ausnutzen.

  

es scheint sicher genug zu sein

Landminen scheinen in Sicherheit zu sein, bis Sie darauf treten.

Von etwas, das "sicher scheint", kann man nicht viel schließen. Sie müssen es wirklich betrachten und verstehen, was möglicherweise schiefgehen kann, und Dinge so arrangieren, dass Sie nur gefährdet sind, wenn ein perfekter Sturm von Dingen schief geht (P (Katastrophe) = P (Scheitern0) * P (Scheitern1 ) * ...) und dass Sie nicht gefährdet sind, wenn nur eine Sache schief geht (P (Desaster) = P (Scheitern0) + P (Scheitern1) * P (! Scheitern0) + ...).

  

Wie soll ich ein href-Attribut setzen, indem ich setAttribute ("href", nicht vertrauenswürdige_Daten) verwende?

Tun Sie es nicht, ohne das Protokoll auf die weiße Liste zu setzen.

%Vor%
  

Ist encodeForHtmlAttribute (nicht vertrauenswürdige_Daten) von der Serverseite her die richtige Herangehensweise?

Nein. Die HTML-Codierung des an setAttribute übergebenen Werts ist redundant und trägt nicht dazu bei, Sicherheitseigenschaften beizubehalten. <iframe srcdoc> könnte eine seltene Ausnahme sein, da der Inhalt HTML ist, wenn meine Erinnerung an die letzten Spezifikationsänderungen korrekt ist.

  

Was ich hier erreichen möchte, ist, den Text von divName1 zu holen und ihn in den Inhalt von divName2 einzufügen. Der Code, den ich oben geschrieben habe, ist XSS-anfällig.

Nicht mit HTML herumalbern. Browser ' .innerHTML getters sind fehlerhaft und führen manchmal zu Exploits wie Backticks, die im IE als Wertbegrenzer fungieren. Klonen Sie einfach die Knoten von einem zum anderen. Etwas wie das Folgende sollte es tun:

%Vor%
  

Ich kann das zu

ändern %Vor%

Das ist in Ordnung, wenn Sie nur den textlichen Inhalt haben wollen.

    
Mike Samuel 20.11.2012, 08:10
quelle

Tags und Links