第12章 Web框架安全
总的来说，实施安全方案，要达到好的效果，必须要完成两个目标：
- 安全方案正确、可靠
- 能够发现所有可能存在的安全问题，不出现遗漏
12.1 MVC框架安全
- MVC架构：Model-View-Controller
- 一个优秀的安全方案，应该是：在正确的地方，做正确的事情。
- 数据在经过不同的应用逻辑处理后，其内容可能会发生改变。因此在设计安全方案时，要考虑到数据可能的变化，认真斟酌安全检查插入的时机。
- 在框架中实施安全方案，比由程序员在业务中修复一个个具体的bug，有着更多的优势。
- 有些安全问题可以在框架中统一解决，能够大大节省程序员的工作量，节约人力成本。
- 对于一些常见的漏洞来说，由程序员一个个修补可能会出现遗漏，而在框架中统一解决，有可能解决“遗漏”的问题。
- 在每个业务里修补安全漏洞，补丁的标准难以统一。而在框架中集中实施的安全方案，可以使所有基于框架开发的业务都嗯那个受益，从安全方案的有效性来说，更容易把握。
12.2 模板引擎与XSS防御
- 从MVC架构来说，XSS时发生在View层，因此使用“输出编码”的防御方法更加合理。
- 这意味着需要针对不同上下文的XSS攻击场景，使用不同的编码方式。
- 当代流行的MVC框架中，View层常用的技术是使用模板引擎对页面进行渲染，比如Django Templates作为模板引擎。
- Django的auto-escape机制。
- 开发者在使用框架时，应该慎重对待安全问题，不可盲从官方指导文档。
12.3 Web框架与CSRF防御
- CSRF攻击的目标，一般都会产生“写数据”操作的URL，比如“增删改”；而“读数据”操作并不是CSRF攻击的目标，因为在CSRF的攻击过程中攻击者无法获取到服务器端返回的数据，攻击者只是借用户之手触发服务器动作，所以读数据对于CSRF来说并无直接的意义。
- 因此，在Web应用开发中，有必要对“读操作”和“写操作”予以区分，比如要求所有的“写操作”都使用HTTP POST。
- POST的使用，对于保护token有者积极的意义，而security token的私密性（不刻预测性原则），是防御CSRF攻击的基础。
- 完整的CSRF防御方案，对于Web框架来说有以下基础地方需要改动。
- 在Sessin中绑定token
- 在form表单中自动填入token字段
- 在Ajax请求中自动添加token，这可能需要已有的Ajax封装实现的支持
- 在服务器端对比POST提交参数的token与Session中绑定的token是否一致，以验证CSRF攻击。
- 书中针对Spring MVC，Django和Rails等框架举例。
12.4 HTTP Headers管理
- 在Web框架中，可以对HTTP头进行全局化的处理，因此一i邪恶基于HTTP头的安全方案可以很好地实施。
- 对于框架来说，管理好跳转目的地址是很有必要的。一般来说，可以在两个地方做这件事：
- Web框架提供的统一跳转函数，在内部实现一个白名单；
- 控制HTTP的Location字段，限制Location的值只能是哪些地址（本质还是白名单）
- 有很多与安全相关的Headers，也可以统一在Web框架中配置。
- HttpOnly Cookie
12.5 数据持久层与SQL注入
- 使用ORM（Object/Realtion Mapping）框架对SQL注入是有积极意义的。
- 对抗SQL注入的最佳方式就是使用“预编译绑定变量”。
- 实际解决SQL注入是，有一个难点是应用复杂后，代码数量庞大，难以把可能存在SQL注入的地方不遗漏地找出来，而ORM框架为我们发现问题提供了一个便捷的途径。
- 使用Web框架提供的功能，在代码风格上更加统一，也更利于代码审计。
12.6 还能想到什么
- 凡是在Web框架中可能实现的安全方案，只要对性能没有太大的损耗，都应该考虑实施。
- 在设计整体安全方案时，比较科学的方法：
- 首先建立威胁模型
- 然后再判断哪些威胁时可以在框架中得到解决的
- 在设计Web框架安全解决方案时，还需要保存好安全检查的日志。
- 设计Web框架安全也要与时俱进。
12.7 Web框架自身安全
- Struts2命令执行漏洞
- 远程执行代码的漏洞
- Spring MVC命令执行漏洞
- 远程执行命令漏洞
- Django命令执行漏洞
- 远程执行命令漏洞（“命令注入”漏洞）