网络与安全

TCP/IP协议

客户端与服务器端进行相互通信，双方必须遵循相同的规则，比如：

如何探测到通信目标
由哪一边先发起通信
使用哪种语言进行通信
怎样结束通信
不同的硬件、操作系统之间如何通信

而这一切都需要一种特定的规则来约束，我们称该规则为协议。

TCP/IP协议是一个协议集合。TCP/IP协议按照层次分为以下五层。

应用层（HTTP协议，FTP协议，DNS协议）
传输层（TCP协议，UDP协议）
网络层（IP协议）
数据链路层
物理层

发送端在层与层间传输数据时，每经过一层都会被加上首部信息，接收端每经过一层都会删除一条首部

应用层–> http数据
传输层–> http数据+TCP首部
网络层–> http数据+TCP首部+IP首部
数据链路层–> http数据+TCP首部+IP首部+以外网首部

OSI 7层模型

应用层
表示层
会话层
传输层
网络层
数据链路层
物理层

辅助记忆：物数网传会表应（误上网站会屌硬）

HTTP协议

HTTP是超文本传输协议，是应用层协议，是无状态的，通过session和cookie来保持会话状态。包含请求报文和响应报文。基于TCP协议。

TCP, UDP协议

UDP：用户数据报协议，是一个简单的面向数据报的传输层协议。
是不可靠的传输协议，在传输数据之前不需要先建立连接，在接收到UDP报文后，不需要确认。只要有数据就发，不管对方是否可以正确接受。优点，无需建立连接，效率高，头部小。

使用场景有：音视频传输，直播，动作类游戏等（常说的丢包）。

TCP：传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。
通过三次握手建立连接，四次挥手取消连接，因为TCP是全双工的，因此在每一个方向都必须单独关闭。

区别：

TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）；UDP提供无连接的传输，通信前不需要建立连接。
TCP提供可靠的传输（有序，无差错，不丢失，不重复）； UDP提供不可靠的传输。
TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组； UDP是面向数据报的传输，没有分组开销。
TCP提供拥塞控制和流量控制机制； UDP不提供拥塞控制和流量控制机制。

三次握手，四次挥手

SYN（Synchronize）：请求连接
ACK（Acknowledgement）：确认
FIN（Finish）：请求关闭连接

三次握手：

主机A：SYN
主机B：SYN+ACK
主机A：ACK

四次挥手：

主机A：FIN
主机B：ACK
主机B：FIN
主机A：ACK

请求报文，响应报文

请求报文：

请求行
请求方法字段、URL字段、HTTP协议版本字段。它们用空格分隔。例如 GET /index.html HTTP/1.1
请求头
请求头由关键字/值对组成，每对占一行。
空行
请求体
请求携带的数据。

响应报文：

响应行
包含协议版本，状态码和状态码的原因短语，例如：HTTP/1.1 200 OK
响应头
请求头也是由关键字/值对组成，每对占一行。
空行
响应体
服务器响应的数据

HTTPs

http协议的数据都是明文进行传输的，所以对于一些敏感信息的传输就很不安全，HTTPS就是为了解决HTTP的不安全而生的。

对称加密：即通信的双方都使用同一个秘钥进行加解密。
非对称加密：用一对密钥对，公钥加私钥。用私钥加密的数据,只有对应的公钥才能解密,用公钥加密的数据,只有对应的私钥才能解密。

对称加密虽然很简单性能也好，但是无法解决首次把秘钥发给对方的问题，很容易被黑客拦截秘钥。
非对称加密虽然安全性更高，但是带来的问题就是速度很慢，影响性能。
那么结合两种加密方式，将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。

如果此时在客户端和服务器之间存在一个中间人,这个中间人只需要把原本双方通信互发的公钥,换成自己的公钥,这样中间人就可以轻松解密通信双方所发送的所有数据。
要保证数据的安全，就必须得保证服务器给客户端下发的公钥是真正的公钥，而不是中间人伪造的公钥。那就得引入数字证书了，数字证书是服务器主动去权威机构申请的，证书中包括：签发者、证书用途、使用者公钥、使用者的HASH算法、证书到期时间等。
证书中的公钥，是权威机构的私钥加密的，而权威机构的私钥是内置在浏览器或操作系统环境中的。
客户端收到权威机构的证书之后，用内置的私钥解密得到服务端公钥，进行操作。

但是如果证书被中间人篡改了，那样客户端拿到的公钥还是中间人的。所以还要保证客户端收到的证书是服务器下发的证书，没有被中间人篡改过。
数字签名正是这个作用。证书中包含该证书的数字签名（权威机构通过hash算法生成证书的数字摘要，然后用私钥加密，得到数字签名）

