我要投搞

标签云

收藏小站

爱尚经典语录、名言、句子、散文、日志、唯美图片

当前位置:2019斗牛棋牌 > 防御能力 >

防范xss的正确姿势

归档日期:07-06       文本归类:防御能力      文章编辑:爱尚语录

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

  实际上选择第一种还是第二种需要根据你的实际情况来定。我们知道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攻击。虽然需要对每个输出数据都进行转义,但是如果你使用带自动转义的模版或者框架来处理的话,那么就可以极大的提高效率,又可以规避安全的问题。最后还是要提醒大家,安全无小事,即使你觉得没有人会攻击的系统,还是要规避这些风险,安全是系统的基石。

本文链接:http://xiahxiu.net/fangyunenli/196.html