HNU网络安全期末知识点整理-CSDN博客

本文链接：https://blog.csdn.net/Wzasty/article/details/148311815

缓冲区溢出攻击与防御

低层协议栈安全体系

这是网络通信的分层模型，展示了数据如何从应用层向下传递到物理网络。左侧是协议层次结构，右侧展示了数据在每一层如何被封装。

数据传递方向是从上到下的封装过程：

应用层生成消息(message)
传输层(TCP/UDP)将消息分割成段(segment)并添加TCP头
网络层(IP)将段封装成数据包(packet)并添加IP头
链路层将数据包封装成帧(frame)，添加以太网头(ETH)和尾(ETF)

每一层都添加自己的头部信息，形成一个完整的封装过程。数据最终以帧的形式在物理网络中传输。

当数据到达目的地时，会进行相反的解封装过程，从下到上逐层剥离各个头部，直到应用层接收到原始消息。

在数据传输过程中，消息会逐渐变长，因为每一层协议都会在原始数据的基础上添加额外的头部信息（在链路层还会添加尾部信息）。应用层的原始消息经过传输层添加TCP/UDP头部、网络层添加IP头部、链路层添加以太网头部和尾部后，数据包的总体积会显著增加。

ip数据包经由路由转发的时候源ip，目的ip是否改变？答案是不能改变的，除非做了nat转换才能改变；NAT为特殊应用，会修改源IP为网关自己外网IP。

IP数据包经由路由转发的时候源ip，目的ip，源MAC,目的mac是否发生改变，如何改变？

A—–(B1-B2)—–(C1-C2)——-E

如上为例，B1和B2是路由器B上的两个接口，C1和C2是路由器C上的两个接口，A和E是PC，由主机A向主机E发送数据包，那么在主机A形成的数据包的目的IP就是E的IP，源IP就是主机A的IP地址，目标MAC地址就是B1的MAC地址，源MAC地址就是A的MAC地址；

由A发给路由器B，B经过重封装后，源IP和目标IP是不变的，源MAC地址变成B2的MAC地址，目标MAC地址变成C1的MAC地址，封装完成发送给路由器C，路由器C接收到数据包后和B做的操作是一样的，源IP和目标IP的不变的，源MAC地址变成C2的MAC地址，目标MAC地址变成主机E的MAC地址，然后发送给主机E，这样E就收到了这个数据包，当回复数据包的时候就是把收到的数据包的源IP地址（主机A的IP地址）和源MAC地址（接口C2的MAC地址）作为他的目标IP和目标MAC地址。

地址解析协议，即ARP（Address Resolution Protocol），是根据IP地址获取物理地址的一个TCP/IP协议。以太网中，主机发送信息时将包含目标IP地址的ARP request广播到网络上的所有主机，并接收返回ARP reply消息，以此确定目标的物理地址--MAC地址。收到返回消息后将该IP地址和物理地址存入本机ARP缓存中并保留一定时间，下次请求时直接查询ARP缓存以节约资源。

一台不可信赖的计算机会发出假冒的ARP查询或应答信息，并将所有流向它的数据流转移。这样，它就可以伪装成某台机器，或修改数据流。这种攻击叫做ARP欺骗攻击(ARP Spoofing)。

上图中：

A/B/G的联网情况

网关G: 可以上网，正常工作
用户A: 无法正常上网，因为发往网关的流量被重定向到攻击者B
攻击者B: 可以上网，并能截获A的流量

防御方法

配置静态ARP表项，将IP和MAC地址固定绑定
启用交换机的动态ARP检测(DAI)和DHCP Snooping功能
使用ARP防火墙或安全监控软件检测和阻止异常ARP报文

A/B/G的联网情况

网关G: 可以上网，但发给用户A的数据会被错误发送到攻击者B
用户A: 无法上网，因为网关G的ARP表被污染，发往用户A的流量被发送到攻击者B而非用户A
攻击者B: 可以上网，并可窃取发往用户A的数据

防御方法

在网关上配置静态ARP表项，绑定IP和MAC地址
启用交换机的ARP检测功能，过滤伪造的ARP报文
部署网络安全监控系统，实时检测并阻断ARP欺骗攻击

攻击者B伪造了用户C的ARP报文发给用户A，使用户A的ARP表中用户C的IP地址映射到了攻击者B的MAC地址。当用户A向用户C发送数据时，数据会被错误地发送到攻击者B，导致攻击者B能够窃取用户A发往用户C的所有数据。如果攻击者B同时转发数据到真正的用户C，用户A和C都不会察觉通信被截获，形成了典型的中间人攻击。