数字签名怎么防止证书被篡改？

客户端接收到证书以后，用内置的私钥解密得到服务端公钥和证书签名，再将签名解密得到数字摘要，用同样的算法计算数字摘要，两者如果一致，说明证书没有被串改。
如过证书被调包，上面的签名肯定是没有问题的，但是客户端还会检查证书中的域名和当前访问的域名是否一致。如果不一致，会发出警告！

https通信过程：

客户端发起https请求
服务端下发证书
客户端验证证书，并获得服务端公钥
客户端生成一个随机的对称密钥，用服务端公钥加密
服务端用自己的私钥解密，得到对称加密的密钥
双方用对称加密进行通信

HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

HTTP1.0最早在网页中使用是在1996年，HTTP1.1则在1999年才开始广泛应用，也是当前使用最为广泛的HTTP协议。HTTP2.0是在2015年产生。HTTP协议的升级其实是对 HTTP 进行深入理解并不断优化的过程。主要为了优化带宽和延迟。

HTTP1.0 HTTP 1.1主要区别

请求方法和状态码
HTTP1.0 定义了三种请求方法： GET, POST 和 HEAD方法。
HTTP1.1 新增了六种请求方法：OPTIONS、PUT、PATCH、DELETE、TRACE 和 CONNECT 方法
还新增了一些状态码。
长连接
HTTP 1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接。在 HTTP/1.1 中，一个连接可用于一次或多次请求/响应交换，尽管连接可能由于各种原因被关闭。
要建立长连接，可以在请求消息中包含Connection: Keep-Alive头，如果服务器愿意维持这条连接，在响应消息中也会包含一个Connection: Keep-Alive的头。请求头中如果Connection: false，表示此次请求结束后关闭长连接。
HTTP1.1默认添加这个头部，HTTP1.0需要手动添加。
缓存处理
在HTTP1.0中主要使用header里的Expires, If-Modified-Since/Last-Modefied来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如：Cache-Control, Etag/If-None-Match等更多可供选择的缓存头来控制缓存策略。
Host域
HTTP1.1在请求头里多了一个Host域，而且是必传的，HTTP1.0则没有这个域。请求消息中如果没有Host域会报400。
带宽优化及网络连接的使用
HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。
Range头域可以请求实体的一个或者多个子范围。例如
- 表示头500个字节：bytes=0-499
- 表示第二个500字节：bytes=500-999
- 表示最后500个字节：bytes=-500
- 表示500字节以后的范围：bytes=500-
- 第一个和最后一个字节：bytes=0-0,-1
- 同时指定几个范围：bytes=500-600,601-999

HTTP1.1与HTTP2.0的区别

二进制分帧
HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。
HTTP/1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。
HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。
头部压缩
HTTP/1.x会在请求和响应中中重复地携带不常改变的、冗长的头部数据，给网络带来额外的负担。
HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送。只发送差异数据。
服务端推送
服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML再发送这些请求。
服务端可以主动推送，客户端也有权利选择接收与否。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。
多路复用
HTTP 1.x 中，如果想并发多个请求，必须使用多个 TCP 链接，且浏览器为了控制资源，还会对单个域名有 6-8个（Chrome是6个）的TCP链接请求限制。
HTTP2中，所有的请求都是通过一个 TCP连接并发完成。
- 同域名下所有通信都在单个连接上完成。
- 单个连接可以承载任意数量的双向数据流。
- 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装
  
  多路复用带来一个新的问题是，在连接共享的基础之上有可能会导致关键请求被阻塞。http2.0允许给每个request设置优先级，这样重要的请求就会优先得到响应。比如浏览器加载首页，首页的html内容应该优先展示，之后才是各种静态资源文件，脚本文件等加载，这样可以保证用户能第一时间看到网页内容。
HTTP2.0要基于HTTPs

SSE（Server-Sent Event，服务端推送事件）

服务器推送事件（Server-sent Events）是基于WebSocket 协议的一种服务器向客户端发送事件&数据的单向通讯。一般用在服务器主动向客户端通信，而客户端无需与服务端通信的时候。如果双向交互，可以用websocket，因为他是全双工的。也可以用轮询，但是浪费资源。

在Web应用程序中使用服务器发推送件很简单。在服务器端,只需要按照一定的格式返回事件流,在客户端中,只需要为一些事件类型绑定监听函数,和处理其他普通的事件没多大区别。

HTTP方法

