60.3.1。转义输出
最重要的任务之一 在视图脚本中执行即可 确保输出正确转义; 除此之外，这有助于 避免跨站点脚本攻击。 除非您使用的是函数， 方法，或逃脱的助手 就你自己而言，你应该总是逃避 输出时的变量。
为什么'总是'？为什么我必须转义未被用户输入创建或更改的变量？
答案 0 :(得分：9)
用户不是输出中唯一的狡猾字符串来源。例如，考虑一个来自数据库的明显安全的字符串“Romeo＆amp; Juliet”。你说没有跨站点脚本吗？真的够了。但是，将它粘贴在一个网页中，原始的＆符号可能会导致验证，解析等一些有趣的问题。
输出转义不仅仅是为了防止恶意或意外的输入，它确保输出被彻底清理并被视为在周围的输出格式中没有特殊含义，无论是HTML，XML，JSON还是其他任何东西。< / p>
答案 1 :(得分：4)
作为一项规则，我会逃避任何来自用户输入，数据源甚至计算的内容。您希望输出是可预测的，转义确保它是可预测的。如果转换为字符串时的值包含破坏所需标记的字符，那么事情就会变得混乱。
如果您使用的是视图，$this->escape($variableToEscape)就足够了。
答案 2 :(得分：2)
另一件事情很多时候，有一天硬编码的东西成为用户或至少是另一天生成的数据库。更好的做法是管理代码中的变量输出。
答案 3 :(得分：1)
您可以这样看待它：您应该始终对变量进行HTML编码，除非您知道它们已经被编码。
假设您有一个包含以下内容的变量：
foo <b>bar</b>
如果您知道它包含HTML标记，并且您对此感到满意，那么您可以说此变量已经过正确的HTML编码。您甚至可以将其分配给不同的变量类型，以使编译器了解区别（Joel的想法），并让输出函数处理这些类型而不转义它们。
当然，这意味着
foo & <b>bar</b>
是一个不正确的值;你需要确保它是：
foo & <b>bar</b>
答案 4 :(得分：1)
我认为除非您打算输出原始HTML片段，否则此处的最佳做法始终是转义输出。即使“安全”数据也可以包含需要转义的字符。例如，考虑电子邮件地址“Bob”＆lt; bob@bob.com>'。如果你没有逃脱它，浏览器会想到＆lt; bob@bob.com>是一个标签。
答案 5 :(得分：1)
显然，您希望避免因用户数据而导致的XSS攻击事件。由于你经常改变你要重新发布的内容以及你不重新发布的内容，你可能记不起所有需要更改的地方......所以即使你现在所有细微差别都正确，你的网站也是如此从今天的XSS脚本安全来看，你可能在某些时候可能会将用户输入添加到你没有逃避的某个变量（或者更可能的是，某些变量变量到某个你没有逃避的变量），这会打开你XSS攻击。
默认情况下转义可以防止该攻击。
另一个原因更具概念性：使用MVC，所有标记 - 根据定义，“视图” - 应该在您的视图模板中。因此，如果您的控制器正在确定视图，并且视图包含所有标记，为什么不转义变量？
答案 6 :(得分：0)
好吧，如果你有硬编码的值（比如你从数据库或XML文件中读取的语言翻译），你就不必逃避它们。
但是如果有一个值已经由用户创建/修改，即使让我们说在管理面板中，你必须逃避它，因为你不知道用户是什么类型的，或者我是否更激进，即使是管理员，也会发送。