TCP三次握手是建立TCP连接的过程，具体步骤如下：

第一次握手：客户端发送SYN报文到服务器，并指定初始序列号X。此时客户端进入SYN_SENT状态。
第二次握手：服务器收到SYN报文后，回复SYN+ACK报文，确认号为X+1，同时自己也指定一个初始序列号Y。此时服务器进入SYN_RCVD（半开放）状态。
第三次握手：客户端收到服务器的SYN+ACK报文后，回复ACK报文，确认号为Y+1，序列号为X+1。此时客户端和服务器都进入ESTABLISHED状态，连接建立完成。

第几次握手的包结构？第二次

第三次握手的包结构序列号和确认号字段是多少？ 1,1

TCP四次挥手过程

TCP四次挥手是终止TCP连接的过程，具体步骤如下：

第一次挥手：客户端发送FIN报文，序列号为u，表示客户端不再发送数据。客户端进入FIN-WAIT-1状态。
第二次挥手：服务器收到FIN报文后，发送ACK确认报文，确认号为u+1，序列号为v。服务器进入CLOSE-WAIT状态，客户端收到后进入FIN-WAIT-2状态。
第三次挥手：服务器数据发送完毕后，发送FIN+ACK报文，序列号为w，确认号为u+1，表示服务器也不再发送数据。服务器进入LAST-ACK状态。
第四次挥手：客户端收到服务器的FIN报文后，发送ACK确认报文，序列号为u+1，确认号为w+1。客户端进入TIME-WAIT状态，等待2MSL（最大报文生存时间）后关闭连接。服务器收到确认后立即关闭连接。

服务端为何要发完ACK报文后，再发一个FIN+ACK报文？

服务器端收到FIN报文段，并不立即用FIN报文段回复客户端，而是向客户端发送一个确认序号ack=x+1，同时通知自己的应用程序，对方要求关闭连接（先发ack是防止客户端重复发送FIN报文）。

然后，服务器的应用程序完成剩余工作后，通知TCP要关闭连接，因此再发送FIN报文，表示服务器端也愿意分手了，将关闭服务器与客户端的连接，释放资源。

当客户端进入TIME-WAIT状态的时候(也就是第四次挥手的时候)，必须经过时间计数器设置的时间2MSL(最长报文段寿命)后，才能进入关闭状态，为什么呢？

1、为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。

2、他还可以防止已失效的报文段。客户端在发送最后一个ACK之后，再经过2MSL关闭，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从而保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。

SYN Flood攻击：攻击者利用TCP连接的半开放状态发动攻击。攻击者使用带有随机源IP地址的SYN数据包对服务器进行大流量冲击，使服务器一直处于半开放连接状态，从而无法完成3步握手协议。填满服务器上的积压队列，使其无法处理正常连接

SYN Defender：目标主机的ACK+SYN包返回给源主机后，防火墙自动产生一个ACK给目标主机，以释放未完成任务等待队列

SYN proxy：SYN Defender的改进，防火墙在与源主机建立连接后，再由防火墙与目标主机建立连接

序号攻击(IP欺骗)：如果攻击者能够预测目标主机选择的起始序号，他就可能欺骗该目标主机，使其相信它正与一台可信的主机会话。

域名系统（DNS）是一个分布式数据库系统，用来实现“域名—IP地址”，或“IP地址—域名”的映射。

初始情况：用户想访问a.bank.com，浏览器向本地DNS解析器发送查询请求。
正常DNS查询：本地DNS解析器向.com域名服务器发送带有特定查询ID（QID=x₁）的请求，查询a.bank.com的IP地址。
攻击者的行动：
- 攻击者不等待正常DNS响应，而是大量发送伪造的DNS响应包
- 这些响应包使用随机的查询ID（y₁, y₂, ...），试图猜中原始查询的ID
- 在伪造的响应中，攻击者提供两条关键信息：
  - NS bank.com=ns.bank.com（声明bank.com的权威域名服务器）
  - A ns.bank.com=attackerIP（将该权威服务器指向攻击者控制的IP）
