2010-12-28 5 views
19

Es gibt bekannte Art Attribut XSS-Angriffe wie:XSS-Angriffe und Stilattribute

<DIV STYLE="width: expression(alert('XSS'));"> 

Oder

<DIV STYLE="background-image: url(javascript:alert('XSS'))"> 

Alle Beispiele I've seen entweder Ausdruck oder URL-Funktionalität nutzen - im Grunde etwas Funktion wie das erfordern " (" und ")".

I die folgenden Verfahren zum Filtern von Style-Tags denken, ich würde überprüft sie folgende mit (ungefähr) Grammatik:

identifier: [a-zA-Z_][a-zA-Z0-9\-]* 
number: [0-9]+ 
string: '[a-zA-Z_0-9 ]*' 
value : identifier | number | string | number + "(em|px)" | number +"%" 
entry: identifier ":" value (\s value)* 
style: (entry ;)* 

Also im Grunde erlaube ich ASCII-Eigenschaften mit numerischen Werten oder sehr begrenzten String-Werten (im Grunde für Schriftartnamen), die nichts erlaubt, das wie Anruf aussieht.

Die Frage ist das gut genug? Gibt es irgendwelche Angriffe, die etwas in der Art tun können:

<DIV STYLE="this-is-js-property: alert 'XSS';"> 

Und erfolgreich sein?

Kann jemand an die XSS-Schwachstelle eines solchen Tests denken?

deutlich machen,

Ich brauche Stil so viele Werkzeuge wie TinyMCE sie Attribute und Filterung harmlos Stilattribute aus deutlich die Funktionalität verletzen würde.

Also bevorzuge Pass häufige Fälle entfernen alle Dinge, die @import, URL, Ausdruck usw. verwenden können. Und stellen Sie auch sicher, dass grundlegende CSS-Syntax in Ordnung ist.

Antwort

Nein ist es nicht sicher durch die Anfälligkeit für Clickjacking.

+1

gute Arbeit geleistet, wusste nicht, viele dieser –

Antwort

9

Dies funktioniert nicht wegen Click-Jacking Schwachstelle.

Beispiel:

<a href="http://example.com/attack.html" style="display: block; z-index: 100000; opacity: 0.5; position: fixed; top: 0px; left: 0; width: 1000000px; height: 100000px; background-color: red;"> </a> 

Gefunden bei: http://www.bioinformatics.org/phplabware/forum/viewtopic.php?id=164

Der Code würde perfekt validiert werden, aber es kann zu schweren Schäden führen.

Also - Faustregel verwenden sehr strenge Whitelist oder erlauben keine Stilattribute.

+0

Guter Punkt! Ich denke, wir könnten heutzutage X-Frame-Optionen zur Abwehr von Klick-Angriffen verwenden. – liweijian

3

Es gibt eine offene Stiftung namens OWASP, die Ihnen dabei hilft.

Um Ihre Frage zu beantworten Are there any attacks....; Ja!

Es gibt Tonnen von Dokumentation dort, und es gibt Bibliotheken, die Sie verwenden können, um alle XSS-Code korrekt zu entkommen.

Lesen Sie die XSS prevention sheet.

+3

Können Sie das konkretisieren bitte? Irgendein ** spezifischer ** Angriff? Ich habe diese Seiten durchsucht und nichts gefunden, was solche Angriffe mit css-IDs und nur Zahlen möglich machen würde. Deshalb frage ich. – Artyom

+0

Es gibt Tonnenweise Weise, HTML zu kodieren. Sie können HTML-Entitäten für eins verwenden. Die OWASP-Dokumentation enthält alle Beispiele, und die dort vorhandenen Bibliotheken entziehen sich "allen" Möglichkeiten. –

+0

HTML-Entities und andere "verdrahtete" Codierungsarten sind nicht erlaubt, wie Sie in der Grammatik sehen können " – Artyom

1

Sicherheitsregel # 1: Wenn Sie am wenigsten Zweifel haben, nehmen Sie an, es gibt ein Loch.

Was versuchen Sie zu erreichen? Welche Funktionalität würde CSS von einer nicht vertrauenswürdigen Quelle verursachen?

+0

vielleicht ein Wysiwyg-Editor von einem nicht vertrauenswürdigen Benutzer? –

+0

In meinem Fall ist es ein Diskussionssystem, wo Leute Kommentare in CommonMark + HTML posten können, und sie könnten 'style = ...' Attribute enthalten. (Ich bin nicht das Original-Poster, ich habe nur ein ähnliches "Problem".) – KajMagnus

0

Ja, Sie können XSS-Angriffe mit Style-Attributen verwenden.

wurden diese Stile injiziert, wie wir haben sie nicht in unsere Tags in einer bestimmten jsp Seite erklärt haben, aber durchkam, wenn sie durch unsere Sicherheitsgruppe geprüft:

<img src="<path here>" style=x:ex/**/pression 
(alert(54163)) ".gif" 

Ich denke, einen HTTP-Filter verwenden um es hier zu stoppen, aber ich schaue immer noch darauf.

Wir haben auch unsere nicht verborgen Eingabefelder proteccted entweder, und dies kommt durch auch:

<input type="hidden" name="<variable name here>" value="<value here>" style=x:ex/**/pression(alert 
(54163)) ""> 

Mit einem Tool wie Burpsuite, können Sie Anfragen on the fly ändern XSS in Tags wie diese zu injizieren . Mit den ESAPI-APIs von OWASP können Sie jedoch Schutz hinzufügen. Wir verwendeten keine JSTL-Tags, da es sich um alten Legacy-Code handelte. Das war die beste kurzfristige Lösung.

Für den versteckten Eingang habe ich verwendet;

<input type="hidden" name="id" value="<%=ESAPI.encoder().encodeForHTMLAttribute(id)%>" 

Sie auch XSS with the js onload event in an img tag verwenden können:

+0

Aber in Ihrem Fall sind die Attribute style und src nicht korrekt maskiert, d. H. Sie können nicht ohne Anführungszeichen und richtig codierten Inhalt gehen. – Artyom

+0

Die XSS, die ich zeige, sind solche, die unseren js-Code tatsächlich durchstanden haben. –