Osticket: < Symbol Restlichen Text abschneiden

< und > sind reservierte HTML-Tag-Zeichen. Ihre Verwendung lässt den WYSIWYG-Editor und HTMLawed glauben, dass es sich um ein HTML-Tag handelt. Ungültige und einige spezifische werden entfernt. Für mich hört es sich so an, als würdest du in das hineinlaufen.

Hallo @ntozier ,

Ja du hast recht. Gibt es eine Möglichkeit, diese Symbole zu aktivieren, wenn ein Update zum Ticket veröffentlicht wird?

Danke schön,

Nicht, dass ich davon Wüste. Sie können versuchen, im Editor zur Codeansicht zu wechseln und &lt und &gt zu verwenden.

Hallo @ntozier ,

Vielen Dank für Ihre Antwort, ich weiß es zu schätzen.
Für den Agenten wird das funktionieren, aber wie wäre es mit der Client-Seite. Wenn sie dieses Symbol verwenden, wird ihre Nachricht abgeschnitten. Hoffe, dass jemand dieses Problem behebt.

Danke schön,

Hallo Leute,

Können Sie mir dabei helfen?

Danke schön,

Hallo @ntozier
Das ist definitiv ein Bug.

Das Problem liegt nicht beim Editor, er konvertiert "weniger als"-Symbole korrekt in die HTML-Entität. E-Mails von Clients sind ebenfalls betroffen, alles in einer Zeile nach einem "<" wird entfernt, wenn das Zeichen nur mit Escapezeichen versehen werden soll.

Das Problem tritt tatsächlich in class.format.php auf, wenn (standardmäßig) Format::safe_html diese Entitäten zurück in "<" decodiert, bevor die Eingabe über HtmLawed ausgeführt wird. Entitäten sind bereits desinfiziert, oder? Dennoch scheinen die Kommentare in safe_html < und > unsicher zu betrachten.

Meine Lösung bestand darin, FORMAT::sanitize in Zeile 340 zu bearbeiten und 'decode'=>false zu den Optionen hinzuzufügen.
$text = Format::safe_html($text, array('spec' => $spec,'decode'=>false));

Verpasse ich etwas? Habe ich mich für XSS geöffnet?
Würden Sie die Entwickler bitten, einen Blick darauf zu werfen?

Danke
Ben

Danke für die Fehlerbehebung. Funktioniert bei mir, es verursachte echte Probleme, als wir mit Formeln antworteten.

+1 für eine Lösung. Dieses Verhalten kann unmöglich erwartet/beabsichtigt werden. Ein < sollte beim Schreiben einer Antwort nur dann als Teil eines HTML-Tags behandelt werden, wenn der Benutzer explizit in den HTML-Modus gewechselt hat.

Bearbeiten: Wenn ich etwas Zeit finde, werde ich den von @bhspiers bereitgestellten Fix durchbekomme .

Dies ist auch ein Problem für mich, obwohl es bei mehr Zeichen als nur < passiert. Obwohl wir nicht feststellen konnten, welche Zeichen oder Codierungen das Problem verursachen, ist es uns in regelmäßigen Abständen aufgefallen.

@caseyamcl

< wird den Text definitiv abschneiden, da wir HTML-Tags im Text ausbalancieren. Das heißt, wenn es ein öffnendes Tag ohne schließendes Tag gibt, entfernen wir es aufgrund von unvollständigem/unausgeglichenem HTML. Wir sind uns bewusst, dass dies manchmal schmerzhaft sein kann und möchten dies in Zukunft angehen.

Beifall.

@JediKev Vielen Dank für die Antwort!

$text = Format::safe_html($text, array('spec' => $spec,'decode'=>false));

das ist noch nicht in master behoben, aber es funktioniert!

Wenn Sie den WYSIWYG-Editor verwenden, erwarten Sie, dass der Editor das < als Literal < und nicht als HTML-Starttag behandelt.
Das ist schlimm, da Sie es erst bemerken können, nachdem Sie die Nachricht gesendet haben

Immer noch ein Problem in v12 und unsere CSR-Mitarbeiter mögen es nicht, wenn ihre sorgfältig geschriebenen Nachrichten unerwartet abgeschnitten werden. Ich denke, dies sollte für das Kernteam eine ziemlich hohe Priorität haben, um es in Release-Versionen zu beheben.

Danke @bhspiers, dass du einen Patch gefunden hast.

@plong0

Ich verweise Sie auf diesen Kommentar oben:
https://github.com/osTicket/osTicket/issues/3791#issuecomment -416594799

Wir freuen uns über Ihr Feedback, und dies steht auf unserer Liste, um es in zukünftigen Versionen zu berücksichtigen.

Beifall.

Vielen Dank für die Antwort @JediKev - aber wenn mein Editor im WYSIWYG-Modus (nicht im HTML-Bearbeitungsmodus) eingestellt ist, sollte er nicht "<" in < konvertieren, bevor er eine HTML-Verarbeitung versucht?