攻击成功条件：
- 如果攻击者猜中了查询ID（存在j使得x₁=yⱼ）
- 且攻击者的响应比合法响应先到达DNS解析器
- 则伪造的DNS记录会被缓存
攻击后果：
- 本地DNS解析器缓存了错误的记录
- 攻击者控制了bank.com域名的解析
- 所有对该域名（包括子域名）的后续查询都会被定向到攻击者的服务器

补丁的核心思路是对DNS查询所使用的源端口号进行随机化处理，从而使得攻击者需要同时猜测正确的事务ID和源端口号，大大增加了成功进行缓存投毒攻击的难度

雪人计划设立的中国IPv6“主根服务器”并非完全独立，不是真正的主根服务器，而是在美国的IPv4主根服务器之下的测试性服务器；从技术上来看，根服务器之间也并不平等。雪人计划新增的25台IPv6根服务器的地位事实上要低于之前的13台IPv4根服务器。

NAT把内部私有IP地址转换为外部公有IP地址，NAT的主要作用是解决当前IPv4地址空间缺乏的问题。

高层协议栈安全体系

附录DDoS

DDoS之所以是一个难以解决的问题，主要因为它利用了互联网的基本设计特性。攻击方式简单（只需发送大量流量），工具容易获取；攻击者可以利用互联网的开放性和路由器处理简单性；大量脆弱机器可被利用组成攻击网络；攻击流量往往能伪装成正常请求（如HTTP请求）难以区分；缺乏有效的追踪溯源机制；服务提供商之间的协作受限于竞争关系，只能以人工时间尺度进行；而有效解决方案很难大规模部署，因为互联网核心架构难以根本性改变。这些因素共同使得DDoS成为一个持续存在的安全挑战。

攻击者伪造受害者的IP地址

攻击者向反射器发送错误生成数据包

反射器向受害者报告所有错误

受害者被错误信息杀死

这个攻击是针对802.11b无线网络协议中的NAV（网络分配向量）漏洞的拒绝服务攻击。NAV是一个15位字段，最大值为32767，允许任何节点预留信道一段时间，在此期间其他设备不应发送数据。攻击者利用大多数802.11b网卡不严格遵守NAV规则的缺陷，通过持续发送高NAV值的帧，即使不实际传输数据，也能预留信道时间，从而阻止其他合法客户端访问网络。图中显示攻击者通过这种"虚拟载波感知攻击"方式，有效地占用了网络资源，导致网络服务被拒绝

也可以用ICMP(ping)风暴，产生大量的echo到受害主机：Attacker向一个具有大量主机和因特网连接的网络的广播地址发送一个欺骗性Ping分组（echo 请求），这个目标网络被称为反弹站点，而欺骗性Ping分组的源地址就是攻击者希望攻击的系统。

DNS放大攻击是一种拒绝服务攻击，攻击者伪造目标受害者的IP地址发送小体积(约60字节)的DNS查询请求到开放的DNS服务器，服务器将放大后的响应(约3000字节)发送到受害者，产生约50倍的流量放大效应。根据Kaminsky-Shiffman 2006年的数据，当时互联网上存在约58万个开放解析器可被利用，攻击者能够利用这一数量庞大的开放解析器集群，向目标发送大量放大后的网络流量，从而导致目标系统或网络资源耗尽。

延缓任务控制块（TCB）分配方法

从前面SYN Flood原理可以看到，消耗服务器资源主要是因为当SYN数据报文一到达，系统立即分配TCB，从而占用了资源。而SYN Flood由于很难建立起正常连接，因此，当正常连接建立起来后再分配TCB则可以有效地减轻服务器资源的消耗。常见的方法是使用Syn Cache和Syn Cookie技术。

Syn Cache技术：Syncache: global hash table for all half open connections on all sockets.

这种技术是在收到SYN数据报文时不急于去分配TCB，而是先回应一个SYN ACK报文，并在一个专用HASH表（Cache）中保存这种半开连接信息，直到收到正确的回应ACK报文再分配TCB。在FreeBSD系统中这种Cache每个半开连接只需使用160字节，远小于TCB所需的736个字节。在发送的SYN ACK中需要使用一个己方的Sequence Number，这个数字不能被非法攻击者知道，否则对于某些稍微智能一点的Syn Flood攻击软件来说，它们在发送Syn报文后会发送一个ACK报文，如果己方的Sequence Number被攻击者猜知道，则会被其建立起真正的连接。因此一般采用一些加密算法生成难于预测的Sequence Number。

Syn Cookie技术：

