HTML-Element ändert sich beim Speichern

[Zille]

In ein HTML-Element trage ich folgendes ein:

<div class="embed-container"><iframe scrolling="no" frameborder="0" src="files/content/dw/1300-220-1/index.html">1300-220-1</iframe></div>

nach dem Speichern steht nur noch:

<div class="embed-container"><iframe>1300-220-1</iframe></div>

was selbstverständlich nicht mehr funktioniert.

Wie kommt es zu dieser Änderung?!

[ausi]

Vermutlich durch ein Update auf eine der Contao-Versionen 4.11.7, 4.9.18 oder 4.4.56.

Welche HTML-Attribute erlaubt sind kannst du unter System › Einstellungen › Sicherheitseinstellungen › Erlaubte HTML-Attribute festlegen.

Wenn du Alles erlauben willst kannst du für das Element * als Attribut * einstellen.
WICHTIG: Das solltest du jedoch nur dann machen wenn du allen Backend-Benutzern zu 100% vertrauen kannst.

[Zille]

Vermutlich durch ein Update auf eine der Contao-Versionen 4.11.7, 4.9.18 oder 4.4.56.

Richtig, es ist ein Update auf 4.11.7

Welche HTML-Attribute erlaubt sind kannst du unter System › Einstellungen › Sicherheitseinstellungen › Erlaubte HTML-Attribute festlegen.

Klar, <iframe> ist unter erlaubte HTML-Tags eingetragen.

Wenn du Alles erlauben willst kannst du für das Element * als Attribut * einstellen.
WICHTIG: Das solltest du jedoch nur dann machen wenn du allen Backend-Benutzern zu 100% vertrauen kannst.

Da ich der einzige Bearbeiter bin, mir auch zumeist vertraue, wäre das wohl kein Problem. Dennoch scheint es irrelevant, da doch <iframe> bereits eingetragen ist.

Was übersehe ich?!

[tab]

Du musst auch die innerhalb eines iframe-Tag verwendbaren Attribute freigeben. Dein freigegebenes iframe-Tag ist ja drin geblieben, aber die Attribute wurden rausgelöscht. Ich habe nirgends iframes, kann dir aus dem Kopf deswegen nicht sagen, wie das genau auszusehen hat. Aber es gibt ältere Threads dazu, daran kann ich mich jedenfalls erinnern. Kann es sein, dass die ganzen erlaubten Tags mal bei einem Update verlorengegangen sind und nur das iframe-Tag ohne Attribute wieder aufgenommen wurde?

[ausi]

Die Einstellung für erlaubte HTML-Attribute gibt es erst seit heute mit den Contao-Versionen 4.11.7, 4.9.18 und 4.4.56.

[tab]

Hmm, ich war der Meinung da hätte man schon zu Zeiten von Contao 3 hier drüber geschrieben. Vielleicht verwechsele ich da auch was, ist schon Jahre her. Muss ich morgen mal ein wenig suchen hier im Forum.

[Nightwing]

Vielleicht verwechsele ich da auch was [...]

Jub, deswegen extra grad mal nachgesehen in der neuen Version, aber an sich isches logisch: HTML Tag (altbekannt) != HTML Attribut (neue Einstellmöglichkeit)
Siehe Bild, man lernt nie aus: tag_vs_attr.PNG

ToM

[Zille]

Die Einstellung für erlaubte HTML-Attribute gibt es erst seit heute …

Na toll, und da tapse ich 10 Minuten später ungewarnt rein.

Nuläuftswieder.

[zonky]

ist das in der 4.12 oder auch schon in 4.9 neu?!?

[lucina]

4.9.18

[zonky]

stand dazu irgendwas in irgendwelchen News oder so..?!?

[lucina]

"Prevent XSS via HTML attributes in the back end ([CVE-2021-35955])"

Darum die Whitelist der Attribute.

[zonky]

"Prevent XSS via HTML attributes in the back end ([CVE-2021-35955])"

Darum die Whitelist der Attribute.

Freunde der Nacht: ich glaube nicht, dass ein Großteil der "Redakteure" sich da durch die CVEs kämpfen um das in Erfahrung zu bekommen.

Solche Sachen sollten etwas plakativer mitgeteilt werden IMHO

[lucina]

Redakteure kämpfen sich im Regelfall überhaupt nicht durch CVEs.

Ich würde das als zu meinen Job der Administratorin zugehörig begreifen.

Und es ist ja auch noch die Frage, ob man ein potentiell gefahrvolles Element überhaupt freigeben muss, oder ob es nicht auch andere Lösungen dafür gibt.

Beispiel: Ich habe ein System, bei dem Menschen regelmässig iFrames einzubauen hatten. Da ich das nicht hinnehmbar fand haben die nun ein Contentelement bekommen, bei dem sie URL und ein paar Parameter in Felder eintragen dürfen. Funktioniert auch, macht keine Arbeit, spart Rückfragen und ist obendrein sicherer.

[servpoint]