Oder übersehe ich die Erwartung, dass jemand HTML-Tags in den WYSIWYG-Modus des Editors eingibt und erwartet, dass sie als HTML-Ausgabe gerendert werden?

Ein Randfall, den ich mir vorstellen kann, wäre das Kopieren und Einfügen von HTML-formatiertem Text in den WYSIWYG-Editor, aber bei diesem Problem geht es um die Kern-/Normalfunktionalität.

@JediKev , Während es zufällige einzelne '<'-Zeichen entfernt, scheint es, als würden vollständige Tags

@plong0 @knels

Wir verwenden HTMLawed mit bestimmten Konfigurationen (und anderen Methoden), um den Inhalt zu bereinigen, um "HTML sicher zu machen". Dies entfernt die meisten Tags, aber einige sind erlaubt, wie divs , tables , Styling-Tags usw. (aus offensichtlichen Gründen). Wenn Sie sich bereits mit HTMLawed beschäftigt haben, wissen Sie, dass es HTML ausbalanciert, was bedeutet, dass es versucht, den HTML-Inhalt zu vervollständigen, und wenn dies nicht erfolgreich ist, werden Tags entfernt, die ihn unvollständig machen. Wenn beispielsweise Test < 123 wird, wird alles nach dem < einschließlich des Tags selbst entfernt, da das Tag nicht abgeschlossen werden kann. Wenn Test <div> 123 wird, gibt HTMLawed Test <div> 123 </div> da es den HTML-Code vervollständigen oder "ausgleichen" könnte. Dies verhindert Rendering-Probleme und sogar _einige_ XSS/Injection-Versuche. Da wir die Nachrichten/Antworten auf der Seite in HTML rendern, müssen wir beim Ausbalancieren von HTML streng sein, um ein fehlerhaftes Rendering und jede Möglichkeit von XSS/Injection-Versuchen zu vermeiden.

Um @knels Frage von ... allows clients to reply and embed iframes into their ticket updates, is this intentional? zu beantworten; Ja, die von uns festgelegten HTMLawed-Konfigurationen erlauben iframes mit eingeschränkten Attributen.

Beifall.

Hatte gerade einen Benutzer, der eine Paste von einem Kompilierungsfehler gesendet hat: fast nutzlos, da das "Ziel" von #includes entfernt wurde.
Ich denke, dass die Verwendung von HTMLawed fehlerhaft ist :) Ich werde den @bhspiers- Patch ausprobieren.

Text aus dem WYSIWYG-Editor sollte WYSIWYG bleiben: Wenn Sie HTML-Code eingeben, ist es in Ordnung, ihn zu maskieren, damit er als Quelle angezeigt wird. Wenn Sie in den HTML-Modus wechseln, sollten Sie einige Tags verwenden können und Text sollte nicht automatisch maskiert werden.
Text aus E-Mails hängt vom Format der E-Mail ab: HTML-Mails müssen bereinigt werden (gefährliche Tags/Attribute entfernen), Text-Mails müssen nur mit Escapezeichen versehen werden.

Bitte wenden Sie einfach das Prinzip "weniger Überraschung" an.

Gleiches Problem mit dem Thema der internen Notizen.
Der Ticket-Betreff scheint sowohl von der E-Mail als auch von der Bedienerschnittstelle korrekt behandelt zu werden.

Ich habe das Problem mit weniger als in internen Notiztiteln "behoben", indem ich Zeile 343 von class.format.php geändert habe in:
$text = Format::safe_html($text, array('spec' => $spec, 'decode'=>false, 'balance'=>false));
(hinzugefügt ", 'balance'=>false").
Es ist nur ein Workaround und möglicherweise ein gefährlicher. Aber anscheinend wird es vom Browser nicht als Start-Tag interpretiert...
Wie auch immer, ist es ratsam, HTML-Code (auch wenn er reduziert) in Titeln zuzulassen?

Wir sind auf das gleiche Problem gestoßen und haben das gleiche Fix angewendet: um 'balance' in der safe_html() Funktion in include/class.format.php zu deaktivieren. Ich bin auch besorgt über die Auswirkungen auf die Sicherheit.

Das ist für uns ein echter Hingucker: Wir verwenden oft das "weniger-als"-Zeichen in Antworten an Kunden. Es erscheint mir auch logisch, dass alles, was im WYSIWYG-Editor eingegeben wird, NICHT als HTML interpretiert werden sollte.

Dieser Patch hat einen unangenehmen Nebeneffekt: HTML-Antworten werden normalerweise mit einem offenen 'div'-Tag (manchmal auch einem 'p'-Tag) abgeschnitten, und das bringt das Layout der Weboberfläche durcheinander.
Ich denke also, es gibt zwei unterschiedliche Probleme:
1) schlecht abgeschnittene eingehende Nachrichten (beim Entfernen des zitierten Teils)
2) Auswuchten funktioniert nicht wie erwartet
Wahrscheinlich 2) kann mit einem anderen Validator gelöst werden.

