《白帽子讲Web安全》3-4章

gjhaoiaao

已于 2024-09-02 17:26:50 修改

阅读量777

点赞数 7

文章标签： web安全安全笔记

于 2024-08-30 09:04:49 首次发布

本文链接：https://blog.csdn.net/qq_42780280/article/details/141703302

版权

《白帽子讲Web安全》3-4章

3、跨站脚本攻击（XSS）

3.1、XSS简介

跨站脚本攻击，英文全称是Cross Site Script，本来缩写是CSS，但是为了和层叠样式表（Cascading Style Sheet, CSS）有所区别，所以在安全领域叫“XSS”。
“XSS根据效果的不同可以分成如下几类。
第一种类型：反射型XSS
反射型XSS只是简单地把用户输入的数据“反射”给浏览器。也就是说，黑客往往需要诱使用户“点击”一个恶意链接，才能攻击成功。反射型XSS也叫做“非持久型XSS”（Non-persistent XSS）。
第二种类型：存储型XSS
存储型XSS会把用户输入的数据“存储”在服务器端。这种XSS具有很强的稳定性。
比较常见的一个场景就是，黑客写下一篇包含有恶意JavaScript代码的博客文章，文章发表后，所有访问该博客文章的用户，都会在他们的浏览器中执行这段恶意的JavaScript代码。黑客把恶意的脚本保存到服务器端，所以这种XSS攻击就叫做“存储型XSS”。
存储型XSS通常也叫做“持久型XSS”(Persistent XSS)，因为从效果上来说，它存在的时间是比较长的。
第三种类型：DOM Based XSS
实际上，这种类型的XSS并非按照“数据是否保存在服务器端”来划分，DOM Based XSS从效果上来说也是反射型XSS。单独划分出来，是因为DOM Based XSS的形成原因比较特别，发现它的安全专家专门提出了这种类型的XSS。出于历史原因，也就把它单独作为一个分类了。
通过修改页面的DOM节点形成的XSS，称之为DOM Based XSS。

在 HTML 文档中，DOM（文档对象模型）将整个页面表示为一个树形结构，其中每个节点代表文档中的一个元素、属性、文本等。这些节点构成了DOM 树，也称为节点树，DOM 节点构成了页面的结构，让我们能够动态地访问和更新文档的内容、结构和样式，其关系为：

文档节点（Document Node）：整个 HTML 文档是一个文档节点，它是 DOM 树的根节点。
元素节点（Element Node）：每个 HTML 元素都是一个元素节点。例如，<div>、<p>、<h1> 等标签都是元素节点。
文本节点（Text Node）：HTML 元素内的文本内容是文本节点。例如，<p>Hello world!</p> 中的 “Hello world!” 是一个文本节点。
属性节点（Attribute Node）：每个 HTML 属性也是一个节点。例如，<img src="image.jpg" alt="My Image"> 中的 src 和 alt 属性都是属性节点。
注释节点（Comment Node）：HTML 中的注释也是节点。例如，<!-- This is a comment --> 是一个注释节点。

节点之间的关系如下：
父节点拥有子节点。例如，<html> 是整个文档的父节点，它拥有 <head> 和 <body> 两个子节点。
同级的子节点被称为同胞（兄弟或姐妹）。例如，<h1> 和 <p> 是 <body> 的同胞节点。
每个节点都有父节点，除了根节点（它没有父节点）。

3.2、XSS攻击进阶

3.2.1、初探XSS Payload

XSS攻击成功后，攻击者能够对用户当前浏览的页面植入恶意脚本，通过恶意脚本, 控制用户的浏览器。这些用以完成各种具体功能的恶意脚本，被称为“XSS Payload”。

3.2.2、强大的XSS Payload

3.2.2.1、构造GET与POST请求

一个网站的应用，只需要接受HTTP协议中的GET 或 POST请求，即可完成所有操作。对于攻击者来说，仅通过JavaScript，就可以让浏览器发起这两种请求。
假设Sohu博客所在域的某页面存在XSS漏洞，那么通过JavaScript，这个过程如下。正常删除该文章的链接是:

http://blog.sohu.com/manage/entry.do?m=delete&id=156713012

对于攻击者来说，只需要知道文章的id，就能够通过这个请求删除这篇文章了。

