- XSS
- CSRF
- 点击劫持
- SQL注入
- OS注入
- 请求劫持
- DDOS
https://cloud.tencent.com/developer/article/1621427
前台页面中去绑定了：
然后用户访问根路径：拼上from = 一个script标签中弹出一个1, 敲回车，真的会弹出一个1。
这就是安全隐患，人家都可以在你的网站上运行自己写的JS文件了，当然是安全隐患，比如人家script src引入了一个JS文件，这个JS文件去当做你自己网站的JS。这个引入的JS是获取cookie信息的。那么人家引入后，就可以轻易的拿到你的cookie，那么就相当于拿到了你的登录态了，就可以当成是你了。那么还会造成如下影响：
- 利用虚假输入表单骗取用户个人信息。如：他里面给你引入一段JS，这个JS能渲染出来一个弹出框(appendchild)，然后让你输入你的个人信息。
- 就是通过外引的脚本窃取用户的cookie，在被害者不知情的情况下，帮助攻击发送恶意请求
- 显示伪造的文章或者图片，诱导用户。
具体看一下黑客是如何窃取cookie的：
1.找漏洞：首先如上面的，发现在url输入框中，可以执行script。
2.引入自己的获取cookie的JS文件（用户访问的网站是localhost:3000，黑客的网站服务器是localhost:4000）
黑客的主服务js：拦截监听所有请求，打印出上面img标签的src，这就知道为什么上面用src了吧，就是能发送个请求。这里就是为了能直观的看到输入出来的结果。
多数情况下，会给自己的邮箱发送一封邮件（里面是窃取到的cookie）。
存储型：如下面的直接在input框中注入了js代码，弹出了1。
这个比 反射型更高级，无需把这个代码发布到其他的位置，直接注入到了这个网站的数据库中（因为添加进了input，input中的值会存储到数据库中）那么这个js代码就已经融在了这个网站中，每次一刷新这个网站，就会一直弹出alert(1)。这就叫攻击。
下面说一下防范手段：
1.第一道防线：
ejs模板渲染的时候进行转译：
上面那种之所以能运行js代码，是因为设置为了-，就是不做任何处理，那么势必会运行script中的代码，所以写成=，就会把scipt代码当成html，那么自然就执行不了js
那么一长串，有稍微懂点的人一看url里面有script标签，可能会引起警惕性，这时候黑客可以把他的这个url变更为短网址伪装一下，这样就不被人怀疑了，别人以为这就是一个正常的网站。
场景是这样的：
比如用户A现在正在访问一个网站，并且没有退出登录，这时候你的cookie就存储在浏览器，那么这时候你去别的网站，看到别的网站上有个诱导性的图片或者文字或者网站地址（伪造好的短网址），你点了进去，殊不知这个图片的src地址就是黑客的JS脚本，那么这个脚本就会能拿到你本地的cookie，或者直接跳到一个跟原来你访问网站一毛一样的网站，他上面也有支付什么的，那么就会被骗了，当然黑客拿到你的登录态就可以窃取你的信息了。
2.第二道防线
浏览器自行设置的X-XSS-Protection
这个东西现在高级的浏览器都会自行进行设置。这里后端设置为0，是为了先关掉浏览器设置的这个，为了自己测试用
3.第三道防线：
CSP规则：网络安全策略
CSP本质上就是建立白名单，开发者明确告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截是由浏览器自己实现的，可以通过这种方式减少XSS的攻击。
第四条防线：
自己设置规则进行转译：
返回数据的时候：被转译方法包裹一下
有一种富文本编辑功能对于这种转译是不行的，因为富文本里面也可以输入代码，怎么解决？
我们可以分黑明白和白名单转译：
黑名单转译错杀的太多了
我们用白名单转译：把合法的正常编译，不合法的就是个字符串不会执行、
执行结果：照样渲染了h1标签，script标签原封不动并未执行。
第五道防线
设置cookie的 httpOnly:true，这个意思就是这个cookie只能由我服务端操作，只能是我服务器用的。
可以看到cookie中：HTTP加了个对号
这样前端再次获取cookie，是得到一个空，就是客户端已经拿不到，用不了了。