Um ein Beispiel für das Problem zu geben, auf das @NdK73 verweist, sehen Sie sich dieses Bild an:

https://www.dropbox.com/s/qwvhm7qhtc6lizc/osTicket-problem.png?dl=0

@caseyamcl

Aus diesem Grund entfernen wir die Tags ... wir haben Pläne, Code in Codeblöcken zuzulassen, die maskiert werden usw., also bleiben Sie dran.

Beifall.

@caseyamcl @NdK73

Das Problem ist, dass wir mit HTML-E-Mails umgehen. Die dortigen Tags müssen nicht maskiert werden, sonst wird die E-Mail in der Ticketansicht nicht richtig gerendert. Wie bestimmen Sie vor diesem Hintergrund, was rendert und was entkommen soll? Die Lösung besteht meistens darin, Code zuzulassen, aber nur in einem Codeblock oder ähnlichem, damit wir wissen, dass der Code im Block maskiert werden muss, der Rest muss so gerendert werden, dass er wie die tatsächlich gesendete E-Mail aussieht.

Beifall.

Nein: Sie können den Benutzern nicht vertrauen, Codeblöcke zu verwenden: Sie fügen einfach Code / Fehlermeldungen ein!
Die einzig praktikable Lösung (IMVHO) ist das Whitelisting von Tags: Alles, was ein bekanntes Tag ist, wird ausgeglichen. Der Rest bleibt so wie er ist.
Das ist, was Mail-Clients tun. Es ist ein Prozess mit mehreren Durchgängen: Zuerst gleichen Sie alle gültigen HTML-Tags aus und entfernen dann die in einer schwarzen Liste.

@NdK73

Es ist jedoch nicht so einfach ... Sie müssen über die Fälle nachdenken, in denen Sie HTML-Code an einen Benutzer senden möchten, ihn jedoch nicht als normalen Text rendern lassen. Da es sich bei dem Code um HTML handelt, wird er als E-Mail-Inhalt angezeigt und nicht entzogen, wodurch er gerendert wird. Sie benötigen einen Codeblock, um zu sagen "dieser Text ist speziell Code, der mit Escapezeichen versehen werden sollte".

Trotzdem liegst du nicht falsch. Es wird höchstwahrscheinlich eine Kombination aus mehreren Dingen sein, wie z. B. Codeblöcken und Tags auf der Whitelist/Blacklist (was safe_html /HTMLawed derzeit tut, bestimmte Tags auf die Whitelist und Blacklist setzt und die Tags auf der schwarzen Liste entfernt).

Beifall.

Es gibt zwei verschiedene Abläufe: Beim Empfangen muss ich "alles" akzeptieren (auch möglicherweise fehlerhafte/bösartige Inhalte), beim Senden muss ich wohlgeformten und sauberen Code senden. Wenn ich HTML-Code erzeuge, muss ich zuerst alles, was der Operator in den Textbereich eingibt, htmlencode() geben. Als Operator erwarte ich, dass der Empfänger, wenn ich ein HTML-Snippet einfüge, es uninterpretiert sieht ("Sie müssen <div>&nbsp;</div> verwenden, um dieses CSS anzuwenden" - übrigens musste ich dieses Beispiel manuell maskieren um es hier auf github richtig gerendert zu haben!).

@NdK73

Trotzdem liegst du nicht falsch. Es wird höchstwahrscheinlich eine Kombination aus mehreren Dingen wie Codeblöcken und Tags auf der Whitelist/Blacklist sein

Für eine Teillösung (die nur Webeingaben adressiert) können Sie einen Blick auf https://www.froala.com/online-html-editor werfen: Es kodiert automatisch eingegebene Entitäten, sobald der Benutzer sie eingibt. Der Nachteil ist, dass Operatoren und Benutzer auf die "geknöpften" Tags beschränkt sind ... Aber ist das wirklich ein Nachteil?

Ein weiterer interessanter Editor kann http://wymeditor.github.io sein -- er folgt dem Paradigma "What You See Is What You Mean". Anschauen lohnt sich wahrscheinlich.

Hallo zusammen, um zu verhindern, dass die Antworten/Notizen nach dem "<"-Symbol abgeschnitten werden, haben wir einen Workaround versucht, um < und > automatisch durch ＜ ＞ . zu ersetzen
Falls es helfen könnte, hier unsere Änderungen zu htmldecode($var) in class.format.php :

--- a/include/class.format.php
+++ b/include/class.format.php
@@ -402,6 +402,15 @@ class Format {
         if (phpversion() >= '5.4.0')
             $flags |= ENT_HTML401;

+        $var = preg_replace_callback("/(&#(?:[0-9]+|x[0-9a-f]+);)/i", function($entity) use ($flags) {
+            return htmlentities(html_entity_decode($entity[1], $flags), $flags);
+        }, $var);
+
+        $var = str_replace(
+            array('<', '>'),
+            array('＜', '＞'),
+        $var);
+
         return htmlspecialchars_decode($var, $flags);
     }