Schon mal daran gedacht was diese Änderungen an erlaubten Attributen für einen Aufwand für bestehende Installationen bedeuten kann? Auch Contao steht im Wettbewerb zu anderen Systemen in Bezug auf die Kosten für die Umsetzung. Das wird immer schwieriger in Wartungsverträgen zu berücksichtigen.

[zonky]

Mir geht es nicht um sinvoll, notwendig oder was auch immer... sondern um die Kommunikation.

Als "Admin" wäre mir das sicher auch erst auf die Füße gefallen, wenn Meldung vom Kunden "da geht wieder was nicht.." gekommen wäre.

Bei MM werden soche Sachen per Migration abgefangen - wenn das nicht geht, kommt Meldung beim DB-Update auf Anpassungs/Check-bedarf - und/oder Hinweis im Handbuch+News.

[mlweb]

Schon mal daran gedacht was diese Änderungen an erlaubten Attributen für einen Aufwand für bestehende Installationen bedeuten kann?

Ich denke der Aufwand, der entsteht, wenn eine Installation gehackt wurde ist wesentlich größer.

[BugBuster]

Es hat ja niemand was gegen die neuen erlaubten Attributen, aber so ganz ohne Kommunikation für Normalsterbliche ist schon etwas krass.
Wenn schon nicht im Vorfeld, dann eben in den Update News, in der Changelog oder so.

[zonky]

so ganz ohne Kommunikation für Normalsterbliche ist schon etwas krass.

Das ist der Punkt!

[lucina]

Ich hatte das auch bereits gestern bei der News entsprechend kommentiert, bin aber nicht sicher, wann (und ob) das dort erscheint.

Bei Security-Sachen ist das ja auch immer so ein latenter Tanz auf dem Seil. Wieviele Informationen gibt man? Welche Gefahren birgt das? Wen bringt das auf welche dummen Gedanken?

Nichtsdestotrotz: Es macht mich auch ein wenig blass, dass anscheinend die wenigsten dann mal in den Code hineinschauen um a) das Risiko einzuschätzen und b) zu schauen, was das für ein eigenes System bedeutet.

[zonky]

man kann das auch anders sehen - wie war das in der Marketing-Vorlesung: "Tue Gutes und rede darüber..."

Wenn man tolle neue Features hat, dann kann man das auch gern an die "große Glocke" hängen.

Ich "nerve" ja auch bei anderen Projekten die Leute ;-)

[albis]

... wie verhält sich das mit der Contao-Eigenen Anweisung

<!-- indexer::stop -->
...
<!-- indexer::continue -->

im HTML-Code Modul? der komplette Code innerhalb dieser Anweisungen wird nicht ausgegeben...
... passiert erst nach Erneuten Speichern des Moduls, vielleicht ist deswegen noch nicht aufgefallen.
wie kann ich dieses der White-List hinzufügen?
... habe bis jetzt keine Lösung gefunden. (außer es zu löschen, was aber nicht Sinn und Zweck sein sollte)

EDIT: scheint sich generell um HTML Kommentare zu handeln a la: <!-- .... -->

[ausi]

Kannst du bitte testen ob das Problem in der aktuellen 4.9.x-dev Version noch auftritt?

Dort sollte das Problem durch folgenden Pull-Request bereits behoben worden sein: https://github.com/contao/contao/pull/3319

[albis]

danke für die schnelle Rückmeldung! ... habe leider aktuell keine Entwicklungsumgebung um dies zeitnah testen zu können.

[lucina]

Naja, die eine Zeile kannst Du ja auch mal von Hand einsetzen, oder?

[albis]

OK hab es getestet.

HTML Ausgabe bleibt erhalten aber zB HTML-Kommentare werden gewandelt als &lt;!-- test --> und somit (im Frontend) sichtbar ...

[Dillinja]

Moin,

ich hätte das als Feature erwartet und nicht als Bugfix, aber cool.

Ich hab nur mit dem Script-Tag Probleme.

<script async>

wird

<script async="">

auch werden ', ", = zum Beispiel codiert...

<script async="">
	var gMapsURL &#61; &#39;https://dev.domain.de/files/theme-files/script/gMaps.js&#39;;
	//if(localStorage.getItem(&#39;fMaps&#39;) &#61;&#61; &#39;yes&#39;){
  	$.getScript(gMapsURL, function(){
  		googleMaps();
  	});
  //}
</script>

Wie könnte ich das zum Laufen bringen?

Vielen Dank und viele Grüße
Micha

Edit: ich sehe, dass man dem schon auf der Spur ist... ;-) wahrscheinlich hier: https://github.com/contao/contao/pull/3315

[ausi]

Mit den aktuellen Entwicklungs-Versionen 4.9.x-dev sowie 4.11.x-dev sollten alle beschriebenen Fehler bereits behoben sein.

<script async>

wird

<script async="">

Diese Umwandlung des Attributes ist korrekt und wird auch von jedem Browser richtig verstanden.