对cookie真得了解么？总是有点模糊，通过参考大量资料，做了一个整理，由于资料查阅太多，都记不得源引用了，如有侵权，请谅解，都是为了学习，哈哈！
什么是cookie
Cookie是保存在客户端的纯文本文件，一般来说cookie都是服务器端写入客户端的纯文本文件。Cookie 文件必须由浏览器的支持，在浏览器中可以设置阻止cookie。这样服务器端就不能写入cookie 到客户端了。目前，大多数浏览器都支持cookie。如谷歌、IE、火狐等。一般来说cookie都不能阻止，因为，有时访问网站时必须使用cookie。否则网站将不能被访问。
cookie的应用
举个例子，比如我们到网站上买东西，我打开买鞋的网页，这时候我发了请求，告诉服务器，你给我返回一些鞋的信息和列表，这时候客户端和服务器端的连接就断开了。用户再次去访问，将某双鞋加入到了购物车后连接又断开了。这时用户又想买条裤子，用户将裤子也加入了购物车，此时连接又断开了。到这时，用户又再次发请求说，我要结账了，然后用户打开一个新的结账界面，现在问题来了，这个用户刚刚加入的购物车的东西服务器是怎么知道的呢？服务器是怎么知道是这个用户买的东西呢？那么现在就用到了cookie 了。在seesion出现之前，一般网站都是通过cookie保存请求的内容，服务器根据用户进行特定的内容展示。也就是说如果不使用cookie，我们将不能在浏览器中看到购物车的东西这就类似于浏览器的收藏夹，如果我们收藏了，下次我们再打开浏览器窗口就会看到我们收藏的东西。也就是说cookie保存了一个前后的状态，如果不用cookie我就不知道我是否已经加入购物车了。
为什么用cookie
标准的http协议是无状态的，无连接的. 标准的http协议指的是不包括cookies, session，token的http协议，他们都不属于标准协议.
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接.
什么是无状态呢，即服务器无法判断用户身份.
- 协议对于事务处理没有记忆能力
- 对同一个url请求没有上下文关系
- 每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况
- 服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器
Cookie的组成
Cookie是一段不超过4KB的小型文本数据，由一个名称（Name）、一个值（Value）和其它几个用于控制Cookie有效期、安全性、使用范围的可选属性组成。
(1)Name/Value：设置Cookie的名称及相对应的值，对于认证Cookie，Value值包括Web服务器所提供的访问令牌 。
(2)Expires属性：设置Cookie的生存期。
有两种存储类型的Cookie：会话性与持久性。Expires属性缺省时，为会话性Cookie，仅保存在客户端内存中，并在用户关闭浏览器时失效；持久性Cookie会保存在用户的硬盘中，直至生存期到或用户直接在网页中单击“注销”等按钮结束会话时才会失效 。只要cookie不失效，那么访问此网站时，浏览器就会找对应的webapplication的cookies（自己写入的）。
(3)Path属性：定义了Web站点上可以访问该Cookie的目录 。
(4)Domain属性：指定了可以访问该 Cookie 的 Web 站点或域。Cookie 机制并未遵循严格的同源策略，允许一个子域只可以设置或获取其父域的 Cookie，不能跨域。当需要实现单点登录方案时，Cookie 的上述特性非常有用，然而也增加了 Cookie受攻击的危险，比如攻击者可以借此发动会话定置攻击。因而，浏览器禁止在 Domain 属性中设置.org、.com 等通用顶级域名、以及在国家及地区顶级域下注册的二级域名，以减小攻击发生的范围。
浏览器的同源定义：
如果两个 URL 的 protocol、port (如果有指定的话)和 host 都相同的话，则这两个 URL 是同源。
下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:
| URL | 结果 | 原因 |
|---|---|---|
| http://store.company.com/dir2/other.html | 同源 | 只有路径不同 |
| http://store.company.com/dir/inner/another.html | 同源 | 只有路径不同 |
| https://store.company.com/secure.html | 失败 | 协议不同 |
| http://store.company.com:81/dir/etc.html | 失败 | 端口不同 ( http:// 默认端口是80) |
| http://news.company.com/dir/other.html | 失败 | 主机不同 |
(5)Secure属性：指定是否使用HTTPS安全协议发送Cookie。使用HTTPS安全协议，可以保护Cookie在浏览器和Web服务器间的传输过程中不被窃取和篡改。该方法也可用于Web站点的身份鉴别，即在HTTPS的连接建立阶段，浏览器会检查Web网站的SSL证书的有效性。但是基于兼容性的原因（比如有些网站使用自签署的证书）在检测到SSL证书无效时，浏览器并不会立即终止用户的连接请求，而是显示安全风险信息，用户仍可以选择继续访问该站点。由于许多用户缺乏安全意识，因而仍可能连接到Pharming网址嫁接攻击所伪造的网站 。
(6)HTTPOnly 属性 ：用于防止客户端脚本通过document.cookie属性访问Cookie，有助于保护Cookie不被跨站脚本攻击窃取或篡改。但是，HTTPOnly的应用仍存在局限性，一些浏览器可以阻止客户端脚本对Cookie的读操作，但允许写操作；此外大多数浏览器仍允许通过XMLHTTP对象读取HTTP响应中的Set-Cookie头 。
认证机制
在 Web认证中 ,因为HTTP协议本身的局限，必须采用其他技术将相关认证标记以某种方式持续传送，以免客户从一个页面跳转至另一个页面时重新输入认证信息 。基于Cookie的认证过程，主要由以下三个阶段组成：
（1）发布Cookie。当用户试图访问某Web站点中需要认证的资源时，Web服务器会检查用户是否提供了认证Cookie，如果没有，则将用户重定向到登录页面。在用户成功登录后，Web服务器会产生认证Cookie，并通过HTTP响应中的Set-Cookie头发送给客户端，用于对用户随后的请求进行检查和验证，接着将用户重定向到初始请求的资源 。
（2）检索Cookie。在用户随后的访问请求中，客户端浏览器检索Path和Domain等属性与用户请求资源相匹配的Cookie，并将找到的Cookie通过HTTP请求中的Cookie头提交给Web服务器 。
（3）验证Cookie，Web服务器提取客户端浏览器递交的Cookie，验证其中的访问令牌。若合法，则将访问请求的资源发送给客户端浏览器；反之则拒绝用户的访问请求。Cookie 认证技术简化了用户访问 Web 网站资源的过程，即用户只需在初次登录网站时输入身份信息进行认证，随后便可以访问被授权的所有站点资源，不再需要重复手工提交身份信息。
CSRF攻击
CSRF(cross-site request forgery),中文名：跨站请求伪造，也被称为：one click attack/session riding(很形象), 缩写为 CSRF/XSRF，就是你点击一个什么按钮，会触发一定的程序攻击。CSRF可以理解为，在你不知情的情况下，攻击者盗用你的身份，恶意的像服务器发送请求。
从图中我们可以看出，一个CSRF攻击需要2个条件
- 登录了一个受信任的网站A，并且本地存放了cookie
- 在不关闭A的情况下，访问了危险网站B
CSRF防御
服务端的CSRF方式方法很多样，但总的思想都是一致的，就是在客户端页面增加伪随机数并存储，服务端收到请求判断这个随机数是否存在，如果不存在，则是恶意网站的请求，直接忽略。
验证 HTTP Referer 字段，通过请求头中的referer字段判断请求的来源
在请求地址中添加 token 并验证
XSS攻击
XSS(cross site scripting)跨网页脚本攻击，是以前常见的一种攻击方式，恶意攻击者往Web页面里插入恶意的Script代码，当用户浏览该页之时，嵌入其中Web里面的Script代码会被执行，从而达到恶意攻击用户的目的。
XSS 攻击可以分为3类：存储型（持久型）、反射型（非持久型）、DOM 型。
| 类型 | 存储区（恶意代码存放的位置） | 插入点（由谁取得恶意代码，并插入到网页上） |
|---|---|---|
| 存储型 XSS | 后端数据库 | HTML |
| 反射型 XSS | URL | HTML |
| DOM型 XSS | 后端数据库/前端存储/URL | 前端JavaScript |
存储型 XSS
危害性最大！通常表现为：注入型脚本存储在目标服务器上（如数据库、日志及评论区等）。当浏览器请求数据时，脚本从服务器上传回并执行。这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
反射型 XSS
当用户点击一个恶意链接，或者提交一个表单，或者进入一个恶意网站时，注入脚本进入被攻击者的网站。Web服务器将注入脚本，比如一个错误信息，搜索结果等返回到用户的浏览器上。由于浏览器认为这个响应来自"可信任"的服务器，所以会执行这段脚本。
反射型XSS和存储型XSS的区别在于恶意代码的存储位置：存储型XSS的恶意代码存放在数据库里，反射型XSS的恶意代码存在URL里。反射型XSS漏洞常见于通过URL传递参数的功能，如网站搜索、跳转等。由于需要用户点击恶意链接才能生效，攻击者往往会结合多种手段诱惑用户点击。POST的内容也会触发反射型XSS，只是触发条件比较苛刻（需要构造表单提交页面，并引导用户点击），故非常少见。
DOM 型 XSS
通过修改原始的客户端代码，受害者浏览器的 DOM 环境改变，导致有效载荷的执行。也就是说，页面本身并没有变化，但由于DOM环境被恶意修改，有客户端代码被包含进了页面，并且意外执行。DOM型XSS和前两种的区别在于：DOM型XSS攻击中，取出和执行恶意代码由浏览器端完成，属于前端JavaScript自身的安全漏洞，另外两种都属于服务器端的安全漏洞。
主要是通过这几个步骤来实现：
攻击者通过页面恶意的编写一下脚本语言， 然后发送给服务器
服务器接收到攻击者发送的请求，但是没有处理。直接保存在数据库中。
当用户访问同一个网站的时候，由于服务器并没有处理攻击者发送的恶意脚步，所有会把恶意代码和原始代码都发送给用户，这样攻击者的代码就成功的显示在用户的页面上面了。
防御
请记住一句：不要相信用户的输入。
XSS防御的总体思路是：对输入(和URL参数)进行过滤，对输出进行转义。