GET: 通常用于请求服务器发送某些资源
POST: 发送数据给服务器
PUT: 用于新增资源或者使用请求中的有效负载替换目标资源的表现形式
DELETE: 用于删除指定的资源
PATCH: 用于对资源进行部分修改
OPTIONS: 用于获取目的资源所支持的通信选项
HEAD: 请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源
CONNECT: HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器
TRACE: 回显服务器收到的请求，主要用于测试或诊断

Get与Post的区别

数据传输方式不同：GET请求通过URL传输数据，而POST的数据通过请求体传输。
安全性不同：POST的数据因为在请求主体内，所以有一定的安全性保证，而GET的数据在URL中，通过历史记录，缓存很容易查到数据信息。
特性不同：GET是安全（这里的安全是指只读特性，就是使用这个方法不会引起服务器状态变化）且幂等（幂等的概念是指同一个请求方法执行多次和仅执行一次的效果完全相同），而POST是非安全非幂等

PUT和POST都是给服务器发送新增资源，有什么区别？

PUT方法是幂等的：连续调用一次或者多次的效果相同（无副作用），而POST方法是非幂等的。
PUT的URI指向是具体单一资源，而POST可以指向资源集合。

PUT和PATCH都是给服务器发送修改资源，有什么区别？

PUT和PATCH都是更新资源，而PATCH用来对已知资源进行局部更新。
直接覆盖资源的修改方式应该用put，修改某一两个字段用patch。

HTTP是无状态的，所以用cookie和session来保持会话状态的。

Cookie是存储在客户端的一小段文本信息。一般用来保存sessionid
Session是服务器运行时创建的一个对象，用来保存一些用户状态信息。

服务器端创建Session之后，就可以调用Session相关的方法往Session中增加内容了，而这些内容只会保存在服务器中，发到客户端的只有SessionId。通过Set-cookie
当客户端再次发送请求的时候，会将这个cookie带上，服务器接受到请求之后就会依据cookie中的SessionId找到相应的Session，从而再次使用。
正是这样一个过程，用户的状态也就得以保持了。

session， token, jwt token

jwt token

header：声明类型jwt和加密算法，然后用base64加密。
1
2
3
4
{
'typ': 'JWT',
'alg': 'HS256'
}

payload：声明令牌颁发者，过期时间，或者一些自定义信息，不要放敏感数据。然后用base64加密。

{
    iss: jwt签发者
    sub: jwt所面向的用户
    aud: 接收jwt的一方
    exp: jwt的过期时间，这个过期时间必须要大于签发时间
    nbf: 定义在什么时间之前，该jwt都是不可用的.
    iat: jwt的签发时间
    jti: jwt的唯一身份标识，主要用来作为一次性token,从而回避重放攻击。
}

Signature 签名：base64的header 和 base64的payload，用header中声明的加密算法加密，密钥由服务端维护。

token 和 session

session：通常保存在服务器的内存中，用户多服务器开销大，而且分布式应用上需要配合redis存储管理session才能实现session共享。因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
token：不需要在服务端去保留用户的认证信息或者会话信息。服务器颁发token，用户以后每次请求携带token就行，验证通过即可。token会保存在服务端数据库或redis中。

token 和 jwt token

服务端验证token信息要进行数据的查询操作；验证JWT token信息就不用，在服务端使用密钥校验就可以，不用数据库的查询。
jwt token的有效期要设置的尽可能短。防止泄露后被盗用。
jwt的缺陷是一旦下发，服务端无法主动让token失效。解决办法是提供一个类似黑名单的机制，每次访问系统时先检查此 jwt 令牌是否已经被拉黑。但是此时又回到了使用redis或者数据库查询的路上了。
token好处是随时可以删除某个token，阻断该token继续使用。

前端如何实现即时通讯？

websocket协议
WebSocket是HTML5开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。是一个全新的、独立的协议，基于TCP协议，与http协议兼容。浏览器和服务器只需要做一个握手的动作，然后，浏览器和服务器之间就形成了一条快速通道。两者之间就直接可以数据互相传送。常用类库：socket.io / ws
短轮询
原理很简单，每隔一段时间客户端就发出一个请求，去获取服务器最新的数据，一定程度上模拟实现了即时通讯。
- 优点：兼容性强，实现非常简单
- 缺点：延迟性高，非常消耗请求资源，影响性能
Comet技术（“服务器推”）
Comet的实现主要有两种方式，基于Ajax的长轮询（long-polling）方式和基于 Iframe 及 htmlfile 的流（http streaming）方式。
优点：兼容性好，消息即时到达，不发无用请求
缺点：服务器维护长连接消耗资源
1. 长轮询
  - 浏览器发出XMLHttpRequest 请求，服务器端接收到请求后，会阻塞请求直到有数据或者超时才返回
  - 浏览器JS在处理请求返回信息（超时或有效数据）后再次发出请求，重新建立连接。
  - 在此期间服务器端可能已经有新的数据到达，服务器会选择把数据保存，直到重新建立连接，浏览器会把所有数据一次性取回。
