3、XSS防御：反射型XSS、存储型XSS、DOM型XSS、Python模板引擎自动转义机制

聊到Web安全，XSS（跨站脚本攻击）绝对是个绕不开的话题。我最早接触这个漏洞，是在一个内部管理系统里。用户提交了一段看似无害的评论，结果整个后台管理页面弹出了奇怪的弹窗。嗯，那会儿我才真正意识到——用户输入，永远不能信任。

XSS说白了，就是攻击者把恶意脚本塞进了你的页面里。浏览器傻傻地执行了，于是Cookie被偷、页面被篡改、甚至用户被钓鱼。今天咱们就把三种XSS类型掰开揉碎讲清楚，再聊聊Python模板引擎怎么帮我们挡掉大部分攻击。

反射型XSS：最直接的攻击方式

反射型XSS，也叫非持久型XSS。攻击者把恶意脚本放在URL参数里，诱导用户点击。服务器拿到参数后，直接拼到HTML里返回。浏览器一渲染，脚本就执行了。

举个例子，你有个搜索页面：

# 不安全的写法
@app.route('/search')
def search():
    query = request.args.get('q', '')
    return f'<h1>搜索结果: {query}</h1>'

攻击者构造这样的链接：

/search?q=<script>alert('XSS')</script>

用户一点，脚本就跑了。为什么会这样？因为服务器直接把用户输入塞进了HTML上下文，没有做任何转义。

注意：反射型XSS虽然不持久，但配合钓鱼邮件、短链接，杀伤力一点不小。我见过一个案例，攻击者通过反射型XSS窃取了管理员的Session，直接拿到了后台权限。

存储型XSS：最危险的定时炸弹

存储型XSS，恶意脚本被永久保存在服务器上。比如评论区、用户资料、博客文章。每个访问该页面的用户，都会中招。

我曾经在一个论坛项目里遇到过。用户提交评论时，后端直接存了原始HTML：

# 不安全的存储
comment = request.form['content']
db.execute('INSERT INTO comments (content) VALUES (?)', (comment,))

然后在展示页面：

# 直接渲染
@app.route('/comments')
def show_comments():
    comments = db.query('SELECT content FROM comments')
    html = ''.join([f'<div>{c}</div>' for c in comments])
    return html

攻击者提交一条包含 <script>stealCookie()</script> 的评论。之后每个访问评论页的用户，Cookie都被偷了。这就是存储型XSS的可怕之处——一次注入，持续伤害。

核心区别：反射型XSS需要用户点击恶意链接，存储型XSS只要用户访问正常页面就会触发。后者危害更大，也更难清理。

DOM型XSS：前端自己的锅

DOM型XSS跟前端关系更大。恶意脚本不经过服务器，完全在浏览器端通过DOM操作执行。攻击者利用 innerHTML、document.write、eval 等API，把用户可控的数据写进页面。

看个典型例子：

// 不安全的DOM操作
var name = new URLSearchParams(window.location.search).get('name');
document.getElementById('greeting').innerHTML = '你好, ' + name;

攻击者构造URL：

/page.html?name=<img src=x onerror=alert(1)>

浏览器解析时，innerHTML 直接插入了HTML标签，onerror 事件触发，脚本执行。整个过程服务器完全不知情。

我个人习惯，在前端处理用户输入时，优先用 textContent 而不是 innerHTML。如果必须用HTML，那就用 DOMPurify 做一次清洗。

避坑指南：我曾经在重构一个老项目时，发现前端大量使用 innerHTML 拼接用户数据。改起来确实麻烦，但这是必须做的。建议团队在代码规范里直接禁止 innerHTML 用于用户输入。

Python模板引擎自动转义机制

好了，聊完三种XSS，咱们看看Python这边怎么防。好消息是，主流模板引擎默认就带自动转义。你想想看，Django的模板、Flask的Jinja2、还有Mako，都默认帮你转义了。

以Jinja2为例：

from flask import Flask, render_template_string

app = Flask(__name__)

@app.route('/user/<name>')
def user(name):
    # Jinja2 默认转义 {{ name }}
    template = '<h1>Hello, {{ name }}!</h1>'
    return render_template_string(template, name=name)

如果 name 是 <script>alert(1)</script>，Jinja2会自动转义成：

&lt;script&gt;alert(1)&lt;/script&gt;

浏览器显示的是纯文本，不会执行脚本。这就是自动转义的作用。

但要注意，自动转义不是万能的。有些场景下，你需要关闭转义，比如渲染富文本内容。这时候就要格外小心。

警告：Jinja2中，使用 |safe 过滤器或 {% autoescape false %} 会关闭转义。只有在你完全信任输入内容时才能用。我建议，即使关闭转义，也要先用 bleach 库做一次白名单过滤。

看看Django模板的自动转义：

# Django 默认也是转义的
from django.shortcuts import render

def user_view(request, name):
    return render(request, 'user.html', {'name': name})

模板文件 user.html：

<h1>Hello, {{ name }}</h1>

Django同样会把 name 中的特殊字符转义。如果你需要输出原始HTML，用 {% autoescape off %} 或 {{ name|safe }}。但记住，安全第一。

总结一下防御要点

XSS类型 攻击方式 防御重点
反射型XSS URL参数注入 输出转义、输入验证
存储型XSS 数据库持久化 存储前转义、输出转义
DOM型XSS 前端DOM操作 避免innerHTML、使用textContent

最后说一句，模板引擎的自动转义是你的第一道防线，但不是唯一防线。我建议你养成几个习惯：

  • 所有用户输入，默认不信任
  • 输出到HTML时，确保转义
  • 前端避免直接操作 innerHTML
  • 使用CSP（内容安全策略）作为第二道防线

嗯，XSS这块内容不少，但核心就一句话：输入过滤，输出转义，前后端一起防。下一章咱们聊聊CSRF，那个也很有意思。

← 上一章 📖 返回目录 下一章 →