XSS防御——从Flask源码看XSS防御

这两天遇到一个项目，老板问我各种安全问题的防护措施，结果我两眼一黑，想想自己以前都是注重攻击而忽视防御，因此开一个专栏来讨论各种web漏洞的防护方法，先从最简单的XSS讲起吧：

编写XSS网站

使用Ninja模板的话是没有xss问题的，测试代码如下：

from flask import Flask, request, render_template_string

app = Flask(__name__)

@app.route('/xss', methods=['GET', 'POST'])
def xss():
    template = '''
    

    

    
    
    

    {{ _input }}
    '''
    if request.method == 'GET':
        return render_template_string(template)
    else:
        return render_template_string(template, _input=request.form["input"])


if __name__ == '__main__':
    app.run(host='127.0.0.1', port=8888)

测试以及结果解释

访问localhost:8888 提交可以看到没有发现问题

xss_notwork.png

那么render究竟做了什么事情呢？可以抓包看一下服务器返回的原始HTTP：

1544259433807.png

可以看到，flask在返回时，对我们的字符串进行了转义。

深入源码

那么我们再看一下源代码，是否像我们猜想的那样使用转义的方法来防御xss的呢？

render_template_string方法是flask渲染template的入口：

1543844859434.png

再跟进去，看到_render(template, context, app)方法：

1543845055451.png

再跟进去，看到template.render方法，template.render中的root_render_func是一系列动态函数，我们就没办法跟进去了，但是可以看到在这个函数执行后敏感字符已经被转义。

1544269415270.png

​ 搜索资料才发现真正的转义代码存在于jinja的safe过滤器，jinja是flask所采用的模板渲染引擎，我们使用模板渲染时，{{ xxx }}中的xxx可以被jinja各种过滤器处理，当然我们也可以自定义过滤器，但是在默认情况下，jinja会使用safe过滤器对xxx进行处理，目的就是转义敏感字符来防止xss的问题。

​ 在https://github.com/pallets/jinja/blob/master/jinja2/filters.py中看到do_mark_safe()函数，其直接调用了jinja2.utils.Markup()函数：

1544269550778.png

​ 在https://github.com/pallets/jinja/blob/master/jinja2/utils.py中找到Markup()函数，实际上，此函数是从markupsafe库导入的，也就是说jinja2库依赖于markupsafe库：

1544269744908.png

​ 在https://github.com/pallets/markupsafe/tree/master/src/markupsafe找到markup的源代码，可以看到其中有两个版本，一个是python写的，一个是c写的，很明显是为了提升效率：

1544270039415.png

​ 在https://github.com/pallets/markupsafe/blob/master/src/markupsafe/_native.py的escape函数中，可以看到具体的转义方法：

1543847597871.png

总结

就如我们最后一步看到的，XSS的防护需要对用户可操纵的数据进行HTML转义，之后再呈现给用户，具体来说，转移规则如下

• < 转成 <
• > 转成 >
• & 转成 &
• " 转成 "
• ' 转成 '
  当然，如果用户可操纵的内容是html的标签属性，那么还要进行关键词的黑名单/白名单的过滤。