2. iframe
  - Iframe设置为不显示。
  - src设为请求的数据地址。
  - 定义个父级函数让iframe子页面调用，传数据给父页面。
  - 定义onload事件，服务器timeout后再次重新加载iframe。
service worker

Web Worker, Service Worker, Web Socket

Web Workers 是现代浏览器提供的一个javascript多线程解决方案，我们可以将一些大计算量的代码交由web Worker运行。它能让你把复杂的功能推到后台线程中，这样你的主JS就可以继续工作.

/* main.js */

// 创建 worker
const myWorker = new Worker('worker.js');

// 向 worker 传递信息
myWorker.postMessage('Hello!');

// 接收从 worker 传递过来的信息
myWorker.onmessage = function(e) {
console.log(e.data);
}

/* worker.js */

// 接收主文件的信息
self.onmessage = function(e) {
console.log(e.data);

// 向主文件发送信息
self.postMessage(workerResult);
}

Service Worker是基于Web Worker的事件驱动的，他们执行的机制都是新开一个线程去处理一些额外的，以前不能直接处理的任务。Service Worker实际上是浏览器和服务器之间的代理服务器，允许您控制页面中的网络请求是如何处理的.基于它可以实现拦截和处理网络请求、消息推送、静默更新、事件同步等服务。

/* main.js */
navigator.serviceWorker.register('/service-worker.js');

/* service-worker.js */

// Install （安装）
self.addEventListener('install', function(event) {
    // ...
});

// Activate （激活）
self.addEventListener('activate', function(event) {
    // ...
});

// 监听主文档中的网络请求
self.addEventListener('fetch', function(event) {
    // 返回缓存中的数据，所以可以做离线应用
    event.respondWith(
        caches.match(event.request);
    );
});

WebSocket: 在客户端和服务器之间创建一个开放的连接，允许在一个连接上进行双向通信。适合目前使用长轮询的任何情况，比如聊天软件、在线游戏。可以直接与DOM交互。通信是通过WebSocket的send方法。

状态码

2开头（请求成功）表示成功处理了请求的状态代码。
- 200 （成功）服务器已成功处理了请求。通常，这表示服务器提供了请求的网页。
- 201 （已创建）请求成功并且服务器创建了新的资源。
- 202 （已接受）服务器已接受请求，但尚未处理。
- 203 （非授权信息）服务器已成功处理了请求，但返回的信息可能来自另一来源。
- 204 （无内容）服务器成功处理了请求，但没有返回任何内容。
- 205 （重置内容）服务器成功处理了请求，但没有返回任何内容。
- 206 （部分内容）服务器成功处理了部分 GET 请求。
3开头（请求被重定向）表示要完成请求，需要进一步操作。通常，这些状态代码用来重定向。
- 300 （多种选择）针对请求，服务器可执行多种操作。服务器可根据请求者 (user agent) 选择一项操作，或提供操作列表供请求者选择。
- 301 （永久移动）请求的网页已永久移动到新位置。服务器返回此响应（对 GET 或 HEAD 请求的响应）时，会自动将请求者转到新位置。
- 302 （临时移动）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
- 303 （查看其他位置）请求者应当对不同的位置使用单独的 GET 请求来检索响应时，服务器返回此代码。
- 304 （未修改）自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容。
- 305 （使用代理）请求者只能使用代理访问请求的网页。如果服务器返回此响应，还表示请求者应使用代理。
- 307 （临时重定向）服务器目前从不同位置的网页响应请求，但请求者应继续使用原有位置来进行以后的请求。
4开头（请求错误）这些状态代码表示请求可能出错，妨碍了服务器的处理。
- 400 （错误请求）服务器不理解请求的语法。
- 401 （未授权）请求要求身份验证。对于需要登录的网页，服务器可能返回此响应。
- 403 （禁止）服务器拒绝请求。
- 404 （未找到）服务器找不到请求的网页。
- 405 （方法禁用）禁用请求中指定的方法。
- 406 （不接受）无法使用请求的内容特性响应请求的网页。
- 407 （需要代理授权）此状态代码与 401（未授权）类似，但指定请求者应当授权使用代理。
- 408 （请求超时）服务器等候请求时发生超时。
- 409 （冲突）服务器在完成请求时发生冲突。服务器必须在响应中包含有关冲突的信息。
- 410 （已删除）如果请求的资源已永久删除，服务器就会返回此响应。
- 411 （需要有效长度）服务器不接受不含有效内容长度标头字段的请求。
- 412 （未满足前提条件）服务器未满足请求者在请求中设置的其中一个前提条件。
- 413 （请求实体过大）服务器无法处理请求，因为请求实体过大，超出服务器的处理能力。
- 414 （请求的 URI 过长）请求的 URI（通常为网址）过长，服务器无法处理。
- 415 （不支持的媒体类型）请求的格式不受请求页面的支持。
- 416 （请求范围不符合要求）如果页面无法提供请求的范围，则服务器会返回此状态代码。
- 417 （未满足期望值）服务器未满足”期望”请求标头字段的要求。
5开头（服务器错误）这些状态代码表示服务器在尝试处理请求时发生内部错误。这些错误可能是服务器本身的错误，而不是请求出错。
- 500 （服务器内部错误）服务器遇到错误，无法完成请求。
- 501 （尚未实施）服务器不具备完成请求的功能。例如，服务器无法识别请求方法时可能会返回此代码。
- 502 （错误网关）服务器作为网关或代理，从上游服务器收到无效响应。
- 503 （服务不可用）服务器目前无法使用（由于超载或停机维护）。通常，这只是暂时状态。
- 504 （网关超时）服务器作为网关或代理，但是没有及时从上游服务器收到请求。
- 505 （HTTP 版本不受支持）服务器不支持请求中所用的 HTTP 协议版本。

