Kann ich nicht bestätigen. Bei mir bleiben Tags und Bilder auch in den Textbausteinen bestehen.
Probier mal bitte:
<span onclick="alert('Hello World')">Test</span>
Yep, das geht nicht. Liegt an einem Bug im Client-/Javascript-Code. Da wird die Einstellungen nicht übernommen, bzw. keine YAML-Config geladen.
Damit wird der Standard von der eingesetzten Bibliothek DOMPurify verwendet. Und in diesem Standard fliegen script-Tags raus.
Workaround (schnell und hässlich per Core-Anpassungen oder aufwendiger per Plugin) findest du hier: Arbeit mit Textbausteinen in SW 6 mangelhaft - #12 von area-net-gmbh
1 „Gefällt mir“
Soweit mir im Moment bekannt wurden auch schon unter sw6.4
Textbausteine wenn dann maximal nur mit Minimum-HTML unterstützt
ohne weitere Veränderungen durch Plugins oder sonstige Eingriffe.
D.h.
- Keine
<style> - Keine
<script> - Keine attr onclick und auch keinerlei andere Events …onload, onchange, oninput…etc…
Das störte mich auch, weil es damit nicht möglich war direkt in Textbausteienen
allgemeine Phrasen zu hinterlegen. Ich hatte das damals gelöst indem ich nur kennungen/klassen
den Elementen mitgab und ein zentrales onLoadJsFrontendScript diesen Elementen dann
ihre Standard-Funktionalität einhauchte mittels addEventListener und Funktionszuweisung.
1 „Gefällt mir“
Nicht unerwähnt bleiben sollte allerdings:
Bei Bedarf ist es auch möglich den HTML Sanitizer komplett zu deaktivieren. Hiervon wird stark abgeraten, da sonst folgende Sicherheitsrisiken bestehen.
-
Cross-Site Scripting (XSS)-Angriffe: HTML-Sanitizer helfen dabei, XSS-Angriffe zu verhindern, bei denen schädliche Skripte in den Code einer Website eingeschleust werden. Ohne ordnungsgemäßes sanitizing könnte ein Angreifer schädliche Skripte in den Shop einschleusen, was potenziell die Sicherheit von Benutzerdaten gefährdet, sensible Informationen stiehlt oder Malware verbreitet.
-
Datenintegrität und Vertraulichkeit: HTML-Sanitizer helfen dabei, die Integrität und Vertraulichkeit der von Benutzern eingegebenen Daten zu gewährleisten. Ohne sanitizing können Angreifer Schwachstellen ausnutzen, um Benutzerdaten zu modifizieren oder zu manipulieren, was zu potenziellen Datenschutzverletzungen, unbefugtem Zugriff oder Manipulation sensibler Informationen führen kann.
-
Reputation und Kundentrust: Wenn ein Shop aufgrund fehlendes sanitizing anfällig für Sicherheitsrisiken wird, kann dies den Ruf des Shops schädigen und das Vertrauen der Kunden untergraben. Nachrichten über Sicherheitsverletzungen, kompromittierte Benutzerdaten oder häufige Angriffe können Kunden davon abhalten, Einkäufe zu tätigen oder ihre persönlichen Informationen zu teilen, was sich negativ auf den Erfolg des Shops auswirkt.
-
Rechtliche und Compliance-Probleme: Unternehmen sind rechtlich verpflichtet, Kundendaten zu schützen und angemessene Sicherheitsmaßnahmen zu treffen. Das Fehlen eines ordnungsgemäßen HTML Sanitizer kann zu rechtlichen und Compliance-Problemen führen, einschließlich Geldstrafen, Klagen oder anderen rechtlichen Konsequenzen, wenn es zu einem Datenverstoß oder einer Verletzung des Datenschutzes kommt.
-
Betriebsstörungen und finanzielle Verluste: Erfolgreiche Angriffe auf einen Shop können zu Betriebsstörungen, Ausfallzeiten und finanziellen Verlusten führen. Die Behebung der Folgen eines Sicherheitsverstoßes, wie die Untersuchung des Vorfalls, die Implementierung von Korrekturen, die Benachrichtigung betroffener Kunden und die Wiederherstellung der Systeme, kann kostspielig und zeitaufwändig sein.
Eben nicht komplett. Bei den Textbausteinen greift clientseitig noch DOMPurify, der nicht konfiguriert werden kann . siehe oben.
2 „Gefällt mir“
Moin zusammen!
Wie sieht denn das bei den Mail-Templates aus, läuft da zufällig auch der Sanitizer drüber?
Ich wollte für einen Kunden gerade die Mails schicker machen, da hab ich festgestellt, dass das CSS, welches ich in den Standard-Head und -Footer der Mails einbinden möchte, nach dem Speichern entfernt wird.
Mein Beispiel:
{% verbatim %}
<style type="text/css">
/** Globals */
*{font-family:Helvetica,Verdana,Arial,sans-serif}
...
</style>
{% endverbatim %}
Alles zwischen den verbatim Tags wird jedoch entfernt. In 6.4. ist dies noch nicht so gewesen, dort setzen wir auf diese Weise erfolgreich CSS in die Shop-Mails ein.
Wir haben nun noch keinen bestehenden Shops mit angepassten Mail-Templates auf v6.5 hochgezogen, aber wäre schon blöd, wenn diese durch ein Shop-Update Ihre individuellen Mail-Layouts verlieren würden und wir die mühselig wieder neu erstellen müssten 
Kann man denn für Mail-Templates auch eine Ausnahme in die .yaml Datei eintragen? Oder sind diese so gar nicht vom Sanitizer betroffen?
LG;LA
Bei Mailtemplates scheint es auch Probleme zu geben. Beispielsweise wird
{{foo.bar | replace({'<br>': 'xyz'})}}
zum fehlerhaften
{{foo.bar | replace()}}
„umgeschrieben“.
1 „Gefällt mir“
Hier das Issue dazu.
Zitate Shopware:
Erschaffe das Herausragende
Bring dein Business auf ein neues Level mit maximaler Flexibilität
Je mehr ich damit arbeite, je mehr spüre ich das. Vor allem „maximaler Flexibilität” … genau mein Humor.
4 „Gefällt mir“
Danke für den Link! Das Ticket beschreibt allerdings ein spezielleres Problem, welches jetzt erstmal nichts mit der Anpassung der Mail-Templates zu tun hat.
@dneustadt Ich markiere Dich einfach mal in der Hoffnung, dass Du vielleicht einen Tipp hast? Werden Mail-Templates vom HTML-Sanitizer bereinigt?
Jede Info dazu wäre hilfreich - wir wollen die Mail-Templates auf keinen Fall im Standard belassen.
Kleine Side-Quest: Kann man eigentlich Mail-Templates in seinen Themes mitliefern? Wäre vom Aufwand her ganz geil, weil die Arbeit über das Backend auch ein wenig „frickelig“ ist.
LG;LA
Kann man eigentlich Mail-Templates in seinen Themes mitliefern?
Glaube nicht. Bei unserer Theme-Erstprüfung war ausversehen noch ein Dokumenten-Template drin. Das wurde angemahnt, dass das nichts in einem Theme zu suchen hätte.
Die spezifischen Mail-Templates, also quasi der Body der Mail, wenn man so will, werden explizit nicht sanitized, da man dort nicht die gleichen Maßstäbe anlegen kann, wie an HTML in den Storefront Templates. HTML in Emails ist einfach nochmal was anderes. Bei Header und Footer der Mails wird allerdings noch der Sanitizer verwendet, was einfach ein Oversight ist. Dort wird das basic Rule-Set verwendet und das kann, wie hier schon beschrieben, entsprechend erweitert werden, sodass alles was im Header/Footer gebraucht wird erlaubt ist. Alternativ kann jetzt in der neuesten Version der Sanitizer ganz abgeschaltet werden.
2 „Gefällt mir“
Infos hierzu bei 1:15 min.
Vielen Dank! Das hat mir sehr geholfen 
Ich konnte mein Problem damit lösen.
Für alle Suchenden:
Inline style Attribute: Dieses wird im Standard bereits vom basic Set zugelassen, man muss also keine z-shopware.yaml Datei erstellen.
<table class="mail" style="width:100%;max-width:100%;">
LG;LA
Hi,
wenn der Sanitizer deaktiviert wird, wird dieser nur für den Backend-Text-Editor deaktiviert, oder auch für das Frontend?
z-shopware.yaml
shopware:
html_sanitizer:
enabled: false
Wäre natürlich absolut bedenklich, wenn bei Shop-Bewertungen Tags eingefügt werden könnten.
Weiß zufällig jemand wie man dem HTML Sanitizer eigene Tags hinzufügen kann?
Wir nutzen ein Plugin was eine XML bei Bestellungseingang exportiert. Leider verwirft der HTML Sanitizer unsere XML Knoten. Es würde zwar funktionieren, wenn wir den HTML Sanitizer kommplett deaktivieren, dies wollen wir aber aus Sicherheitsgründen nicht.
Habe versucht die Knotenbezeichner den Tags hinzuzufügen aber das scheint so nicht zu funktionieren.
Für Hilfe und Ideen wäre ich dankbar.
-
Kannst du bitte kurz aufklären und auch in der Doku aufnehmen, ob der HTML-Sanitizer nur das Backend betrifft oder auch das Frontend?
-
Plant ihr auch SVG-Elemente zuzulassen? Momentan können in der Einkaufswelt keine Elemente mit SVGs mehr eingebaut werden, auf welche ein Hover-Effekt gelegt werden kann. Die SVG-Grafiken müssen in einem img Tag eingebunden werden und sind somit nicht mehr manipulierbar mit CSS.
Ist wohl etwas schwieriger und ähnelt dem Punkt von dem Kommentar über diesem, da es auch um XML-Strukturen geht.
Für jeden der nach einer Möglichkeit sucht den HTML-Sanitizer über das Backend zu deaktivieren, haben wir ein Plugin entwickelt:
Grüße
Adrian
Hallo Marco,
nein, es ist nicht plausibel, weil falsche Stelle und inkonsequent:
Im Frontend kann ein User eine Bewertung mit beliebigen HTML-Code eintragen.
Getestet habe ich mit Vers. 6.5.5.2:
- h1, a und button mit verschiedenen class und style-Attributen; alle lassen sich im Frontend eintragen und speichern.
- Diese Bewertung kann ich dann auch freischalten mit allem Code drin
- Editieren kann ich als Admin das Feld nicht.
- Aber wenn ich selber im Backend einen Kommentar zur Bewertung mit HTML-Code eintrage (z.B. einen Link auf eine interne Seite), dann greift der Sanitizer ein und löscht das.
Diese Logik erschliesst sich mir nicht!
Aber wir sind ja schon froh, dass Symfony wenigstens Javascript aus einer Bewertung entfernt.