naugtur
2010-11-12 14:14:52 UTC
Hier ist eine große Liste von XSS-Vektoren verfügbar: http://ha.ckers.org/xss.html, aber es hat sich in letzter Zeit nicht viel geändert (z. B. die zuletzt erwähnte FF-Version) ist 2.0).
Gibt es eine andere Liste, die so gut ist, aber aktuell?
Wir benötigen weniger Cheatsheets / Tools und ausführlichere Methodenhandbücher für Befundprobleme wie XSS. Es sollte auch beachtet werden, dass manuelle Codeüberprüfung und kontrollbasierte Lückenanalyse einfachere Methoden sind, um XSS-Probleme zu finden und zu beseitigen, insbesondere bei extrem großen Codebasen und in einer großen Anzahl von Anwendungen.
@atdre, Ich stimme zu - im Prinzip. Eine fehlende Kontrolle reicht jedoch häufig nicht aus, damit ein Unternehmen beschließt, die Ressourcen zur Behebung des Mangels einzusetzen. In der Tat würde das Risikomanagement erfordern, dass Sie nachweisen, ob der Fehler ausnutzbar ist, oder nur Best-Practice / Tiefenverteidigung.
@AviD: Hahahahaha, XSS ist immer ausnutzbar. Ich stimme dir überhaupt nicht zu. Das Aufzeigen von Risikomanagementproblemen durch Risikobewertungen ist eine reine Zeitverschwendung für die Anwendungssicherheit! Muss eine Organisation die Kunst üben, ihre eigenen Lastwagen mit vorgehaltener Waffe zu stehlen, um die Risikomanagementprobleme zu beweisen, wenn Fahrer nachts durch schlechte Nachbarschaften fahren und PR über ihren gesamten Standort und ihren LKW-Inhalt verteilt sind?
Mir ist gerade aufgefallen, dass mein Kommentar hier ein polemisches Argument ist. Bitte markieren Sie es nicht als anstößig
Heh, @atdre, Ich denke, das ist ein fairer Punkt - aber nicht der, den ich machen wollte. Nicht, dass das Risikomanagement über Risikobewertungen erfolgen sollte - aber wenn Sie eine Risikobewertung / Pentest- / Kontrollanalyse durchgeführt und bestimmte Probleme festgestellt haben, woher wissen Sie, ob dies ein hohes Risiko oder ein geringes Risiko ist? Wenn es ausnutzbar ist, ist das so. Ganz einfach, wenn es nicht ausnutzbar ist, hat es keinen Einfluss auf das Risiko. Auch sogenannte "Spickzettel" können als eine Form der (leichten) Methodik verwendet werden, da einer der Hauptteile die verschiedenen Vektoren sind, die getestet werden sollten - es ist nicht nur eine Frage der Nutzlast.
Und genauer gesagt - nicht, dass XSS immer ausnutzbar ist, aber mangelnde XSS-Verhinderung oder fehlende Validierung / Codierung im Code bedeutet nicht automatisch, dass XSS ausnutzbar ist.
Sieht so aus, als hätte ich das ganze Wochenende über viel verpasst :) Ein Wort von mir - ich halte solche Spickzettel für nützlich, um zu lernen, worauf ich beim Codieren achten sollte. Und ich muss kein Blackhat sein, um eine App ohne Codeüberprüfung nutzen zu können. (zB eine App, die in meinem Unternehmen geschrieben wurde, aber in einer Sprache, die ich nicht kenne)
@ AviD: Fehlt eine Daten- oder Risikoklassifizierung, möchten Sie möglicherweise Risikobewertungen zuweisen. Aber sind normalerweise keine Daten und Risikoklassifizierungen vorhanden? Und wenn dies nicht der Fall ist, sollten möglicherweise andere Arten von Risikomanagementinformationen verfügbar sein (ein weiteres Projekt zur Lückenanalyse), z. B. die Vorgeschichte von Vorfällen oder eine ordnungsgemäße App-Forensik?
@ AviD: Ich würde ausnutzbares XSS als HTMLi, Script Injection oder sogar CSSi definieren - egal ob es sich um eine HTTP-Schicht handelt oder nicht
@atdre, Das Problem, auf das ich Sie aufmerksam gemacht habe, ist, dass eine fehlende XSS-Präventionskontrolle NICHT unbedingt bedeutet, dass es XSS gibt. Gleich wie bei der Codeüberprüfung finden Sie möglicherweise nicht validierte Eingaben, aber das bedeutet NICHT, dass es tatsächlich XSS gibt. Warum nicht? Da es viele verschiedene Kontexte gibt, in denen injiziertes Skript möglicherweise nicht ausführbar oder falsch übersetzt ist oder oder ... Andererseits bedeutet ein vorhandenes Steuerelement oder das Auffinden von Anti-XSS-Validierungsmethoden im Code möglicherweise noch nicht, dass dies der Fall ist NICHT xss. Warum nicht? Auch hier gibt es je nach Kontext viele Möglichkeiten, dies zu umgehen.
@AviD: Jedes vom Benutzer steuerbare HTML-Elementattribut ist XSS, auch wenn es nur HTMLi oder CSSi ist. Wenn Inhalte aus Eingaben wiedergegeben werden, benötigen Sie Anti-XSS-Steuerelemente - und für mich ist das Testen von Stiften und das Überprüfen von Codes nach dieser Feststellung Zeitverschwendung. Gehen Sie direkt zu den Appsec-Steuerelementen und sammeln Sie keine 200 US-Dollar
@atdre, Was ist mit benutzersteuerbaren Daten, die KEIN HTML-Element sind? Was ist mit Meta-Tag unter Verwendung von Daten: Schema? Was ist mit * teilweise * steuerbaren Daten (d. H. Es gibt einen unvollständigen Filter)? Kurz gesagt, es gibt viele Randfälle, in denen es nicht so klar ist.
@AviD: Nun, genau das ist mein Punkt. Sie machen mein Argument für mich. Vielen Dank! Ich gewinne! Wo ist meine Punktzahl?
Jede App hat XSS. Whois hat XSS
Nein, @atdre, ist umgekehrt. Ob Sie die Kontrolle haben oder nicht, ist nicht der entscheidende Faktor, ob es ausnutzbar ist oder nicht. Sie könnten ** nicht ** die Kontrolle haben und dennoch * nicht * ausnutzbar sein; oder Sie haben ** möglicherweise ** das Steuerelement, aber aufgrund der * Implementierung * ist es ** ausnutzbar. Nur ein Häkchen neben "XSS Control" auf einer Checkliste zu haben, schützt Sie nicht.
Ich habe nie gesagt, dass ein XSS-Steuerelement funktionieren würde. Ich habe gerade gesagt, dass es der beste Anfang ist. Natürlich müssen Sie überprüfen, ob das Steuerelement funktioniert. Sie testen Ihre Kontrollen, richtig?
Natürlich ist es eine gute Idee, Informationen im Voraus zu sammeln. Aber genau dafür wird das XSS-Cheatsheet verwendet - * um zu überprüfen, ob das Steuerelement funktioniert *. DING! Ich gewinne, du hast ** meinen ** Punkt gemacht :)
Und @atdre, NICHT jede App hat XSS, nur die meisten von ihnen.
Machen Sie sich also in 30 Jahren Sorgen, wenn Sie XSS über Appsec-Steuerelemente ausgemerzt haben. Sie können den Krieg gewinnen, aber ich gewinne die Schlacht. Oh warte, wir kämpfen gegen die RBN?
Außerdem: Jede App verfügt über XSS, das als HTML, XML oder eine zukünftige Auszeichnungssprache angezeigt werden kann. Möchten Sie dieses Argument ernsthaft haben?
Wie stimme ich ab, um Kommentare zu dieser Frage zu schließen? ;)
Eigentlich denke ich, @naugtur,, die Kommentare hier sind äußerst hilfreich, möglicherweise sogar mehr als die Antworten selbst - aber andererseits könnte ich voreingenommen sein. Ich denke, das Back'n'Forth, das ich mit @atdre hatte, war aktuell und von hohem Wert - aber wahrscheinlich verdient seine eigene Frage / Diskussion. Aber auch hier bin ich wahrscheinlich voreingenommen :)
@AviD Ich habe es als Witz gepostet. Es wäre schön, wenn jemand es in einer brauchbaren Form zusammenfassen könnte;) Die meisten Leute werden die Kommentare einfach überspringen.