XSS ist eine Form der Code-Injektion, d. h. der Angreifer schafft es, seinen eigenen Schadcode (normalerweise JavaScript) in vertrauenswürdigen Code (HTML, CSS, JavaScript) zu injizieren, der von der Site bereitgestellt wird. Es ist SQLi insofern ähnlich, als es durch dynamisch aufgebauten Code verursacht wird, dh SQL-Anweisungen, HTML-Seiten usw.

Es gibt jedoch etablierte Techniken zum Lösen von SQLi (dh Parameter verwenden) Bindung) ist es mit XSS noch schwieriger. Um sich gegen XSS zu verteidigen, muss jede benutzergesteuerte Eingabe ordnungsgemäß maskiert werden, was viel schwieriger ist als es sich anhört:

• Escape-Regeln hängen vom Kontext ab, dh HTML, HTML-Attribut, XHTML, URL, Skript, CSS-Kontexte haben alle unterschiedliche Escape-Regeln.
• Diese Kontexte können verschachtelt sein, dh <a href = javascript: XXX > ist ein JavaScript-Kontext in einem URL-Kontext innerhalb eines HTML-Attributs
• Darüber hinaus haben Sie Codierungsregeln für Zeichen (UTF-8, UTF-7, latin1, ...), die wiederum kontextspezifisch sein können.
• Der Kontext und Die Codierung muss beim Erstellen der Ausgabe bekannt sein: Während die meisten Template-Engines die ordnungsgemäße HTML-Escape-Funktion unterstützen, kennen sie den umgebenden Kontext häufig nicht und können daher die kontextspezifischen Escape-Regeln nicht anwenden.
• Darüber hinaus können Browser dies Verhalten Sie sich in Bezug auf Escape- oder Codierung etwas anders.
• Abgesehen davon finden Sie häufig in gewachsenem Code ohne ordnungsgemäße Trennung von Logik und PR Es wird angegeben, dass HTML-Fragmente in der Datenbank gespeichert werden und dem Entwickler nicht immer klar ist, ob ein bestimmter Wert bereits HTML-sauber ist oder maskiert werden muss.

Und es gibt einige einfache Möglichkeiten Zum Schutz vor XSS durch Design (insbesondere Content-Security-Policy) funktionieren diese nur mit den neuesten Browsern, müssen vom Entwickler explizit aktiviert werden und sind häufig erst nach großen (und teuren) Änderungen am Code (wie dem Entfernen von Inline-Skripten) wirksam. .

Trotzdem besteht eine gute Chance, es richtig zu machen, wenn Sie Entwickler mit den richtigen Kenntnissen haben und mit modernen Toolkits, die sich bereits um XSS kümmern, von vorne anfangen können. Leider gibt es in vielen Fällen Legacy-Code, an dem nur weiter gearbeitet werden muss. Und die Entwicklung wird normalerweise von Entwicklern durchgeführt, die XSS überhaupt nicht kennen oder nicht alle Fallstricke kennen.

Und solange die Webentwicklung in Umgebungen durchgeführt wird, die sehr kosten- und zeitempfindlich sind, ist die Wahrscheinlichkeit gering, dass sich dies ändert. Ziel in dieser Umgebung ist es, dass der Code in kurzer Zeit und mit geringen Kosten überhaupt funktioniert. Unternehmen konkurrieren normalerweise nach Funktionen und Markteinführungszeit und nicht nach dem sichersten Produkt. Und XSS-Schutz bedeutet derzeit nur zusätzliche Kosten ohne offensichtlichen Nutzen für viele Manager.