对于SYN攻击，Syn Cache虽然不分配TCB，但是为了判断后续对方发来的ACK报文中的Sequence Number的正确性，还是需要使用一些空间去保存己方生成的Sequence Number等信息，也造成了一些资源的浪费。

Syn Cookie技术则完全不使用任何存储资源，这种方法比较巧妙，它使用一种特殊的算法生成Sequence Number，这种算法考虑到了对方的IP、端口、己方IP、端口的固定信息，以及对方无法知道而己方比较固定的一些信息，如MSS、时间等，在收到对方的ACK报文后，重新计算一遍，看其是否与对方回应报文中的（Sequence Number-1）相同，从而决定是否分配TCB资源。

而算法只有合法的用户知道。

SYN Cookie的缺陷：

1、无法理解SYN包中一些字段，例如MSS、时间戳等

2、由于无状态机制，如果客户端回应的ACK在传输过程中丢掉了，就会导致客户端和服务器端状态的不一致，客户端认为连接已经建立，但是服务器端没有建立，通常这个问题可以通过SYN-ACK的重传机制来解决，但是SYN Cookie中没有这部分，最后就是服务器发送RST中断连接。

3、SYN Cookie存在ACK Flood攻击缺陷

4、如果攻击者攻破了算法，仅仅使用ACK就可以完成连接的建立。使得一些通过SYN包来进行过滤的防火墙失效。

SYN Cache:

会保存SYN包里面的所有的字段，这是SYN Cookie做不到的。

实施重复文件删除技术，通过哈希值比对避免相同文件多次占用存储资源；对上传操作实施严格的速率限制和请求频率控制，防止单一用户消耗过多带宽；引入先进的人机识别验证确保请求来自真实用户；使用智能负载均衡技术分散流量；设置文件大小上限。

对线上大批攻击数据进行分析，并结合其全球智能调度系统进行实时检测，然后在边缘安全节点智能清洗各类DDoS攻击，例如CC攻击、SYN Flood攻击、UDP Flood攻击等等，保障让客户相关业务依旧可安全及其稳定的运行。

Web应用前沿攻防实战

恶意用户攻击服务器：SQL注入、文件系统遍历、访问控制中断

恶意服务器攻击用户：点击劫持、搜索访问记录、钓鱼网站

恶意用户攻击其他用户：跨站脚本攻击XSS、跨站请求伪造CSRF、远程文件包含

多服务器应用中的恶意用户：单点登录、多方支付

单点登录：多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统。

A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

互联网服务离不开用户认证。一般流程是下面这样。

用户向服务器发送账户和密码

服务器验证通过后，在当前会话（session）里保存相关数据，如用户角色、用户ID等

服务器向用户返回一个 session_id，写入用户 cookie

用户之后的每一次请求，都会通过 Cookie 将 session_id 传回服务器

服务器收到 session_id ，找到之前存储的数据，由此得知用户身份

在二阶SQL注入（也称为存储SQL注入）中，应用程序从HTTP请求中获取用户输入并将其存储以供将来使用。这通常是通过将输入放入数据库来实现的，但在存储数据的地方不会出现漏洞。稍后，当处理不同的HTTP请求时，应用程序会检索存储的数据，并以不安全的方式将其合并到SQL查询中。

3个步骤

1，先create一个恶意的账号

2，再查看所谓’自己’的profile，即执行了select * 语句 //导致users表中的administrator记录被修改

3，再以administrator身份登录即可

盲注入是指攻击者在无法直接看到SQL查询结果的情况下，通过观察应用程序的间接响应来推断数据库信息的一种SQL注入技术。

SQL注入攻击难以防御，主要是因为用户输入验证的复杂性与攻击技术的不断演变相互交织。开发人员往往安全意识不足，未能正确实施参数化查询等防御措施；而企业中的历史遗留系统改造成本高昂，导致漏洞长期存在。此外，现代应用程序的复杂架构和第三方依赖增加了攻击面，使得全面防护变得困难。SQL注入攻击可以被设计得非常隐蔽，并且实现较为简单，攻击成本低。

同源策略是浏览器的基础安全机制，限制网页只能访问与自身来源（协议、域名、端口）相同的资源，防止恶意网站窃取用户在其他网站的数据或执行未授权操作。
对于点击劫持攻击，同源策略本身无法直接防御，因为点击劫持利用的是界面视觉欺骗而非数据访问。攻击者通常通过iframe将目标网站嵌入自己的恶意页面并设为透明，覆盖在诱导性内容上，诱使用户"不知情"地点击目标网站的按钮。同源策略虽然限制了跨源脚本读取目标网站内容，但不阻止iframe加载和显示其他网站。为防范点击劫持，网站需要额外实施X-Frame-Options等HTTP响应头，明确禁止自己被嵌入其他网站的iframe中。