XSS，怎么防范

Cross-Site Scripting，跨站脚本注入。攻击者将脚本注入到目标网站进行攻击。XSS的实质其实是HTML代码与Javscript代码的注入。
根据攻击的来源，XSS 攻击可分为存储型、反射型和 DOM 型三种。

存储型，恶意代码被存储到了数据库中。危害最大，永久性的。
- 攻击者将恶意代码提交到目标网站的数据库中。
- 用户打开目标网站时，网站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
  
  这种攻击常见于带有用户保存数据的网站功能，如论坛发帖、商品评论、用户私信等。
反射型，恶意代码在URL中
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL 时，网站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
- 用户浏览器接收到响应后解析执行，混在其中的恶意代码也被执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
  
  反射型 XSS 漏洞常见于通过 URL 传递参数的功能，如网站搜索、跳转等。
DOM型，恶意代码也是在URL中
- 攻击者构造出特殊的 URL，其中包含恶意代码。
- 用户打开带有恶意代码的 URL。
- 用户浏览器接收到响应后解析执行，前端 JavaScript 取出 URL 中的恶意代码并执行。
- 恶意代码窃取用户数据并发送到攻击者的网站，或者冒充用户的行为，调用目标网站接口执行攻击者指定的操作。
  
  DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞，而其他两种 XSS 都属于服务端的安全漏洞。

防范

CSP
对于用户的任何输入要进行检查、过滤和转义
纯前端渲染
尽量不使用innerHTML()等可以把数据作为HTML插入到页面的方法。

CSRF，怎么防范

跨站请求伪造，是一种劫持受信任用户向服务器发送非预期请求的攻击方式。CSRF 攻击是攻击者借助受害者的 Cookie 骗取服务器的信任，可以在受害者毫不知情的情况下以受害者名义伪造请求发送给受攻击服务器，从而在并未授权的情况下执行在权限保护之下的操作。

受害者登录 a.com，并保留了登录凭证（Cookie）
攻击者引诱受害者访问了b.com
b.com 向 a.com 发送了一个请求：a.com/act=xx浏览器会默认携带a.com的Cookie
a.com接收到请求后，对请求进行验证，并确认是受害者的凭证，误以为是受害者自己发送的请求
a.com以受害者的名义执行了act=xx
攻击完成，攻击者在受害者不知情的情况下，冒充受害者，让a.com执行了自己定义的操作

CSRF的两个特点：

CSRF（通常）发生在第三方域名。
CSRF攻击者不能获取到Cookie等信息，只是使用。

防范：

服务器做同源检测，在HTTP头中有一个字段叫Referer，记录了该HTTP请求的来源地址。
Cookie设置HTTP-only。 Samesite。提交时要求附加本域才能获取到信息
请求中包含token，而不是单单只用cookie

SQL注入

Sql 注入攻击，是通过将恶意的 Sql查询或添加语句插入到应用的输入参数中，再在后台Sql服务器上解析执行进行的攻击。

流程如下所示：

找出SQL漏洞的注入点
判断数据库的类型以及版本
猜解用户名和密码
利用工具查找Web后台管理入口
入侵和破坏

预防方式如下：

严格检查输入变量的类型和格式
过滤和转义特殊字符
对访问数据库的Web应用程序采用Web应用防火墙