面试经典问题：请说出至少N种网络攻击方式

XSS攻击

Cross Site Scripting 跨站脚本攻击，是代码注入攻击的一种

把用户在此网站的cookie窃取到

如何防范：

• 像Thymeleaf等html模板引擎，都会做编码的
• server端程序使用commons-lang3#StringEscapeUtils，做转义

CSRF攻击

cross-site request forgery：跨站请求伪造

攻击方式1：

1. 假设你经常使用bank.example.com进行网上转账，在你提交转账请求时bank.example.com的前端代码会提交一个HTTP请求，所以这个浏览器中已经包含了相关的cookie，这个cookie是非常重要的

   POST /transfer HTTP/1.1
   Host: bank.example.com
   cookie: JsessionID=randomid; Domain=bank.example.com; Secure;HttpOnly
   Content-Type: application/x-www-form-urlencoded
   
   
   amount=100.00&routingNumber=1234&account=9876
   

2. 你图方便没有登出bank.example.com，随后又访问了一个恶意网站，如attacker.com，其提供了一个html页面，用户无法分辨出这是一个真实的站点，还是一个伪造的站点。

   <form action="https://bank.example.com/transfer" method="post">
     <input type="hidden" name="amount" value="100.00"/>
     <input type="hidden" name="routingNumber" value="evilsRoutingNumber"/>
     <input type="hidden" name="account" value="evilsAccountNumber"/>
     <input type="submit" value="点击就送!"/>
   </form>
   

3. 你被“点击就送”吸引了，当你点了提交按钮时你已经向攻击者的账号转了100元。现实中的攻击可能更隐蔽，恶意网站的页面可能使用Javascript自动完成提交。尽管恶意网站没有办法盗取你的session cookie（从而假冒你的身份），但恶意网站向bank.example.com发起请求时，你的cookie会被自动发送过去。而用户点击按钮就是一个表单提交，表单提交为了可用性考虑，浏览器同源策略不做限制。

4. 浏览器允许提交，并携带了cookie

攻击方式2：
攻击者试图去欺骗用户，使得用户以为访问的是银行站点（钓鱼网站）

如何防范？
就是当浏览器GET请求mybank转账表单的时候，银行站点响应会添加一个有时效性的token=yyy(hidden)，提交时会自动携带。

而攻击者伪造的转账表单中是不含有这个token的（同源策略也让攻击者不能读取bank.com转账表单的dom树），这样在服务器端就可以防护了

使用JWT token可以对CSRF攻击进行防护吗？

有些人认为前端代码将JWT通过HTTP header发送给服务端（而不是通过cookie自动发送）可以有效防护CSRF。在这种方案中，服务端代码在完成认证后，会在HTTP response的header中返回JWT，前端代码将该JWT存放到Local Storage里待用，或是服务端直接在cookie中保存HttpOnly=false的JWT。

在向服务端发起请求时，用Javascript取出JWT（否则前端Javascript代码无权从cookie中获取数据），再通过header发送回服务端通过认证。由于恶意网站的代码无法获取bank.example.com的cookie/Local Storage中的JWT，这种方式确实能防护CSRF，但将JWT保存在cookie/Local Storage中可能会给另一种攻击可乘之机，跨站脚本攻击——XSS，比如我通过留言等方式在此页面放了一个链接，点击链接之后，此页面就可以获取到存储在cookie/local storage中的jwt了，可以通过表单提交等方式写入到攻击者的系统中，从而获取jwt令牌

针对oauth2的CSRF攻击

前提：我们使用豆瓣app，通过支付宝，支付宝直接以code的方式返回授权码，并且在将用户从第三方client导向支付宝的时候，支付宝并不需要state参数

攻击者李四视角：

李四在自己支付宝联合登录点击”同意授权“之后，截获支付宝服务器返回的含有Authorization code参数的HTTP响应

李四精心构造一个链接，它会触发豆瓣app向支付宝发起令牌申请的请求，而这个请求中的Authorization Code参数正是上一步截获到的code

受害者张三的视角：