session与cookie的区别要分析一下：Cookie通过在客户端记录信息确定用户身份(可以比较长时间存在)，Session通过在服务器端记录信息确定用户身份(时间较短，hashtable)。Cookie实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用response向客户端浏览器颁发一个Cookie。客户端浏览器会把Cookie保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该Cookie一同提交给服务器。服务器检查该Cookie，以此来辨认用户状态。服务器还可以根据需要修改Cookie的内容。

CSRF防御技术：CSRF令牌，Cookie的SameSite属性

客户表示："我想要那个40美元的背心"（客户向Jimmy's Army Surplus提出购买请求）
系统将客户重定向到PayPal支付页面："重定向到paypal.com/pay?id=123&total=40"
客户被引导到支付链接："/pay?id=123&total=40"
PayPal系统向客户请求付款："给我40美元"
客户确认付款："这是我的40美元"
PayPal确认收到付款："好的"
订单完成信息反馈给商家："订单123已完成"
商家发货："发货您的背心"

客户对Jimmy's Army Surplus表示："我想要那个40美元的背心"（初始购买请求）
系统将客户重定向到PayPal支付页面："重定向到paypal.com/pay?id=123&total=40"
但客户在被重定向过程中篡改了URL参数："/pay?id=123&total=1"（将原价40美元改为1美元）
PayPal系统基于被篡改的参数向客户请求付款："给我1美元"（而非原价40美元）
客户确认支付被篡改的金额："这是我的1美元"
PayPal确认收到(被篡改的)付款："好的"
订单完成信息反馈给商家："订单123已完成"
商家发货："发货您的背心"（商家不知道实际只收到了1美元而非40美元）

通过数字签名机制防止了先前图片中展示的参数篡改攻击：

客户向Jimmy's Army Surplus表示："我想要那个40美元的背心"（初始购买请求）
Jimmy's系统将客户重定向到PayPal支付页面，包含以下参数：
- id=123（订单ID）
- total=40（总价格）
- callback=jimmy.com（支付完成后的回调地址）
- Signed by Jimmy（重要：此参数由Jimmy's商店使用其私钥对参数进行数字签名）
客户被重定向到PayPal的支付页面，PayPal收到相同的参数：
- id=123
- total=40
- callback=jimmy.com
- Signed by Jimmy（PayPal可以使用Jimmy的公钥验证此签名的真实性）
PayPal向客户请求付款："给我40美元"
客户确认付款："这是我的40美元"
PayPal将客户重定向回Jimmy的网站，带有以下参数：
- total=40（确认支付金额）
- Paid（支付状态）
- Signed by PayPal（重要：PayPal用自己的私钥对这些参数进行签名）
客户被重定向到jimmy.com，带有PayPal签名的支付确认：
- total=40
- Signed by PayPal（Jimmy可以使用PayPal的公钥验证此签名）
Jimmy's系统验证签名正确无误："签名验证通过，发货您的背心"
PayPal将40美元转给Jimmy's Army Surplus（完成资金结算）

Eve想从Jimmy's Army Surplus购买40美元的背心，但不想付钱
Eve创建了一个假冒商店："Eve's Totally Fake Army Surplus"，并将其关联到PayPal账户
作为客户，Eve访问Jimmy的商店并表示："我想要那个40美元的背心"
Jimmy的系统将Eve重定向到PayPal付款页面，带有参数：
- id=123
- total=40
- callback=jimmy.com
- Signed by Jimmy
关键欺骗点：Eve没有直接通过paypal向Jimmy支付，而是同时操作自己的假商店，利用这个假商店向PayPal发起一个支付请求，参数为：
- id=123
- total=40
- callback=jimmy.com（故意设置为与Jimmy相同的回调地址）
- Signed by Eve's Store
Eve通过paypal向自己的假商店支付40美元（本质上是从自己的一个账户转到自己的另一个账户）
PayPal处理完成后，根据回调地址将Eve重定向到jimmy.com，带有：
- total=40
- Paid
- Signed by PayPal
Jimmy的系统看到PayPal的签名和付款确认，认为Eve已经支付了订单，不知道这笔钱实际上是支付给了Eve自己的假商店，于是向Eve发货
结果是：
- Eve获得了Jimmy发送的真实背心
- Eve支付的40美元实际上回到了自己的假商店账户
- Eve实际上没有损失任何钱，因为钱只是在自己的账户间转移

