攻击者构造网站后台某个功能接口的请求地址，诱导用户去点击或者用特殊方法让该请求地址自动加载。用户在登录状态下这个请求被服务端接收后会被误以为是用户合法的操作。对于 GET 形式的接口地址可轻易被攻击，对于 POST 形式的接口地址也不是百分百安全，攻击者可诱导用户进入带 Form 表单可用POST方式提交参数的页面。
客户端防范：对于数据库的修改请求，全部使用POST提交，禁止使用GET请求。
服务器端防范：一般的做法是在表单里面添加一段隐藏的唯一的token(请求令牌)。
http://link.zhihu.com/?target=https%3A//account.bilibili.com/login%3Fact%3Dexit
1. 正常用户 A 提交正常内容，显示在另一个用户 B 的网页上，没有问题。
2. 恶意用户 H 提交恶意内容，显示在另一个用户 B 的网页上，对 B 的网页随意篡改。
造成 XSS 有几个要点：
1. 恶意用户可以提交内容
2. 提交的内容可以显示在另一个用户的页面上
3. 这些内容未经过滤，直接运行在另一个用户的页面上
假设我们有一个评论系统。
用户 A 提交评论「小谷你好」到服务器，然后用户 B 来访问网站，看到了 A 的评论「小谷你好」，这里没有 XSS。
恶意用户 H 提交评论「<script>console.log(document.cookie)</script>」，然后用户 B 来访问网站，这段脚本在 B 的浏览器直接执行，恶意用户 H 的脚本就可以任意操作 B 的 cookie，而 B 对此毫无察觉。有了 cookie，恶意用户 H 就可以伪造 B 的登录信息，随意访问 B 的隐私了。而 B 始终被蒙在鼓里。
系统进行简单的转义
<img src="pic.gif" οnerrοr="javascript:this.src='/noPic.gif';" alt="pic">
因为标签失去闭合性，触发onerror事件，执行onerror中的函数，将src
换为自己想要的url
如果没过滤的情况，可以直接吧src设为自己想要的url
参考文章
https://zhuanlan.zhihu.com/p/22521378
https://zhuanlan.zhihu.com/p/22500730
https://blog.csdn.net/tanzhen1991910/article/details/53085274