其登录了豆瓣app，张三通过站内信给李四发送了构造的链接，李四不小心点击了张三构造的链接。点击之后什么也没有发生。但是他不知道的是，其在后台已经把李四的支付宝联合登录与张三在豆瓣app网站上的用户绑定了。

令牌申请流程在张三的浏览器里被顺利触发

于是李四如果登录豆瓣app，那么其看到的是自己的信息。

李四如果通过支付宝联合登录豆瓣app，那么其看到的是张三的信息。

而张三根本不知道自己已经可以支付宝联合登录了，而且其通过自己的支付宝联合登录，并不能登录上去。

防范方法：
oauth中state的作用。state能防止的原因，就在于点击链接后续流程，并不是张三触发的，所以没有生成state。李四是无法伪造state的（与银行转账表单带有失效性token原理相同）

参考：移花接木：针对OAuth2的CSRF攻击

syn flood攻击

比如一些攻击者，不使用操作系统内核的tcp协议栈，而是自己构造出SYN帧，发给server之后却不发送ACK，使得服务器大量的连接都处理SYN-RECV状态，将操作系统内核中的SYN队列快速占满。这就是一种SYN攻击

如何防范：
采用syn cookie技术：TCP服务器接收到TCP SYN包并返回TCP SYN + ACK包时，不分配一个专门的数据区，而是根据这个SYN包计算出一个cookie值。这个cookie作为将要返回的SYN ACK包的初始序列号。当客户端返回一个ACK包时，根据包头信息计算cookie，与返回的确认序列号(初始序列号 + 1)进行对比，如果相同，则是一个正常连接，然后，分配资源，建立连接。

DNS劫持

访问了一个假的DNS Server，返回了一个错误的ip地址

运营商弹出一些广告，就是运营商的一些DNS Server把一些广告地址返回给我们，于是访问到这些

ARP欺骗

在一个本地网络中，alice和bob要进行通讯，正常情况下，各自的本地缓存中应该存着对方的ip-mac对应关系。

现在有一个攻击方charlie，其主动回答alice和bob的arp报文，这样，alice和bob发送的报文就全部都发送到charlie这里了。

其正向应用：比如在一个酒店里面，希望大家上网的时候都进行登录，也可以使用这种方式。

代理缓存污染

比如websocket中客户端发送的帧必须基于掩码编码，这是因为有一种攻击方式是针对代理服务器的缓存污染攻击

首先是有一个代理服务器，它实现是不当的，其不认识websocket协议，而只能透传http协议。在这种情况下，有一个黑客搭建了一个恶意服务器，这个服务器还提供了一个恶意页面。这个恶意页面中会使用javascript来建立一个websocket连接，攻击方式是这样的：

1. 通过javascript代码发起websocket握手
2. 这个代理服务器就按照正常的http头部，将其代理到恶意服务器了
3. websocket建立好之后，后续传递的都是基于frame帧的数据，这个帧已经不是http格式了，但这个恶意页面通过javascript代码伪造出类似HTTP GET请求的帧数据，这个HTTP GET请求的Host是一个被攻击的服务器
4. 由于代理服务器不认识websocket，所以其将这个请求直接透传给了恶意服务器
5. 恶意服务器伪造被攻击服务的响应，这个响应是用来攻击 被攻击服务器 的
6. 这个响应就被代理服务器做了缓存
7. 代理服务器给恶意页面发送返回
8. 当 被攻击服务器 的用户通过正常浏览器访问资源
9. 在代理服务器中发现缓存，返回伪造的响应
10. 从而向正常浏览器的用户返回伪造的信息

如何防范：
强制浏览器执行以下方法：

1. 生成随机的 32 位 frame-masking-key，不能让 JS 代码猜出（否则可以反向构造）
2. 对传输的包体按照 frame-masking-key 执行可对称解密的 XOR 异或操作，使代理服务器不识别，这样也就不会解析为http get请求了

DDoS攻击

当多个系统淹没目标系统（通常是一个或多个Web服务器）的带宽或资源时，就会发生拒绝服务（DDoS）攻击。 DDoS攻击使用多个唯一的IP地址或计算机，通常来自数千个感染了恶意软件的主机。