再看一个复杂点的例子。如果网站应用者接受POST请求,那么攻击者如何实施XSS攻击呢?
下例是Douban的一处表单。攻击者将通过JavaScript发出一个POST 请求，提交此表单，最终发出一条新的消息。
在正常情况下，发出一条消息，浏览器发的包是:

要模拟这一过程，有两种方法。
第一种方法是，构造一个form表单，然后自动提交这个表单。
如果表单的参数很多的话，通过构造DOM节点的方式，代码将会非常冗长。所以可以直接写HTML代码，这样会使得整个代码精简很多。
第二种方法是，通过XMLHttpRequest发送一个POST请求。

所以XSS攻击后，攻击者除了可以实施“Cookie劫持”外，还能够通过模拟GET、POST请求操作用户的浏览器。这在某些隔离环境中会非常有用，比如“Cookie劫持”失效时，或者目标用户的网络不能访问互联网等情况。

3.2.2.2、XSS钓鱼

反射型XSS属于XSS钓鱼吗？
—XSS 反射是一种直接利用用户输入的攻击方式，而 XSS 钓鱼则是通过欺骗用户来达到攻击目的。

XSS 反射：
- 定义：XSS 反射是一种攻击，攻击者通过在 URL 参数、表单字段或其他用户可控的输入中插入恶意脚本，使用户在访问特定页面时执行这些脚本。
- 原理：攻击者构造一个恶意 URL，将脚本作为参数传递给目标网站。当用户点击或访问该 URL 时，网站会将脚本从 URL 中提取并执行，导致攻击成功。
- 示例：以下是一个简单的 XSS 反射示例，如果用户访问这个 URL，就会触发弹出一个警告框：
```
https://example.com/search?query=<script>alert('XSS!')</script>
```
XSS 钓鱼：
- 定义：XSS 钓鱼是一种利用 XSS 漏洞来欺骗用户的攻击方式。攻击者通过伪装成受信任的网站或服务，诱使用户点击恶意链接或执行恶意操作。
- 原理：攻击者创建一个看似合法的页面，其中包含恶意脚本。然后，他们通过社交工程、电子邮件或其他方式将这个页面链接发送给用户。用户点击链接后，脚本会执行，可能导致信息泄露、账户被接管等问题。
- 示例：攻击者可以伪装成银行网站，诱使用户输入敏感信息（如密码）。

3.2.2.3、识别用户浏览器

由于浏览器之间的实现存在差异——不同的浏览器会各自实现一些独特的功能，而同一个浏览器的不同版本之间也可能会有细微差别。所以通过分辨这些浏览器之间的差异，就能准确地判断出浏览器版本，而几乎不会误报。这种方法比读取UserAgent要准确得多。

//代码为文字识别后手动纠正可能和作者的原代码有差别
if (window .ActivexObject)1// MSTE 6.0 or below
//判断是否是IE7以上
if (document.documentElement && typeof document.documentElement.style.maxHeight!=undefined"){
	//判断是否是工E8+
	if (typeof document.adoptNode != "undefined"){// Safari3 & FF & Opera & Chrome & IE8
		//MSIE 8.0因为同时满足前两个if判断，所以//在这里是IE 8
	}
	//MSIE7.0  否则就是IE7
}
		return "msie";
