做企业网站要怎么设计方案忘记wordpress
在 View 层，可以解决 XSS 问题。在本书的“跨站脚本攻击”一章中，阐述了“输入检查” 与“输出编码”这两种方法在 XSS 防御效果上的差异。XSS 攻击是在用户的浏览器上执行的， 其形成过程则是在服务器端页面渲染时，注入了恶意的 HTML 代码导致的。从 MVC 架构来说， 是发生在 View 层，因此使用“输出编码”的防御方法更加合理，这意味着需要针对不同上下 文的 XSS 攻击场景，使用不同的编码方式。
在“跨站脚本攻击”一章中，我们将“输出编码”的防御方法总结为以下几种： 在 HTML 标签中输出变量； 在 HTML 属性中输出变量； 在 script 标签中输出变量； 在事件中输出变量； 在 CSS 中输出变量； 在 URL 中输出变量。
针对不同的情况，使用不同的编码函数。那么现在流行的 MVC 框架是否符合这样的设计 呢？答案是否定的。
在当前流行的 MVC 框架中，View 层常用的技术是使用模板引擎对页面进行渲染，比如在“跨站脚本攻击”一章中所提到的 Django，就使用了 Django Templates 作为模板引擎。模板引 擎本身，可能会提供一些编码方法，比如，在 Django Templates 中，使用 filters 中的 escape 作 为 HtmlEncode 的方法： Hello, {{ name|escape }}!
Django Templates 同时支持 auto-escape，这符合 Secure by Default 原则。现在的 Django Templates，默认是将 auto-escape 开启的，所有的变量都会经过 HtmlEncode 后输出。默认是编 码了 5 个字符：
< is converted to <
> is converted to >
' (single quote) is converted to '
" (double quote) is converted to "
& is converted to & 如果要关闭 auto-escape，则需要使用以下方法：
{{ data|safe }}
{% autoescape off %} Hello {{ name }} {% endautoescape %}
为了方便，很多程序员可能会选择关闭 auto-escape。要检查 auto-escape 是否被关闭也很简 单，搜索代码里是否出现上面两种情况即可。
但是正如前文所述，最好的 XSS 防御方案，在不同的场景需要使用不同的编码函数，如 果统一使用这 5 个字符的 HtmlEncode，则很可能会被攻击者绕过。由此看来，这种 auto-escape 的方案，看起来也变得不那么美好了。
再看看非常流行的模板引擎 Velocity，它也提供了类似的机制，但是有所不同的是，Velocity 默认是没有开启 HtmlEncode 的。
在 Velocity 中，可以通过 Event Handler 来进行 HtmlEncode。
eventhandler.referenceinsertion.class = org.apache.velocity.app.event.implement.
EscapeHtmlReference
eventhandler.escape.html.match = /msg.*/ 使用方法如下例，这里同时还加入了一个转义 SQL 语句的 Event Handler。
import org.apache.velocity.app.event.EventCartridge;
import org.apache.velocity.app.event.ReferenceInsertionEventHandler;
import org.apache.velocity.app.event.implement.EscapeHtmlReference;
import org.apache.velocity.app.event.implement.EscapeSqlReference;
public class Test
{ public void myTest() { .... /** * Make a cartridge to hold the event handlers */ EventCartridge ec = new EventCartridge(); /* * then register and chain two escape-related handlers */ ec.addEventHandler(new EscapeHtmlReference()); ec.addEventHandler(new EscapeSqlReference()); /* * and then finally let it attach itself to the context */ ec.attachToContext( context ); /* * now merge your template with the context as you normally * do */ .... } } 但 Velocity 提供的处理机制，与 Django 的 auto-escape 所提供的机制是类似的，都只进行 了 HtmlEncode，而未细分编码使用的具体场景。不过幸运的是，在模板引擎中，可以实现自定 义的编码函数，应用于不同场景。在 Django 中是使用自定义 filters，在 Velocity 中则可以使用 “宏”(velocimacro)，比如：
通过自定义的方法，使得 XSS 防御的功能得到完善；同时在模板系统中，搜索不安全的 变量也有了依据，甚至在代码检测工具中，可以自动判断出需要使用哪一种安全的编码方法， 这在安全开发流程中是非常重要的。
在其他的模板引擎中，也可以依据“是否有细分场景使用不同的编码方式”来判断 XSS 的安全方案是否完整。在很多 Web 框架官方文档中推荐的用法，就是存在缺陷的。Web 框架 的开发者在设计安全方案时，有时会缺乏来自安全专家的建议。所以开发者在使用框架时，应 该慎重对待安全问题，不可盲从官方指导文档。