Cookie挟持
HTTP是无状态的协议，为了维持和跟踪用户的状态，引入了Cookie和Session。 Cookie包含了浏览器客户端的用户凭证，相对较小。Session则维护在服务器，用于维护相对较大的用户信息。可以把Cookie当成密码，而Session是保险柜。由于HTTP是明文传输，Cookie很容易被盗取，如果被盗取，别人就可以冒充你的身份，打开你的保险柜，获取你的信息，动用你的资金，这是很危险的。
1.危害
盗取cookie信息，冒充他人身份，盗取信息。
2.防御
- 给cookie添加HttpOnly属性，该属性设置后，只能在http请求中传递，在脚本中，document.cookie无法获取到该cookie值，对XSS攻击有防御作用，但对网络拦截还是会泄露。
- 在cookie中添加校验信息，这个校验信息和当前用户外置环境有些关系，比如ip、user agent等有关.这样当cookie被人劫持冒用时，在服务器端校验的时候，发现校验值发生了变化，因此会要求用户重新登录，可以规避cookie劫持。
- cookie中session id的定时更换，让session id按一定频率变换，同时对用户而言，该操作是透明的，这样保证了服务体验的一致性。
XSS攻击
攻击者在web页面恶意插入HTML或script标签，当用户浏览该页面时，恶意代码就会被执行，从而达到攻击的目的。XSS利用的是用户对指定网站的信任。
1.类型
反射型(非持久)：攻击者事先制作好攻击链接,需要欺骗用户自己去点击链接才能触发XSS代码，所谓反射型XSS就是将恶意用户输入的js脚本，反射到浏览器执行。
最经典的存储型XSS漏洞是留言板，当用户A在留言板留言一段JS代码<script>alert("run javascript");</script>,后端未经过滤直接存储到数据库，当正常用户浏览到他的留言后，这段JS代码就会被执行，可以借此来盗取cookie。
- 储存型(持久型)：会把攻击者的数据储存到服务端，攻击行为将伴随攻击数据一直存在，每当用户访问该页面就会触发代码执行。
流程图链接：https://p3-juejin.byteimg.com... - DOM型XSS是：基于DOM文档对象模型的。对于浏览器来说，DOM文档就是一份XML文档，当有了这个标准的技术之后，通过JavaScript就可以轻松的访问DOM。当确认客户端代码中有DOM型XSS漏洞时，诱使(钓鱼)一名用户访问自己构造的URL，利用步骤和反射型很类似，但是唯一的区别就是，构造的URL参数不用发送到服务器端，可以达到绕过WAF、躲避服务端的检测效果。案列：
<html>
<head>
<title>DOM Based XSS Demo</title>
<script>
function xsstest()
{
var str = document.getElementById("input").value;
document.getElementById("output").innerHTML = "<img
src='"+str+"'></img>";
}
</script>
</head>
<body>
<div id="output"></div>
<input type="text" id="input" size=50 value="" />
<input type="button" value="submit" onclick="xsstest()" />
</body>
</html>
在这段代码中，submit按钮的onclick事件调用了xsstest()函数。而在xsstest()中，修改了页面的DOM节点，通过innerHTML把一段用户数据当作HTML写入到页面中，造成了DOM Based XSS。
- 通用型XSS
通用型XSS，也叫做UXSS或者Universal XSS，全称Universal Cross-Site Scripting。
上面三种XSS攻击的是因为客户端或服务端的代码开发不严谨等问题而存在漏洞的目标网站或者应用程序。这些攻击的先决条件是访问页面存在漏洞，但是UXSS是一种利用浏览器或者浏览器扩展漏洞来制造产生XSS的条件并执行代码的一种攻击类型。案列：IE6或火狐浏览器扩展程序Adobe Acrobat的漏洞等 突变型XSS，也叫做mXSS或，全称Mutation-based Cross-Site-Scripting。（mutation，突变，来自遗传学的一个单词，大家都知道的基因突变，gene mutation）
mxss 种类：
1.反引号打破属性边界导致的 mXSS；
（该类型是最早被发现并利用的一类mXSS，于2007年被提出，随后被有效的修复）;
2.未知元素中的xmlns属性所导致的mXSS；（一些浏览器不支持HTML5的标记，例如IE8，
会将article，aside，menu等当作是未知的HTML标签。）
3.CSS中反斜线转义导致的mXSS；
（在CSS中，允许用\来对字符进行转义，例如：property: 'v\61 lue' 表示 property:'value'，其中61是字母a的ascii码（16进制）。
\后也可以接unicode，例如：\20AC 表示 € 。正常情况下，这种转义不会有问题。但是碰上innerHTML后，一些奇妙的事情就会发生。）
4.CSS中双引号实体或转义导致的mXSS；（接着上一部分，依然是CSS中所存在的问题，" " " 等双引号的表示形式均可导致这类问题，）
5.CSS属性名中的转义所导致的mXSS；
6.非HTML文档中的实体突变；
7.HTML文档中的非HTML上下文的实体突变；xss防御
1.预防 DOM 型 XSS 攻击
DOM 型 XSS 攻击，实际上就是网站前端 JavaScript 代码本身不够严谨，把不可信的数据当作代码执行了。
在使用 .innerHTML、.outerHTML、document.write() 时要特别小心，不要把不可信的数据作为 HTML 插到页面上，而应尽量使用 .textContent、.setAttribute() 等。
DOM 中的内联事件监听器，如 location、onclick、onerror、onload、onmouseover 等， 标签的href属性，JavaScript 的eval()、setTimeout()、setInterval()等，都能把字符串作为代码运行。如果不可信的数据拼接到字符串中传递给这些 API，很容易 产生安全隐患，请务必避免。2.输入过滤
如果由前端过滤输入，然后提交到后端的话。一旦攻击者绕过前端过滤，直接构造请求，就可以提交恶意代码了。
那么，换一个过滤时机：后端在写入数据库前，对输入进行过滤，然后把“安全的”内容，返回给前端。这样是否可行呢？ 我们举一个例子，一个正常的用户输入了 5 < 7 这个内容，在写入数据库前，被转义，变成了 5 $lt; 7。 问题是：在提交阶段，我们并不确定内容要输出到哪里。
这里的“并不确定内容要输出到哪里”有两层含义：1.用户的输入内容可能同时提供给前端和客户端，而一旦经过了 escapeHTML()，客户端显示的内容就变成了乱码( 5 $lt;7 )。
在前端中，不同的位置所需的编码也不同。 当 5 $lt;7 作为 HTML 拼接页面时，可以正常显示：5 < 72.所以输入过滤非完全可靠，我们就要通过“防止浏览器执行恶意代码”来防范 XSS，可采用下面的两种方法
3.前端渲染把代码和数据分隔开
在前端渲染中，我们会明确的告诉浏览器：下面要设置的内容是文本（.innerText），还是属性（.setAttribute），还是样式 （.style）等等。浏览器不会被轻易的被欺骗，执行预期外的代码了。
- Javascript：可以使用textContent或者innerText的地方，尽量不使用innerHTML；
jquery：可以使用text()得地方，尽量不使用html()；
4.拼接HTML时对其进行转义
如果拼接 HTML 是必要的，就需要采用合适的转义库，对 HTML 模板各处插入点进行充分的转义。
常用的模板引擎，如 doT.js、ejs、FreeMarker 等，对于 HTML 转义通常只有一个规则，就是把 & < > " ' / 这几个字符转义掉，确 实能起到一定的 XSS 防护作用，但并不完善：
这里推荐一个前端防止XSS攻击的插件: js-xss的使用和源码解读，Git 3.8K 的Star和60W的周下载量证明了其强大性.总结
防范 XSS 是不只是服务端的任务，需要后端和前端共同参与的系统工程。虽然很难通过技术手段完全避免XSS，但我们原则上减少漏洞的产生。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。