else if (typeof window.opera != "undefined"){//Opera独占
//"Opera "+window.opera.version()
return "opera";
}
else if (typeof window.netscape != "undefined"){//Mozilla独占
//"Mozilla"
/可以准确识别大版本
if(typeof window.Iterator != "undefined"){
	//Firefox 2以上支持这个对象
	if (typeof document.styleSheetSets != "undefined"){// Firefox 3 & Opera 9
		//Firefox 3同时满足这些条件的必然是Firefox 3了
return "mozilla”;
}
else if (typeof window.pageXOffset != "undefined"){ // Nozilla& Safari
	//"Safari"
	try{
	if (typeof external.AddSearchProvider != "undefined") { // Firefox & Google Chrome
		//Google Chrome
		return "chrome" ;
		}
	}catch (e){
		return "safari";
	}
}
else{//unknown
	//Unknown
	return "unknown";
}

安全研究者Gareth Heyes曾经找到一种更巧妙的方法，通过很精简的代码，即可识别出不同的浏览器。

//Firefox detector 2/3 by DoctorDan
FF=/a/[-1]=='a'
//Firefox 3 by me:-
FF3=(function x(){})[-5]=='x'
//Firefox 2 by me:-
FF2=(function x(){})[-6]=='x'
//IE detector I posted previously
IE='\v'=='v'
//Safari detector by me
Saf=/a/.__proto__=='//'
//Chrome by me
Chr=/source/.test((/a/.toString+''))
//Opera by me
Op=/^function \(/.test([].sort)
//IE6 detector using conditionals 
try {IE6=@cc_on @_jscript_version <= 5.7&&@_jscript_build<10000

精简为一行代码，即：

B=(function x(){})[-5]=='x'?'FF3':(function x(){})[-6]=='x'?'FF2':/a/[-1]=='a'?'FF':'\v'=='v'?'IE':/a/.__proto__=='//'?'Saf':/s/.test(/a/.toString)?'Chr':/^function \(/.test([].sort)?'Op':'Unknown'

3.2.2.4、识别用户安装的软件

在XSS Payload中使用时，可以在Flash的ActionScript中读取system.capabilities对象后，将结果通过ExtenalInterface传给页面的JavaScript。这个过程在此不再赘述了。

该过程如下：

Flash 和 JavaScript 之间的通信：
- Flash 可以通过 ExternalInterface 类与嵌入它的 HTML 页面中的 JavaScript 进行通信。
- ExternalInterface 允许 Flash 应用程序调用 JavaScript 函数，也允许 JavaScript 调用 Flash 应用程序中的函数。
system.capabilities 对象：
- system.capabilities 是 Flash 中的一个对象，用于提供关于用户系统和浏览器的信息。
- 通过读取 system.capabilities，我们可以获取有关浏览器、操作系统、屏幕分辨率、Flash 版本等方面的信息。

XSS Payload 示例：

假设有一个 Flash 文件（SWF），其中包含以下 ActionScript 代码：

import flash.external.ExternalInterface;

// 获取系统和浏览器信息
var capabilities:Object = System.capabilities;
var browserInfo:String = capabilities.version + " " + capabilities.os;

// 将信息传递给 JavaScript
ExternalInterface.call("receiveBrowserInfo", browserInfo);

在 HTML 页面中，需要有一个 JavaScript 函数来接收 Flash 传递的信息：

function receiveBrowserInfo(info) {
    console.log("Received browser info from Flash: " + info);
    // 在这里执行其他操作，比如记录日志或更新页面内容
}

当 Flash 文件加载并执行时，它会调用 receiveBrowserInfo 函数，并将浏览器信息作为参数传递给 JavaScript。

3.2.2.5、CSS History Hack

我们再看看另外一个有趣的XSS Payload—通过CSS，来发现一个用户曾经访问过的网站。
这个技巧最早被Jeremiah Grossman发现，其原理是利用style的visited属性—如果用户曾经访问过某个链接，那么这个链接的颜色会变得与众不同。

3.2.2.6、获取用户的真实IP

JavaScript本身并没有提供获取本地IP地址的能力，有没有其他办法？一般来说，XSS攻击需要借助第三方软件来完成。比如，客户端安装了Java环境（JRE），那么XSS就可以通过调用Java Applet的接口获取客户端的本地IP地址。

3.2.3、XSS攻击平台

Attack API
Attack API是安全研究者pdp所主导的一个项目，它总结了很多能够直接使用XSS Payload，归纳为API的方式。比如上节提到的“获取客户端本地信息的API”就出自这个项目。
BeEF
BeEF曾经是最好的XSS演示平台。不同于Attack API，BeEF所演示的是一个完整的XSS攻击过程。BeEF有一个控制后台，攻击者可以在后台控制前端的一切。
XSS-Proxy
XSS-Proxy是一个轻量级的XSS攻击平台，通过嵌套iframe的方式可以实时地远程控制被XSS攻击的浏览器。

3.2.4、终极武器：XSS Worm

3.2.4.1、Samy Worm

Samy蠕虫的技术细节分析
一般来说，用户之间发生交互行为的页面，如果存在存储型XSS，则比较容易发起XSS Worm攻击。
比如，发送站内信、用户留言等页面，都是XSS Worm的高发区，需要重点关注。而相对的，如果一个页面只能由用户个人查看，比如“用户个人资料设置”页面，因为缺乏用户之间互动的功能，所以即使存在XSS，也不能被用于XSS Worm的传播。

3.2.4.2、百度空间蠕虫

3.2.5、调试JavaScript

Firebug是JavaScript调试的第一利器。如果要说缺点，那就是除了Firefox外，对其他浏览器的支持并不好。
在需要调试IE而又没有其他可用的JavaScript Debugger时，IE 8 Developer Tools是个不错的选择。
Fiddler是一个本地代理服务器，需要将浏览器设置为使用本地代理服务器上网才可使用。Fiddler会监控所有的浏览器请求，并有能力在浏览器请求中插入数据。
HttpWatch也能够监控所有的浏览器请求，在目标网站是HTTPS时会特别有用。但HttpWatch并不能调试JavaScript，它仅仅是一个专业的针对Web的“Sniffer”。

3.2.6、XSS构造技巧

3.2.6.1、利用字符编码

3.2.6.2、绕过长度限制

利用事件（Event）来缩短所需字节数，onclick、onfocus、onblur等。不足是能够缩短的字节数是有限的。
将XSS Payload写到别处，再通过简短的代码加载这段XSS Payload。最常用的一个“藏代码”的地方，就是“location.hash”。而且根据HTTP协议，location.hash的内容不会在HTTP包中发送，所以服务器端的Web日志中并不会记录下location.hash里的内容，从而也更好地隐藏了黑客真实的意图。因为location.hash的第一个字符是#，所以必须去除第一个字符才行。location.hash本身没有长度限制，但是浏览器的地址栏是有长度限制的，不过这个长度已经足够写很长的XSS Payload了。要是地址栏的长度也不够用，还可以再使用加载远程JS的方法，来写更多的代码。
在某些环境下，可以利用注释符绕过长度限制。比如我们能控制两个文本框，第二个文本框允许写入更多的字节。此时可以利用HTML的“注释符号”，把两个文本框之间的HTML代码全部注释掉，从而“打通”两个<input>标签。

3.2.6.3、使用`<base>`标签

<base>标签并不常用，它的作用是定义页面上的所有使用“相对路径”标签的hosting地址。
需要特别注意的是，在有的技术文档中，提到<base>标签只能用于<head>标签之内，其实这是不对的。<base>标签可以出现在页面的任何地方，并作用于位于该标签之后的所有标签。

3.2.6.4、window.name的妙用

window.name对象是一个很神奇的东西。对当前窗口的window.name对象赋值，没有特殊字符的限制。因为window对象是浏览器的窗体，而并非document对象，因此很多时候window对象不受同源策略的限制。攻击者利用这个对象，可以实现跨域、跨页面传递数据。在某些环境下，这种特性将变得非常有用。

跟着书中的教程试了一下，在一个初始网站上给window.name赋值，然后在初始网站下用了window.location或location.href跳转到目标网站，此时的window.name还是初始网站上所赋的值。因此可以实现缩短XSS Payload长度的作用。

3.2.7、变废为宝：Mission Impossible

3.2.7.1、Apache Expect Header XSS

Apache的漏洞允许攻击者通过向HTTP头中注入恶意数据，触发未经处理的Expect头中的HTML代码执行。这个漏洞曾被认为是“鸡肋”，但后来安全研究者Amit Klein成功地利用了“使用Flash构造请求”的方法，将其变废为宝。

印证了安全是一个动态的过程

3.2.7.2、Anehta的回旋镖

回旋镖的思路就是：如果在B域上存在一个反射型“XSS_B”，在A域上存在一个存储型“XSS_A”，当用户访问A域上的“XSS_A”时，同时嵌入B域上的“XSS_B”，则可以达到在A域的XSS攻击B域用户的目的。

读的有点吃力了

3.2.8、容易被忽视的角落：Flash XSS

Flash的安全问题也是其被淘汰的原因吧。

3.2.9、真的高枕无忧吗：JavaScript开发框架

使用JavaScript框架并不能让开发者高枕无忧，同样可能存在安全问题。除了需要关注框架本身的安全外，开发者还要提高安全意识，理解并正确地使用开发框架。

3.3、XSS的防御

3.3.1、四两拨千斤：HttpOnly

HttpOnly 属性可以防止 JavaScript 访问 Cookie，降低 XSS 攻击的风险。
如果某个 Cookie 带有 HttpOnly 属性，JavaScript 将无法读取该 Cookie。
用户与服务端的正常交互不受影响，因为 HttpRequest 包中仍然会携带这个 Cookie 信息。

但是，HttpOnly不是万能的，添加了HttpOnly不等于解决了XSS问题。
XSS攻击带来的不光是Cookie劫持问题，还有窃取用户信息、模拟用户身份执行操作等诸多严重的后果。如前文所述，攻击者利用AJAX构造HTTP请求，以用户身份完成的操作，就是在不知道用户Cookie的情况下进行的。
使用HttpOnly有助于缓解XSS攻击，但仍然需要其他能够解决XSS漏洞的方案。

3.3.2、输入检查

输入检查的逻辑，必须放在服务器端代码中实现。如果只是在客户端使用JavaScript进行输入检查，是很容易被攻击者绕过的。目前Web开发的普遍做法，是同时在客户端JavaScript中和服务器端代码中实现相同的输入检查。客户端JavaScript的输入检查，可以阻挡大部分误操作的正常用户，从而节约服务器资源。
XSS Filter在用户提交数据时获取变量，并进行XSS检查；但此时用户数据并没有结合渲染页面的HTML代码，因此XSS
Filter对语境的理解并不完整。 XSS Filter还有一个问题——其对“<”、“>”等字符的处理，可能会改变用户数据的语义。

3.3.3、输出检查

一般来说，除了富文本的输出外，在变量输出到HTML页面时，可以使用编码或转义的方式来防御XSS攻击。

3.3.3.1、安全的编码函数

针对HTML代码的编码方式是HtmlEncode。
在PHP中，有htmlentities()和htmlspecialchars()两个函数可以满足安全要求。
相应地，JavaScript的编码方式可以使用JavascriptEncode（除了数字、字母外的所有字符，都使用十六进制“\xHH”的方式进行编码）。
还有许多用于各种情况的编码函数，比如XMLEncode（其实现与HtmlEncode类似）、JSONEncode（与JavascriptEncode类似）等。

3.3.3.2、只需一种编码吗

3.3.4、正确地防御XSS

想要根治XSS问题，可以列出所有XSS可能发生的场景，再一一解决：

在HTML标签中输出对应的防御方案——HtmlEncode
在HTML属性中输出对应的防御方案——HtmlEncode
在<script>标签中输出对应的防御方案——JavascriptEncode
在CSS中输出对应的防御方案——OWASP ESAPI中的encodeForCSS()函数
在地址中输出——
- 一般来说，在URL的path（路径）或者search（参数）中输出，使用URLEncode即可。
- 如果变量是整个URL，则应该先检查变量是否以“http”开头（如果不是则自动添加），以保证不会出现伪协议类的XSS攻击。在此之后，再对变量进行URLEncode。

伪协议如何导致XSS：一个URL的组成如：[Protocal] [Host] [Path][Search][Hash]其中Protocal处输入伪协议可能导致脚本执行，如“javascript”、“vbscript”以及“dataURI”等伪协议。

3.3.5、处理富文本

在过滤富文本时，“事件”应该被严格禁止，因为“富文本”的展示需求里不应该包括“事件”这种动态效果。
有一些比较成熟的开源项目，实现了对富文本的XSS检查。
Anti-Samy 是OWASP上的一个开源项目，也是目前最好的XSS Filter。最早它是基于Java的，现在已经扩展到.NET等语言。
在PHP中，可以使用另外一个广受好评的开源项目：HTMLPurify。

写文章的MarkDown编辑器同样也属于富文本范畴。

3.3.6、防御DOM Based XSS

DOM Based XSS是从JavaScript中输出数据到HTML页面里。而前文提到的方法都是针对“从服务器应用直接输出到HTML页面”的XSS漏洞，因此并不适用于DOM Based XSS。

书中的例子写到“当document.write输出数据到HTML页面时，浏览器重新渲染了页面”，浏览器会在以下几种情况下重新渲染页面：

DOM结构变化：添加或删除可见的DOM元素，或者元素的内容发生变化导致尺寸变化。
样式属性变更：影响元素几何属性的CSS属性发生变化，例如宽度、高度、外边距、内边距、边框等。
获取布局信息：当JavaScript请求读取依赖于布局信息的样式属性时，如offsetTop、offsetLeft、scrollTop、scrollWidth等。
窗口或设备视口尺寸变化：用户调整浏览器窗口大小时，特别是在响应式设计场景下。

这里当使用document.write将数据输出到HTML页面时，它会直接修改DOM，添加新的内容，从而导致页面的重新渲染。浏览器渲染页面的机制和原理：

当用户在浏览器地址栏输入网址并访问页面时，浏览器经历了以下阶段：

1.HTTP请求阶段：浏览器向服务器发起请求，包括DNS解析、TCP协议的握手和挥手，以及HTTP和HTTPS之间的区别。
2. HTTP响应阶段：服务器返回相应的页面源代码，包括HTTP状态码、304缓存和HTTP报文。
3. 浏览器渲染阶段：浏览器将源代码渲染成可视化页面。这一阶段包括以下步骤：

DOM树渲染：浏览器解析HTML标签，构建DOM树。但仅有DOM树还不能显示页面，需要进一步处理。
CSSDOM树渲染：浏览器解析CSS样式，生成CSSOM（CSS Object Model）。
生成Render Tree（渲染树）：将DOM树和CSSOM结合，生成渲染树。
回流（Layout）：根据渲染树计算元素的确切位置和大小，触发重新布局。
重绘（Painting）：根据渲染树的几何信息，绘制页面内容。
GPU展现：通知GPU按照渲染树逐步绘制页面。

回流一定会触发重绘，但重绘不一定触发回流。优化时要减少DOM的回流和重绘，例如分离读写操作、减少HTTP请求次数和大小等。

从JavaScript输出到HTML页面，也相当于一次XSS输出的过程，需要分语境使用不同的编码函数。
安全研究者Stefano Di Paola设立了一个DOM Based XSS的cheatsheet，有兴趣深入研究的读者可以参考。

3.3.7、换个角度看XSS的风险

一般来说，存储型XSS的风险会高于反射型XSS。因为存储型XSS会保存在服务器上，有可能会跨页面存在。
从攻击过程来说，反射型XSS，一般要求攻击者诱使用户点击一个包含XSS代码的URL链接；而存储型XSS，则只需要让用户查看一个正常的URL链接。
从风险的角度看，用户之间有互动的页面，是可能发起XSS Worm攻击的地方。

3.4、小结

这里想到了之前刷题用到的xss platform。xss platform，提供了注入语句，将语句插入到出现xss的地方，该url就被污染了，然后别人访问该url就会被盗取cookie。

4、跨站点请求伪造（CSRF）

CSRF的全名是Cross Site Request Forgery，翻译成中文就是跨站点请求伪造。

4.1、CSRF简介

4.2、CSRF进阶

4.2.1、浏览器的Cookie策略

HTTP Cookie（也叫 Web Cookie 或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据。浏览器会存储 cookie 并在下次向同一服务器再发起请求时携带并发送到服务器上。两种常见 Cookie 类型：

Session Cookie（临时 Cookie）：
- 这些 Cookie 没有指定过期时间；
- 保存在浏览器进程的内存空间中，当用户关闭浏览器时，Session Cookie 就会失效；
- 通常用于保持用户登录状态，只在用户会话期间有效；
- 例如，登录某个网站后，该网站会使用 Session Cookie 来跟踪你的登录状态。
Third-party Cookie（本地 Cookie）：
- 这些 Cookie 由服务器在设置时指定了过期时间（Expires/Max-age）；
- 只有到了过期时间后，Third-party Cookie 才会失效；
- 保存在本地，不受浏览器关闭的影响；
- 例如，广告商或其他网站可能在你访问某个网站时设置 Third-party Cookie，以便跟踪你的浏览行为。

此外，还有一些其他属性与 Cookie 相关：

Domain（域）：表示当前 Cookie 所属于哪个域或子域下。例如，.baidu.com 表示在 .baidu.com 下可以访问。
Path（路径）：表示 Cookie 的所属路径，一般设为“/”，表示同一个站点的所有页面都可以访问这个 Cookie。
Secure：表示该 Cookie 只能用 HTTPS 传输，通常用于包含认证信息的 Cookie。
HttpOnly：表示此 Cookie 必须用于 HTTP 或 HTTPS 传输，防止客户端脚本访问操作此 Cookie，有助于避免 XSS 攻击。
SameSite：用于防止跨站请求伪造攻击（CSRF），可以有三种值：Strict、Lax 和 None。

4.2.2、P3P头的副作用

P3P Header是W3C制定的一项关于隐私的标准，全称是The Platform for Privacy Preferences。如果网站返回给浏览器的HTTP头中包含有P3P头，则在某种程度上来说，将允许浏览器发送第三方Cookie。在IE下即使是<iframe>、<script>等标签也将不再拦截第三方Cookie的发送。

4.2.3、GET? POST?

如果服务器端已经区分了GET与POST，那么攻击者有什么方法呢？对于攻击者来说，有若干种方法可以构造出一个POST请求。

最简单的方法，就是在一个页面中构造好一个form表单，然后使用JavaScript自动提交这个表单。
攻击者甚至可以将这个页面隐藏在一个不可见的iframe窗口中，那么整个自动提交表单的过程，对于用户来说也是不可见的。

4.2.4、Flash CSRF

Flash也有多种方式能够发起网络请求，包括POST。除了URLRequest外，在Flash中还可以使用getURL，loadVars等方式发起请求。

4.2.5、CSRF Worm

4.3、CSRF的防御

4.3.1、验证码

4.3.2、Referer Check

常见的互联网应用，页面与页面之间都具有一定的逻辑关系，这就使得每个正常请求的Referer具有一定的规律。缺陷：

服务器并非什么时候都能取到Referer 。很多用户出于隐私保护的考虑，限制了Referer的发送。
在某些情况下，浏览器也不会发送Referer，比如从HTTPS跳转到HTTP，出于安全的考虑，浏览器也不会发送Referer。
在Flash的一些版本中，曾经可以发送自定义的Referer头。

4.3.3、Anti CSRF Token

现在业界针对CSRF的防御，一致的做法是使用一个Token。

4.3.3.1、CSRF的本质

CSRF为什么能够攻击成功？其本质原因是重要操作的所有参数都是可以被攻击者猜测到的。
一个解决方案：把参数加密，或者使用一些随机数，从而让攻击者无法猜测到参数值。

在实际应用时，Token可以放在用户的Session中，或者浏览器的Cookie中。由于Token的存在，攻击者无法再构造出一个完整的URL实施CSRF攻击。

Token需要同时放在表单和Session中。在提交请求时，服务器只需验证表单中的Token，与用户Session（或Cookie）中的Token是否一致，如果一致，则认为是合法请求；如果不一致，或者有一个为空，则认为请求不合法，可能发生了CSRF攻击。

4.3.3.2、Token的使用原则

Token 生成原则：
- 防御 CSRF（跨站请求伪造）的 Token 是根据“不可预测性原则”设计的方案。
- Token 的生成必须足够随机，通常使用安全的随机数生成器来生成。
Token 使用方便性：
- 在一个用户的有效生命周期内，可以允许使用同一个 Token，直到它被消耗掉。
- 如果用户已经提交了表单，应该重新生成一个新的 Token，以确保安全性。
- 当用户同时打开多个相同页面并操作时，某个页面消耗掉 Token 后，其他页面的表单仍保存着已消耗的 Token，导致其他页面再次提交时出现 Token 错误。解决方法是生成多个有效的 Token，以适应多页面共存的场景。
Token 存储位置问题：
- 如果 Token 存储在 Cookie 中而不是服务器端的 Session 中，会引发新的问题。
Token 保密性：
- 使用 Token 时应注意其保密性。
- 尽量将 Token 放在表单中，而不是 URL 中。
- 将敏感操作由 GET 请求改为 POST 请求，以 form 表单（或 AJAX）的形式提交，可以避免 Token 泄露。