为什么要“始终”转义? 为什么必须转义那些没有被用户输入创建或更改的变量?60.3.1. 转义输出
在视图脚本中执行的最重要任务之一是确保输出被正确地转义;其中,这可以帮助避免跨站点脚本攻击。除非您正在使用一个能够自行转义的函数、方法或辅助工具,否则在输出变量时,您应该始终进行转义。
为什么要“始终”转义? 为什么必须转义那些没有被用户输入创建或更改的变量?60.3.1. 转义输出
在视图脚本中执行的最重要任务之一是确保输出被正确地转义;其中,这可以帮助避免跨站点脚本攻击。除非您正在使用一个能够自行转义的函数、方法或辅助工具,否则在输出变量时,您应该始终进行转义。
用户不是输出中可疑字符串的唯一来源。例如,从数据库中输出的看似安全的字符串"Romeo & Juliet"。你说这里没有跨站脚本漏洞?当然没错。但是如果把它放在网页中,原始的&符号可能会导致验证、解析等方面出现一些有趣的问题。
输出转义不仅仅是为了防范恶意或意外损坏的输入,而且确保输出经过彻底的净化,并被视为在周围的输出格式中没有特殊含义,无论是HTML、XML、JSON还是其他格式。
$this->escape($variableToEscape)
应该足够。另外一件事是,有很多时候,一些被硬编码的内容,在另一天可能会变成用户或至少是数据库生成的内容。更好的做法是在代码中管理变量的输出。
foo <b>bar</b>
foo & <b>bar</b>
是一个不正确的值;您需要确保它是:
foo & <b>bar</b>
显然,您希望转义用户数据的结果以防止XSS攻击。由于您经常更改重新发布和不重新发布的内容,您可能无法记住需要更改的所有位置...因此,即使您现在正确理解了所有细微差别,并且您的网站今天免受XSS脚本的攻击,但您可能会在某个时候将用户输入添加到某些未转义的变量中(或更有可能是一些变量到一些变量到一些变量,您没有进行转义),这将使您面临XSS攻击。
默认情况下进行转义可以防止该攻击。
另一个原因更为概念化:使用MVC,您的所有标记(定义为“视图”)都应在视图模板中。因此,如果您的控制器确定了视图,并且视图包含所有标记,为什么不转义您的变量呢?
如果你有硬编码的数值(比如说语言翻译,从数据库或XML文件读取),你不需要转义它们。
但是如果一个数值是由用户创建/修改的,即使在管理面板中,你必须要转义它,因为你不知道用户发送的数据类型是什么,甚至更极端一点,就算是管理员也不例外。