Osticket: < 符号 截断剩余文本

< 和 > 是保留的 HTML 标记字符。 使用它们会触发 WYSIWYG 编辑器和 HTMLawed 认为它是一个 HTML 标记。 无效的，以及一些特定的被剥离。 在我看来，你正在遇到这种情况。

你好@ntozier ，

是的，你是对的。 在票证上发布更新时，有没有办法让这些符号起作用？

谢谢，

从来没听说过。 您可以尝试拖放到编辑器中的代码视图并使用 &lt 和 &gt。

你好@ntozier ，

谢谢你的回复，我很感激。
对于可以工作的代理，但对于客户端呢？ 如果他们使用该符号，他们的信息将被截断。 希望有人解决这个问题。

谢谢，

嗨，大家好，

你能帮我解决这个问题吗？

谢谢，

嗨@ntozier
这绝对是一个错误。

问题不在于编辑器，它正确地将“小于”符号转换为 html 实体。 来自客户的电子邮件也会受到影响，“<”之后的一行上的所有内容都会被删除，而此时字符应该被转义。

这个问题实际上发生在class.format.php时（默认）格式:: safe_html解码这些实体回“<”，通过HtmLawed运行输入之前。 实体已经被消毒了对吧？ 然而，safe_html 中的注释似乎认为<和>不安全。

我的解决方法是在第 340 行编辑 FORMAT::sanitize 并将 'decode'=>false 添加到选项中。
$text = Format::safe_html($text, array('spec' => $spec,'decode'=>false));

我错过了什么吗？ 我对 XSS 开放了吗？
你会要求开发人员看看吗？

谢谢
本

感谢您的修复。 对我有用，当我们用公式回答时，它会引起真正的问题。

+1 进行修复。 这不可能是预期/预期的行为。 在编写回复时，唯一应将<视为 HTML 标记的一部分的情况是用户已明确切换到 HTML 模式。

编辑：如果我有时间我会测试@bhspiers提供的

这对我来说也是一个问题，尽管它发生的字符不仅仅是< 。 虽然我们无法确定导致问题的字符或编码，但我们会定期注意到它。

@caseyamcl

<肯定会截断文本，因为我们平衡了文本中的 HTML 标签。 这意味着如果有一个没有结束标签的开始标签，那么由于 HTML 不完整/不平衡，我们将其删除。 我们知道这有时会很痛苦，我们希望在未来解决这个问题。

干杯。

@JediKev 非常感谢您的回复！

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

这仍然没有在 master 中修复，但它有效！

如果您使用 WYSIWYG 编辑器，您希望编辑器将 < 视为文字 < 而不是 HTML 开始标记。
这很糟糕，因为在您发送消息之前您不会注意到它

在 v12 中仍然存在问题，我们的 CSR 员工不喜欢他们精心编写的消息被意外截断。 我觉得这应该是核心团队在发布版本中修复的一个相当高的优先级。

感谢@bhspiers找到补丁。

@plong0

我将向您推荐上面的这条评论：
https://github.com/osTicket/osTicket/issues/3791#issuecomment -416594799

我们感谢您的反馈，这是我们在未来版本中要解决的问题。

干杯。

感谢@JediKev的回复 - 但是如果我的编辑器设置为所见即所得模式（不是 HTML 编辑模式），在尝试对其进行任何 HTML 处理之前，它不应该将“<”转换为<吗？

或者我是否忽略了有人可能会在编辑器的 WYSIWYG 模式中输入 HTML 标签并期望它们被呈现为 HTML 输出的期望？

我能想到的一种极端情况是将 HTML 格式的文本复制并粘贴到 WYSIWYG 编辑器中，但这个问题与核心/正常功能有关。

@JediKev ，虽然它确实去

@plong0 @knels

我们使用带有特定配置（和其他方法）的 HTMLawed 来清理内容以“使 HTML 安全”。 这会删除大多数标签，但有些标签是允许的，例如divs 、 tables 、样式标签等（出于显而易见的原因）。 如果您在处理过 HTMLawed 之前就知道它会平衡 HTML，这意味着它将尝试使 HTML 内容完整，如果不成功将删除使其不完整的标签。 例如，如果Test < 123传递一切后， <包括标签为标签不能完成本身将被删除。 如果传递了Test <div> 123 ，则 HTMLawed 将返回Test <div> 123 </div>因为它可以完成或“平衡”HTML。 这可以防止渲染问题，甚至 _some_ XSS/Injection 尝试。 由于我们在页面上以 HTML 格式呈现消息/响应，因此我们必须严格平衡 HTML 以避免渲染中断和任何 XSS/注入尝试的机会。

回答... allows clients to reply and embed iframes into their ticket updates, is this intentional? @knels问题； 是的，我们设置的 HTMLawed 配置允许具有有限属性的iframes 。

