<转>12.1 MVC框架安全

《白帽子讲Web安全》第12章Web框架安全，本章讲述了一些Web框架中可以实施的安全方案。Web框架 本身也是应用程序的一个组成部分，只是这个组成部分较为特殊，处于基础和底层的位置。Web框架为安全方案的设计提供了很多便利，好好利用它的强大功能， 能够设计出非常优美的安全方案。本节为大家介绍MVC框架安全。

AD：【线下活动】三大新锐HTML 5企业汇聚51CTO—大话移动前端技术

第12章 Web框架安全

前面的章节，我们讨论了许多浏览器、服务器端的安全问题，这些问题都有对应的解决方法。总的来说，实施安全方案，要达到好的效果，必须要完成两个目标：

（1）安全方案正确、可靠；

（2）能够发现所有可能存在的安全问题，不出现遗漏。

只有深入理解漏洞原理之后，才能设计出真正有效、能够解决问题的方案，本书的许多篇幅，都是介绍漏洞形成的根本原因。比如真正理解了XSS、SQL 注入等漏洞的产生原理后，想彻底解决这些顽疾并不难。但是，方案光有效是不够的，要想设计出完美的方案，还需要解决第二件事情，就是找到一个方法，能够让 我们快速有效、不会遗漏地发现所有问题。而Web开发框架，为我们解决这个问题提供了便捷。

12.1  MVC框架安全

在现代Web开发中，使用MVC架构是一种流行的做法。MVC是Model-View-Controller的缩写，它将Web应用分为三 层，View层负责用户视图、页面展示等工作；Controller负责应用的逻辑实现，接收View层传入的用户请求，并转发给对应的Model做处 理；Model层则负责实现模型，完成数据的处理。

 

MVC框架示意图

从数据的流入来看，用户提交的数据先后流经了View层、Controller、Model层，数据的流出则反过来。在设计安全方案时，要牢牢把握 住数据这个关键因素。在MVC框架中，通过切片、过滤器等方式，往往能对数据进行全局处理，这为设计安全方案提供了极大的便利。

比如在Spring Security中，通过URL pattern实现的访问控制，需要由框架来处理所有用户请求，在Spring Security获取了URL handler基础上，才有可能将后续的安全检查落实。在Spring Security的配置中，第一步就是在web.xml文件中增加一个filter，接管用户数据。

<filter>
  <filter-name>springSecurityFilterChain</filter-name>
  <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
</filter>

<filter-mapping>
  <filter-name>springSecurityFilterChain</filter-name>
  <url-pattern>/*</url-pattern>
</filter-mapping>

然而数据的处理是复杂的，数据经过不同的应用逻辑处理后，其内容可能会发生改变。比如数据经过toLowercase，会把大写变成小写；而一些编 码解码，则可能会把GBK变成Unicode码。这些处理都会改变数据的内容，因此在设计安全方案时，要考虑到数据可能的变化，认真斟酌安全检查插入的时 机。

在本书第1章中曾经提到，一个优秀的安全方案，应该是：在正确的地方，做正确的事情。

举例来说，在"注入攻击"一章中，我们并没有使用PHP的magic_quotes_gpc 作为一项对抗SQL注入的防御方案，这是因为magic_quotes_gpc是有缺陷的，它并没有在正确的地方解决问题。 magic_quotes_gpc实际上是调用了一次addslashes()，将一些特殊符号（比如单引号）进行转义，变成了 \' 。

对应到MVC架构里，它是在View层做这件事情的，而SQL注入是Model层需要解决的问题，结果如何呢？黑客们找到了多种绕过magic_quotes_gpc 的办法，比如使用GBK编码、使用无单引号的注入等。

PHP官方在若干年后终于开始正视这个问题，于是在官方文档 的描述中不再推荐大家使用它：

 

（点击查看大图）PHP官方声明取消Magic Quotes

所以Model层的事情搞到View层去解决，效果只会适得其反。

一般来说，我们需要先想清楚要解决什么问题，深入理解这些问题后，再在"正确"的地方对数据进行安全检查。一些主要的Web安全威胁，如XSS、CSRF、SQL注入、访问控制、认证、URL跳转等不涉及业务逻辑的安全问题，都可以集中放在MVC框架中解决。

在框架中实施安全方案，比由程序员在业务中修复一个个具体的bug，有着更多的优势。

首先，有些安全问题可以在框架中统一解决，能够大大节省程序员的工作量，节约人力成本。当代码的规模大到一定程度时，在业务的压力下，专门花时间去一个个修补漏洞几乎成为不可能完成的任务。

其次，对于一些常见的漏洞来说，由程序员一个个修补可能会出现遗漏，而在框架中统一解决，有可能解决"遗漏"的问题。这需要制定相关的代码规范和工具配合。

最后，在每个业务里修补安全漏洞，补丁的标准难以统一，而在框架中集中实施的安全方案，可以使所有基于框架开发的业务都能受益，从安全方案的有效性来说，更容易把握。