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