防范xss的正确姿式

防范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与一、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.