干杯。

刚刚有一个用户从编译错误中发送了一个粘贴：几乎没用，因为#includes 已经删除了他们的“目标”。
我认为如果 FLawed 使用 HTMLawed :) 我会尝试@bhspiers补丁。

WYSIWYG 编辑器中的文本应保持 WYSIWYG：如果您输入 HTML 代码，则可以对其进行转义，以便将其显示为源代码。 如果你切换到 HTML 模式，那么你应该可以使用一些标签，并且文本不应该被自动转义。
邮件中的文本取决于邮件的格式：HTML 邮件需要清理（删除危险标签/属性），文本邮件只需要转义。

请只应用“少惊喜”的原则。

内部注释的主题也有同样的问题。
工单主题似乎从邮件和操作员界面都得到了正确处理。

我“修复”了这个问题，将 class.format.php 的第 343 行更改为：
$text = Format::safe_html($text, array('spec' => $spec, 'decode'=>false, 'balance'=>false));
（添加“，'平衡'=>假”）。
这只是一种解决方法，并且可能是一种危险的方法。 但它似乎没有被浏览器解释为开始标签......
无论如何，在标题中允许 HTML 代码（即使减少）是否明智？

我们遇到了同样的问题并应用了相同的修复：在include/class.format.php的safe_html()函数中禁用“余额”。 我也担心这会带来安全隐患。

这对我们来说确实是一个噱头：我们经常在回复客户时使用“小于”字符。 在我看来，在所见即所得编辑器中输入的任何内容都不应该被解释为 HTML，这也是合乎逻辑的。

该补丁确实有一个令人讨厌的副作用：HTML 回复通常会被一个开放的“div”标签（有时也是一个“p”标签）截断，这会扰乱 Web 界面的布局。
所以我认为有两个明显的问题：
1）严重截断传入消息（删除引用部分时）
2) 平衡没有按预期工作
可能 2) 可以通过使用不同的验证器来解决。

要举例说明@NdK73所引用的问题，请参见此图：

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

@caseyamcl

这就是我们剥离标签的原因......我们计划最终允许代码块中的代码被转义等，所以请继续关注。

干杯。

@caseyamcl @NdK73

问题是我们处理的是 HTML 格式的电子邮件。 那里的标签不需要转义，否则电子邮件将无法在工单视图中正确呈现。 考虑到这一点，您如何确定要渲染什么以及逃避什么？ 解决方案通常是允许代码，但只允许在代码块或类似的东西中，因此我们知道块中的代码需要转义，其余部分需要呈现为看起来像发送的实际电子邮件。

干杯。

不：您不能相信用户使用代码块：他们只会粘贴代码/错误消息！
唯一可行的解​​决方案 (IMVHO) 是将标签列入白名单：所有已知标签都会得到平衡。 其余的保持原样。
这就是邮件客户端所做的。 这是一个多遍过程：首先平衡所有有效的 HTML 标记，然后去除黑名单中的标记。

@NdK73

但这并不是那么简单……您必须考虑要将 HTML 代码发送给用户但又不将其呈现为普通文本的情况。 由于代码是 HTML，它会将其视为电子邮件内容，而不会对其进行转义，从而导致其被呈现。 您需要一个代码块来说明“此文本专门是应该转义的代码”。

不管怎样，你没有错。 它很可能是多个事物的组合，例如代码块和列入白名单/列入黑名单的标签（ safe_html /HTMLawed 当前所做的，将某些标签列入白名单和黑名单并删除列入黑名单的标签）。

干杯。

有两种不同的流程：接收时我必须接受“一切”（甚至可能是格式错误/恶意的内容），发送时我必须发送格式正确且干净的代码。 如果我正在生成 HTML 代码，那么我首先必须 htmlencode() 操作员在 textarea 中输入的所有内容。 作为操作员，我希望如果我粘贴一个 HTML 片段，接收者会看到它没有被解释（“你必须使用 <div>&nbsp;</div> 来应用这个 css”——顺便说一句，我不得不手动转义这个例子让它在 github 上正确呈现！）。

@NdK73

不管怎样，你没有错。 它很可能是多种事物的组合，例如代码块和列入白名单/黑名单的标签

对于部分解决方案（仅解决 Web 输入），您可以查看https://www.froala.com/online-html-editor ：一旦用户输入它们，它就会自动对输入的实体进行编码。 缺点是运营商和用户受限于“按钮化”标签……但这真的是缺点吗？

另一个有趣的编辑器可以是http://wymeditor.github.io——它遵循“所见即所得”范式。 大概值得一看。

大家好，为了防止回复/注释在“<”符号后被截断，我们尝试了一种解决方法，将 < 和 > 自动替换为 ＜ ＞
如果有帮助，这里我们对class.format.php htmldecode($var)更改：

--- 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);
     }