第12章 WEB框架安全

12.1 MVC框架安全

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

12.2 模板引擎与XSS防御

12.3 WEB框架与CSRF防御

在MVC中防御CSRF：

q  在Session中绑定token。如果不能保存到数据库中的Session，则使用Cookie.

q  在form表单中自动填写token字段

q  在Ajax请求中封装token。

q  在服务器端对比POST提交的token与Session绑定的Tiken是否一致。

q  尽量使用POST

12.4 Http Headers管理

在MVC框架中对响应的HTTP头做好防御和返回

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

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

q  如果Web框架提供统一的跳转函数，则可以在跳转函数内部实现一个白名单，指定跳转地址只能在白名单中；

q  另一种解决方式是控制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返回头中配置实现。

12.5 数据持久层与SQL注入

对于ibaits参数引用可以使用#和$两种写法，其中#写法会采用预编译方式，将转义交给了数据库，不会出现注入问题；如果采用$写法，则相当于拼接字符串，会出现注入问题。

例如，如果属性值为“‘ or‘1‘=‘1 ”，采用#写法没有问题，采用$写法就会有问题。

q  对于like语句，难免要使用$写法：

q  对于Oracle可以通过‘%‘||‘#param#‘||‘%‘避免；

q  对于MySQL可以通过CONCAT(‘%‘,#param#,‘%‘)避免；

q  MSSQL中通过‘%‘+#param#+‘%。

mysql: select * from t_user where name like concat(‘%‘,#name #,‘%‘)

oracle: select * from t_user where name like ‘%‘||#name #||‘%‘

SQL Server:select * from t_user where name like ‘%‘+#name #+‘%

注：尽量避免使用如下代码：

<![CDATA[
  INSERTINTO `tab_user_one`
values( )                                                                                         
   ]]>

12.6 还能想到什么

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

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

12.7 Web框架自身安全

Web框架本身也可能会出现漏洞，只要是程序，就可能出现bug。但是开发框架由于其本身的特殊性，一般网站出于稳定的考虑不会对这个基础设施频繁升级，因此开发框架的漏洞可能不会得到及时的修补，但由此引发的后果却会很严重。

本文出自 “梦朝思夕” 博客，请务必保留此出处http://qiangmzsx.blog.51cto.com/2052549/1859560

《白帽子讲WEB安全》学习笔记之第12章 WEB框架安全