第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提交的tokenSession绑定的Tiken是否一致。

q  尽量使用POST

12.4 Http Headers管理

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

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

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

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

q  另一种解决方式是控制HTTPLocation字段,限制Location的值只能是哪些地址,也能起到同样的效果,其本质还是白名单。

 

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

X-Frame-Options: SAMEORIGIN

Web框架可以封装此功能,并提供页面配置。该HTTP头有三个可选的值:SAMEORIGINDENYALLOW-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 #+'%

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

12.6 还能想到什么

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

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

 

12.7 Web框架自身安全

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