Loading
0

防范xss攻击的正确姿势

 xss攻击是web攻击中非常常见的一种攻击手段。如果你还没有听说过xss攻击,可以先了解xss的相关知识和原理,例如: XSS)" target="_blank" rel="nofollow,noindex">https://www.owasp.org/index.php/Cross-site_Scripting_(XSS) 。

防范xss攻击的方式也十分简单:转义!

但是转义的时机?是在持久化之前转义呢,还是读数据之后escape呢?

我开始想也没想就选择了第一种方式,因为这种方法看上去一劳永逸,但是我现在越来越倾向于第二种方式。

实际上选择第一种还是第二种需要根据你的实际情况来定。我们知道xss攻击是一种web攻击手段,它的运行环境是在用户的浏览器中,也就是说用户的运行环境是不可控的。那么在持久化之前进行转义看上去似乎不错,因为我们可以利用filter或者interceptor拦截所有的写入请求,统一进行转义。这样一来,我们的业务逻辑就完全不需要care转义的问题了,因为我们取到的数据已经都是转义的过的了。

如果用户的终端是可控的,比如:Native App,那么入库之前进行转义就显得多此一举,因为所有的输出方式都是在我们的App中展现的,自然也就不会出现了xss攻击的问题了。例如用户在评论中输入了<哈哈>,你觉得用户希望输出<哈哈>,还是<哈哈>呢? 结果是显而易见的。

现实的情况往往是复杂的,不会只有黑和白、0与1、native和web,更多的是它们交织在一起,互相入侵对方的领域。基本上现在大部分的App都有分享功能,那么恶意的用户完全可以在评论中插入注入代码,再将该评论分享出去,那么其它被分享的用户就有被攻击的风险。解决的方法就是针对分享的数据进行全局转义,事实上已经很多模版系统已经帮我们考虑了这部分问题,例如Django和Jinja2的模版就是默认开启自动转义的。如果是前后端分离的场景,也可以有前端来进行escape。

我推荐使用“入库不转义读转义”还有一个原因,那就是前期转义格式的不确定性和后期输出的多样性。如果你正在正在开发一个rest服务器,你与App使用json格式通信。为了简单,在开始业务代码前,你对所有输入数据按照html格式进行转义。那么你可以十分放心分享出去的数据是安全的,因为所有的数据在持久化之前就已经转义了,同时你会痛苦unescape给App的数据。如果那天老板要求你以xml的格式输出这些数据(可能是其它系统的输入要求,也可能是打印报表),那么你会更加痛苦。因为xml和html的转义字符还是有些不同的,你不得不先unescape回原始数据然后再按照xml的格式escape一次。如果这样你觉得都还ok,那么我开始有点佩服你了。如果老板还要求你有更多的输出格式,那么你会更加痛苦,这还是在没有考虑输入格式变化的情况下。因为一个转义的问题导致逻辑变得复杂,影响系统的稳定性是得不偿失的。

最后,我来终结一下这两种方式的优缺点:

转义方式 优点 缺点
入库前转义 一劳永逸 需要针对多端进行不同的输出,灵活性不足,无法应对后期数据格式的变化
读取前转义 简单,灵活,能应对各种数据格式的场景 需要对每个输出数据转义,人工处理容易遗漏

本人推荐第二种方式来防范xss攻击。虽然需要对每个输出数据都进行转义,但是如果你使用带自动转义的模版或者框架来处理的话,那么就可以极大的提高效率,又可以规避安全的问题。最后还是要提醒大家,安全无小事,即使你觉得没有人会攻击的系统,还是要规避这些风险,安全是系统的基石。

参考文献:

Why escape-on-input is a bad idea

When do you escape your data?

This article used CC-BY-SA-3.0 license, please follow it.

【声明】:8090安全小组门户(https://www.8090-sec.com)登载此文出于传递更多信息之目的,并不代表本站赞同其观点和对其真实性负责,仅适于网络安全技术爱好者学习研究使用,学习中请遵循国家相关法律法规。如有问题请联系我们,联系邮箱hack@ddos.kim 或 hack@ddos.social,我们会在最短的时间内进行处理。