《白帽子讲Web安全》| 学习笔记之Web框架安全

第12章  Web框架安全

1、MVC框架安全

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

在Spring框架中可以使用spring security来增加系统的安全性。

2、模板引擎与XSS防御

在view层可以解决xss问题。使用”输出编码“的防御方法更好。

3、Web框架与CSRF防御

在web框架中可以使用security token解决CSRF攻击的问题。

• 在Session中绑定token。如果不能保存到数据库中的Session，则可以保存到Cookie.
• 在form表单中自动填写token字段，比如<input type=hidden name="anti_csrf_token" value="$token"/>
• 在Ajax请求中封装token。
• 在服务器端对比POST提交的token与Session绑定的Token是否一致，以验证CSRF的攻击。

4、HTTP Headers管理

对HTTP头的CSRF注入的防御，可以对HTTP进行全局化处理。

对抗CRLF的方案只需要在"value"中编码所有的\r\n即可。这里没有提到在"key"中编码\r\n，是因为让用户能够控制"key"是极其危险的事情，在任何情况下都不应该使其发生。

对于框架来说，管理好跳转目的地址是很有必要的。一般来说，可以在两个地方做这件事情：

1. 如果Web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中；
2. 另一种解决方式是控制HTTP的Location字段，限制Location的值只能是哪些地址，也能起到同样的效果，其本质还是白名单。

有很多与安全相关的Headers，也可以统一在Web框架中配置。比如用来对抗ClickJacking的X-Frame-Options，需要在页面的HTTP Response中添加：

X-Frame-Options: SAMEORIGIN

Web框架可以封装此功能，并提供页面配置。该HTTP头有三个可选的值：SAMEORIGIN、DENY、ALLOW-FROM origin，适用于各种不同的场景。

并不是所有的Web服务器、Web容器、脚本语言提供的API都支持设置HttpOnly Cookie，所以很多时候需要由框架实现一个功能：对所有的Cookie默认添加HttpOnly，不需要此功能的Cookie则单独在配置文件中列出。

这将是非常有用的一项安全措施，在框架中实现的好处就是不用担心会有遗漏。就HttpOnly Cookie来说，它要求在所有服务器端设置该Cookie的地方都必须加上，这可能意味着很多不同的业务和页面，只要一个地方有遗漏，就会成为短板。当网站的业务复杂时，登录入口可能就有数十个，兼顾所有Set-Cookie页面会非常麻烦，因此在框架中解决将成为最好的方案。

一般来说，框架会提供一个统一的设置Cookie函数，HttpOnly的功能可以在此函数中实现；如果没有这样的函数，则需要统一在HTTP返回头中配置实现。

5、数据持久层与SQL注入

对抗SQL注入最佳方式是使用”预编译绑定变量“。使用ORM(Object/Relation Mapping)框架对SQL注入是有积极意义的。

6、其他

在设计Web框架安全解决方案时，还需要保存好安全检查的日志。在设计安全逻辑时也需要考虑到日志的记录，比如发生XSS攻击时，可以记录下攻击者的IP、时间、UserAgent、目标URL、用户名等信息。这些日志，对于后期建立攻击事件分析、入侵分析都是有积极意义的。当然，开启日志也会造成一定的性能损失，因此在设计时，需要考虑日志记录行为的频繁程度，并尽可能避免误报。

在设计Web框架安全时，还需要与时俱进。当新的威胁出现时，应当及时完成对应的防御方案，如此一个Web框架才具有生命力。而一些0day漏洞，也有可能通过"虚拟补丁"的方式在框架层面解决，因为Web框架就像是一层外衣，为Web应用提供了足够的保护和控制力。

7、总结

Web框架在提高安全的同时，自身安全性也不可忽视。