xss打击是web打击中非每每见的一种打击手段。如果你还没有风闻过xss打击，可以先了解xss的相关常识和道理，例如: XSS)" target="_blank">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.