本文目录一览：
XSS攻击的定义，类型以及防御方法？
XXS攻击全称跨站脚本攻击，是一种在Web应用中的计算机安全漏洞，它允许恶意Web用户将代码植入到提供给其他使用的页面中。
XSS攻击有哪几种类型?下面就由锐速云的小编为大家介绍一下
经常见到XSS攻击有三种：反射XSS攻击、DOM-based型XSS攻击以及储存型XSS攻击。
[if !supportLists]1、[endif]反射型XSS攻击
反射性XSS一般是攻击者通过特定手法(如电子邮件)，诱使用户去访问一个包含恶意代码的URL，当受害者点击这些专门设计链接的时候，恶意代码会直接在受害主机上的浏览器上执行，反射型XSS通常出现在网站搜索栏，用户登入口等地方，常用来窃取客户端或进行钓鱼欺骗。
[if !supportLists]2、[endif]存储型XSS攻击
存储型XSS攻击也叫持久型XSS，主要将XSS代码提交储存在服务器端(数据库，内存，文件系统等)下次请求目标页面时不用在提交XSS代码。当目标用户访问该页面获取数据时，XSS代码会从服务器解析之后加载出来，返回到浏览器做正常的HTML和JS解析执行，XSS攻击就发生了。储存型XSS一般出现在网站留言，评论，博客日志等交互处，恶意脚本储存到客户端或者服务端的数据库中。
[if !supportLists]3、[endif]DOM-based型XSS攻击
DOM-based型XSS攻击它是基于DOM的XSS攻击是指通过恶意脚本修改页面的DOM结构，是纯粹发生在客户端的攻击。DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞。
如何防御XSS攻击?
[if !supportLists]1、[endif]对输入内容的特定字符进行编码，列如表示html标记等符号。
[if !supportLists]2、[endif]对重要的cookie设置httpOnly，防止客户端通过document。cookie读取cookie，此HTTP开头由服务端设置。
[if !supportLists]3、[endif]将不可信的输出URT参数之前，进行URLEncode操作，而对于从URL参数中获取值一定要进行格式检查
[if !supportLists]4、[endif]不要使用Eval来解析并运行不确定的数据或代码，对于JSON解析请使用JSON。Parse()方法
[if !supportLists]5、[endif]后端接口也应该要做到关键字符过滤的问题。
js eval 这个函数有什么漏洞吗
eval函数接收一个参数s，如果s不是字符串，则直接返回s。否则执行s语句。如果s语句执行结果是一个值，则返回此值，否则返回undefined。
JavaScript中的eval()不安全，可能会被利用做XSS攻击，eval也存在一个安全问题，因为它可以执行传给它的任何字符串，所以永远不要传入字符串或者来历不明和不受信任源的参数。
JavaScript 为什么不推荐使用 eval
1、eval 太神秘了，以至于很多人用错。所以不推荐使用。
2、 eval不容易调试。用chromeDev等调试工具无法打断点调试，所以麻烦的东西也是不推荐使用的…
3、说到性能问题，在旧的浏览器中如果你使用了eval，性能会下降10倍。在现代浏览器中有两种编译模式：fast path和slow path。fast path是编译那些稳定和可预测（stable and predictable）的代码。而明显的，eval不可预测，所以将会使用slow path ，所以会慢。
还有一个是，在使用类似于Closure Compiler等压缩（混淆）代码时，使用eval会报错。
（又慢又报错，我还推荐吗？）
4、关于安全性，我们经常听到eval是魔鬼，他会引起XSS攻击，实际上，如果我们对信息源有足够的把握时，eval并不会引起很大的安全问题。而且不光是eval，其他方式也可能引起安全问题。比如：
莫名其妙给你注入一个script src=""标签，或者一段来历不明的JSON-P请求，再或者就是Ajax请求中的eval代码…
所以啊，只要你的信息源不安全，你的代码就不安全。不单单是因为eval引起的。
你用eval的时候会在意XSS的问题，你越在意就越出问题，出的多了，eval就成噩梦了。
5、效率问题是程序逻辑问题。对于一些有执行字符串代码需求的程序中，不用eval而用其他方式模拟反而会带来更大的开销。