这个攻击的本质是：Eve利用了多方支付系统中的弱点，使得自己可以向自己的假商店付款，但让Jimmy误以为这笔付款是支付给Jimmy的。Jimmy只验证了"有PayPal付款确认"，但没有验证"这笔钱实际支付给了谁"，因此被欺骗发货。

这张图展示了OAuth单点登录(Single Sign-On)的流程，描述了用户Alice如何使用Facebook账户登录Udacity平台：

Alice向Udacity表示："我想使用Facebook账号登录"
Udacity将Alice重定向到Facebook登录页面，包含：
- 回调URL（用户验证后Facebook应返回的地址）
- 标识符Z（用于跟踪此次认证请求）
Alice被重定向到Facebook，Facebook接收到Udacity的请求，参数包含："Z, callback"（标识符和回调地址）
Facebook询问Alice："你允许Udacity访问你的信息吗？"
Alice回应："好的"（同意授权）
Facebook回应："好，这是一个特殊令牌'X'。重定向到回调地址，带上标识符Z"
Facebook将Alice重定向回Udacity，并提供令牌："这是用户Z的令牌'X'"
Udacity向Facebook验证令牌："谁拥有令牌'X'？我的密钥是U"（Udacity使用自己的密钥U进行验证请求）
Facebook回应Udacity："这是Alice，她有5个朋友"（确认令牌属于Alice并提供请求的用户信息）

图片顶部的附加信息说明：

"Z linked to Alice's session shared with Facebook secret: U"：标识符Z与Alice的会话关联，且Udacity与Facebook共享密钥U
"how Z is authenticated as Alice"：中间橙色框显示整个流程是如何将标识符Z验证为Alice的
"Knows Udacity's secret is U"：Facebook知道Udacity的密钥是U

这张图展示了OAuth单点登录中的一种安全漏洞攻击场景，即"会话固定攻击"(Session Fixation Attack)，其中Eve冒充Alice登录Udacity：

Eve向Udacity表示："我想使用Facebook账号登录"（但Eve的真实目的是获取Alice的账号访问权）
Udacity将Eve重定向到Facebook登录页面，包含：回调URL（用户验证后Facebook应返回的地址），标识符Z（用于跟踪此次认证请求）
关键攻击点：Eve没有登录Facebook，而是将此URL发送给Alice："嘿Alice！看看这个URL！"（社会工程学攻击）
Alice点击链接，访问Facebook，Facebook收到带有"Z, callback"的参数
Facebook询问Alice："你允许Udacity访问你的信息吗？"
Alice不明真相，随意回答："嗯？随便吧"（同意授权）
Facebook生成授权令牌："好的，这是特殊令牌'X'。重定向到回调地址，带上标识符Z"
Facebook将Alice重定向回Udacity，但是这个令牌实际上被返回给了Eve："这是用户Z的令牌'X'"（因为标识符Z是与Eve的会话关联的）
Udacity向Facebook验证令牌："谁拥有令牌'X'？我的密钥是U"
Facebook回应："这是Alice，她有5个朋友"（确认令牌属于Alice）

图片顶部显示的关键信息：

"Z linked to Eve's session"：标识符Z与Eve的会话关联（而非Alice）
"how Eve is authenticated as Alice"：中间橙色框显示Eve如何被验证为Alice
"shared with Facebook secret: U"：Udacity与Facebook共享密钥U
"Knows Udacity's secret is U"：Facebook知道Udacity的密钥是U

消息验证和杂凑函数

A先用A私钥加密再用B公钥加密、A先用B公钥加密再用A私钥加密，这两种安全机制的区别和目的何在？

两种加密机制的目的不同：A先用A私钥加密再用B公钥加密实现了"签名+加密"双重保障，确保了信息来源可验证(A的签名)且只有B能解读(B的公钥加密)；而A先用B公钥加密再用A私钥加密实现了"加密+签名"，确保消息只有B能看懂且能验证是A发送的，但在这种情况下，任何人都可以验证A的签名，因此第一种方法在需要保密签名本身的场景中更为安全。