Java 面试知识点解析——网络协议

SegmentFault 社区作者：我没有三颗心脏

公众号：我没有三颗心脏
ID：wmyskxz

---

（一）网络基础知识

1）Http 和 Https 的区别？

答：

Http 协议运行在 TCP 之上，明文传输，客户端与服务器端都无法验证对方的身份；Https 是身披 SSL (Secure Socket Layer) 外壳的 Http，运行于 SSL 上，SSL 运行于 TCP 之上，是添加了加密和认证机制的 HTTP。二者之间存在如下不同：

• 端口不同：Http 与 Http 使用不同的连接方式，用的端口也不一样，前者是 80，后者是 443；

• 资源消耗：和 HTTP 通信相比，Https 通信会由于加减密处理消耗更多的 CPU 和内存资源；

• 开销：Https 通信需要证书，而证书一般需要向认证机构购买；

Https 的加密机制是一种共享密钥加密和公开密钥加密并用的混合加密机制。

---

2）对称加密与非对称加密

答：

对称密钥加密是指加密和解密使用同一个密钥的方式，这种方式存在的最大问题就是密钥发送问题，即如何安全地将密钥发给对方；而非对称加密是指使用一对非对称密钥，即公钥和私钥，公钥可以随意发布，但私钥只有自己知道。发送密文的一方使用对方的公钥进行加密处理，对方接收到加密信息后，使用自己的私钥进行解密。

由于非对称加密的方式不需要发送用来解密的私钥，所以可以保证安全性；但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

---

3）三次握手与四次挥手

答：

(1). 三次握手 （我要和你建立链接，你真的要和我建立链接么，我真的要和你建立链接，成功）

•  第一次握手：Client 将标志位 SYN 置为 1，随机产生一个值 seq=J，并将该数据包发送给 Server，Client 进入 SYN_SENT 状态，等待 Server 确认。

• 第二次握手：Server 收到数据包后由标志位 SYN=1 知道 Client 请求建立连接，Server 将标志位 SYN 和 ACK 都置为 1，ack=J+1，随机产生一个值 seq=K，并将该数据包发送给 Client 以确认连接请求，Server 进入 SYN_RCVD 状态。

• 第三次握手：Client 收到确认后，检查 ack 是否为 J+1，ACK 是否为 1，如果正确则将标志位 ACK 置为 1，ack=K+1，并将该数据包发送给 Server，Server 检查 ack 是否为 K+1，ACK 是否为 1，如果正确则连接建立成功，Client 和 Server 进入 ESTABLISHED 状态，完成三次握手，随后 Client 与 Server 之间可以开始传输数据了。

(2). 四次挥手 （我要和你断开链接；好的，断吧。我也要和你断开链接；好的，断吧）：

• 第一次挥手：Client 发送一个 FIN，用来关闭 Client 到 Server 的数据传送，Client 进入 FIN_WAIT_1 状态。

• 第二次挥手：Server 收到 FIN 后，发送一个 ACK 给 Client，确认序号为收到序号 +1 （与 SYN 相同，一个 FIN 占用一个序号） ，Server 进入 CLOSE_WAIT 状态。此时 TCP 链接处于半关闭状态，即客户端已经没有要发送的数据了，但服务端若发送数据，则客户端仍要接收。

• 第三次挥手：Server 发送一个 FIN，用来关闭 Server 到 Client 的数据传送，Server 进入 LAST_ACK 状态。

• 第四次挥手：Client 收到 FIN 后，Client 进入 TIME_WAIT 状态，接着发送一个 ACK 给 Server，确认序号为收到序号 +1，Server 进入 CLOSED 状态，完成四次挥手。

(3). 通俗一点的理解就是：

---

4）为什么 TCP 链接需要三次握手，两次不可以么？

答：

“三次握手” 的目的是为了防止已失效的链接请求报文突然又传送到了服务端，因而产生错误。

• 正常的情况：A 发出连接请求，但因连接请求报文丢失而未收到确认，于是 A 再重传一次连接请求。后来收到了确认，建立了连接。数据传输完毕后，就释放了连接。A 共发送了两个连接请求报文段，其中第一个丢失，第二个到达了 B。没有 “已失效的连接请求报文段”。

• 现假定出现了一种异常情况：即 A 发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达 B。本来这是一个早已失效的报文段。但 B 收到此失效的连接请求报文段后，就误认为是 A 再次发出的一个新的连接请求。于是就向 A 发出确认报文段，同意建立连接。

假设不采用“三次握手”，那么只要 B 发出确认，新的连接就建立了。由于现在 A 并没有发出建立连接的请求，因此不会理睬 B 的确认，也不会向 B 发送数据。但 B 却以为新的运输连接已经建立，并一直等待 A 发来数据。这样，B 的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。

---

5）为什么要四次挥手？

答：

TCP 协议是一种面向连接的、可靠的、基于字节流的运输层通信协议。TCP 是全双工模式，这就意味着，当 A 向 B 发出 FIN 报文段时，只是表示 A 已经没有数据要发送了，而此时 A 还是能够接受到来自 B 发出的数据；B 向 A 发出 ACK 报文段也只是告诉 A ，它自己知道 A 没有数据要发了，但 B 还是能够向 A 发送数据。

所以想要愉快的结束这次对话就需要四次挥手。

---

6）TCP 协议如何来保证传输的可靠性

答：

TCP 提供一种面向连接的、可靠的字节流服务。其中，面向连接意味着两个使用 TCP 的应用 （通常是一个客户和一个服务器） 在彼此交换数据之前必须先建立一个 TCP 连接。在一个 TCP 连接中，仅有两方进行彼此通信；而字节流服务意味着两个应用程序通过 TCP 链接交换 8 bit 字节构成的字节流，TCP 不在字节流中插入记录标识符。

对于可靠性，TCP 通过以下方式进行保证：

• 数据包校验： 目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；

• 对失序数据包重排序： 既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序，然后才交给应用层；

• 丢弃重复数据： 对于重复数据，能够丢弃重复数据；

• 应答机制： 当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。这个确认不是立即发送，通常将推迟几分之一秒；

• 超时重发： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段；

• 流量控制： TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

---

7）客户端不断进行请求链接会怎样？ DDos(Distributed Denial of Service)攻击？

答：

服务器端会为每个请求创建一个链接，并向其发送确认报文，然后等待客户端进行确认

(1). DDos 攻击：

• 客户端向服务端发送请求链接数据包

• 服务端向客户端发送确认数据包

• 客户端不向服务端发送确认数据包，服务器一直等待来自客户端的确认

(2). DDos 预防： （没有彻底根治的办法，除非不使用TCP）

• 限制同时打开 SYN 半链接的数目

• 缩短 SYN 半链接的 Time out 时间

• 关闭不必要的服务

---

8）GET 与 POST 的区别？

答：

GET 与 POST 是我们常用的两种 HTTP Method，二者之间的区别主要包括如下五个方面：

(1). 从功能上讲，GET 一般用来从服务器上获取资源，POST 一般用来更新服务器上的资源；

(2). 从 REST 服务角度上说，GET 是幂等的，即读取同一个资源，总是得到相同的数据，而 POST 不是幂等的，因为每次请求对资源的改变并不是相同的；进一步地，GET 不会改变服务器上的资源，而 POST 会对服务器资源进行改变；

(3). 从请求参数形式上看，GET 请求的数据会附在 URL 之后，即将请求数据放置在 HTTP 报文的请求头 中，以 ? 分割 URL 和传输数据，参数之间以 & 相连。特别地，如果数据是英文字母/数字，原样发送；否则，会将其编码为  application/x-www-form-urlencoded MIME 字符串 (如果是空格，转换为+，如果是中文/其他字符，则直接把字符串用 BASE64 加密，得出如：%E4%BD%A0%E5%A5%BD，其中 ％XX 中的 XX 为该符号以 16 进制表示的ASCII)； 而 POST 请求会把提交的数据则放置在是 HTTP 请求报文的 请求体 中。

(4). 就安全性而言，POST 的安全性要比 GET 的安全性高，因为 GET 请求提交的数据将明文出现在 URL 上，而且 POST 请求参数则被包装到请求体中，相对更安全。

(5). 从请求的大小看，GET 请求的长度受限于浏览器或服务器对 URL 长度的限制，允许发送的数据量比较小，而 POST 请求则是没有大小限制的。

为什么在 GET 请求中会对 URL 进行编码？

我们知道，在 GET 请求中会对 URL 中非西文字符进行编码，这样做的目的就是为了 避免歧义。看下面的例子，

针对 “name1=value1&name2=value2” 的例子，我们来谈一下数据从客户端到服务端的解析过程。首先，上述字符串在计算机中用 ASCII 码表示为：

   6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
   6E616D6531：name1
   3D：= 
   76616C756531：value1
   26：&
   6E616D6532：name2
   3D：= 
   76616C756532：value2

服务端在接收到该数据后就可以遍历该字节流，一个字节一个字节的吃，当吃到 3D 这字节后，服务端就知道前面吃得字节表示一个 key，再往后吃，如果遇到 26，说明从刚才吃的 3D 到 26 子节之间的是上一个 key 的 value，以此类推就可以解析出客户端传过来的参数。

现在考虑这样一个问题，如果我们的参数值中就包含=或&这种特殊字符的时候该怎么办？比如，“name1=value1”，其中 value1 的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。这样，我们的本意是只有一个键值对，但是服务端却会解析成两个键值对，这样就产生了歧义。

那么，如何解决上述问题带来的歧义呢？解决的办法就是对参数进行 URL 编码：例如，我们对上述会产生歧义的字符进行 URL 编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。

---

9）TCP 与 UDP 的区别

答：

TCP (Transmission Control Protocol) 和 UDP (User Datagram Protocol) 协议属于传输层协议，它们之间的区别包括：

•  TCP 是面向连接的，UDP 是无连接的；

• TCP 是可靠的，UDP 是不可靠的；

• TCP 只支持点对点通信，UDP 支持一对一、一对多、多对一、多对多的通信模式；

• TCP 是面向字节流的，UDP 是面向报文的；

• TCP 有拥塞控制机制;UDP 没有拥塞控制，适合媒体通信；

• TCP 首部开销 (20 个字节) 比 UDP 的首部开销 (8 个字节) 要大；

---

10）TCP 和 UDP 分别对应的常见应用层协议

答：

(1). TCP 对应的应用层协议：

• FTP：定义了文件传输协议，使用 21 端口。常说某某计算机开了 FTP 服务便是启动了文件传输服务。下载文件，上传主页，都要用到 FTP 服务。

• Telnet：它是一种用于远程登陆的端口，用户可以以自己的身份远程连接到计算机上，通过这种端口可以提供一种基于 DOS 模式下的通信服务。如以前的 BBS 是-纯字符界面的，支持 BBS 的服务器将 23 端口打开，对外提供服务。

• SMTP：定义了简单邮件传送协议，现在很多邮件服务器都用的是这个协议，用于发送邮件。如常见的免费邮件服务中用的就是这个邮件服务端口，所以在电子邮件设置-中常看到有这么 SMTP 端口设置这个栏，服务器开放的是 25 号端口。

• POP3：它是和 SMTP 对应，POP3 用于接收邮件。通常情况下，POP3 协议所用的是 110 端口。也是说，只要你有相应的使用 POP3 协议的程序 （例如 Fo-xmail 或 Outlook） ，就可以不以 Web 方式登陆进邮箱界面，直接用邮件程序就可以收到邮件 （如是 163 邮箱就没有必要先进入网易网站，再进入自己的邮-箱来收信）。

• HTTP：从 Web 服务器传输超文本到本地浏览器的传送协议。

(2). UDP 对应的应用层协议：

• DNS：用于域名解析服务，将域名地址转换为 IP 地址。DNS 用的是 53 号端口。

• SNMP：简单网络管理协议，使用 161 号端口，是用来管理网络设备的。由于网络设备很多，无连接的服务就体现出其优势。

• TFTP (Trival File Transfer Protocal) ：简单文件传输协议，该协议在熟知端口 69 上使用 UDP 服务

(3). 图示：

---

11）TCP 的拥塞避免机制

答：

拥塞：对资源的需求超过了可用的资源。若网络中许多资源同时供应不足，网络的性能就要明显变坏，整个网络的吞吐量随之负荷的增大而下降。

拥塞控制：防止过多的数据注入到网络中，使得网络中的路由器或链路不致过载。

拥塞控制的方法：

(1). 慢启动 + 拥塞避免：

慢启动：不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小;

拥塞避免：拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间 RTT 就把发送方的拥塞窗口 cwnd 加 1，而不是加倍，这样拥塞窗口按线性规律缓慢增长。

(2). 快重传 + 快恢复：

快重传：快重传要求接收方在收到一个 失序的报文段 后就立即发出 重复确认 （为的是使发送方及早知道有报文段没有到达对方） 而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

快恢复：快重传配合使用的还有快恢复算法，当发送方连续收到三个重复确认时，就执行“乘法减小”算法，把 ssthresh 门限减半，但是接下去并不执行慢开始算法：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方现在认为网络可能没有出现拥塞。所以此时不执行慢开始算法，而是将 cwnd 设置为 ssthresh 的大小，然后执行拥塞避免算法。

---

12）浏览器中输入： “`www.xxx.com`” 之后都发生了什么？ 请详细阐述。

解析：经典的网络协议问题。

答：

1、由域名→IP 地址 寻找 IP 地址的过程依次经过了浏览器缓存、系统缓存、hosts 文件、路由器缓存、 递归搜索根域名服务器。

2、建立 TCP/IP 连接 （三次握手具体过程）

3、由浏览器发送一个 HTTP 请求

4、经过路由器的转发，通过服务器的防火墙，该 HTTP 请求到达了服务器

5、服务器处理该 HTTP 请求，返回一个 HTML 文件

6、浏览器解析该 HTML 文件，并且显示在浏览器端

7、这里需要注意：

• HTTP 协议是一种基于 TCP/IP 的应用层协议，进行 HTTP 数据请求必须先建立 TCP/IP 连接

• 可以这样理解：HTTP 是轿车，提供了封装或者显示数据的具体形式；Socket 是发动机，提供了网络通信的能力。

• 两个计算机之间的交流无非是两个端口之间的数据通信,具体的数据会以什么样的形式展现是以不同的应用层协议来定义的。

---

13）什么是 HTTP 协议无状态协议？ 怎么解决 Http 协议无状态协议?

答：

HTTP 是一个无状态的协议，也就是没有记忆力，这意味着每一次的请求都是独立的，缺少状态意味着如果后续处理需要前面的信息，则它必须要重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就很快。

HTTP 的这种特性有优点也有缺点：

• 优点：解放了服务器，每一次的请求“点到为止”，不会造成不必要的连接占用

• 缺点：每次请求会传输大量重复的内容信息，并且，在请求之间无法实现数据的共享

解决方案：

• 使用参数传递机制：
将参数拼接在请求的 URL 后面，实现数据的传递 （GET方式） ，例如：/param/list?username=wmyskxz
问题：可以解决数据共享的问题，但是这种方式一不安全，二数据允许传输量只有 1kb

• 使用 Cookie 技术

• 使用 Session 技术

---

14）Session、Cookie 与 Application

答：

Cookie 和 Session 都是客户端与服务器之间保持状态的解决方案，具体来说，cookie 机制采用的是在客户端保持状态的方案，而 session 机制采用的是在服务器端保持状态的方案。

(1). Cookie 及其相关 API ：

Cookie 实际上是一小段的文本信息。客户端请求服务器，如果服务器需要记录该用户状态，就使用 response 向客户端浏览器颁发一个 Cookie，而客户端浏览器会把 Cookie 保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该 Cookie 一同提交给服务器，服务器检查该 Cookie，以此来辨认用户状态。服务器还可以根据需要修改 Cookie 的内容。

(2). Session 及其相关 API：

同样地，会话状态也可以保存在服务器端。客户端请求服务器，如果服务器记录该用户状态，就获取 Session 来保存状态，这时，如果服务器已经为此客户端创建过 session，服务器就按照 sessionid 把这个 session 检索出来使用；如果客户端请求不包含 sessionid，则为此客户端创建一个 session 并且生成一个与此 session 相关联的 sessionid，并将这个 sessionid 在本次响应中返回给客户端保存。保存这个 sessionid 的方式可以采用 cookie 机制 ，这样在交互过程中浏览器可以自动的按照规则把这个标识发挥给服务器；若浏览器禁用 Cookie 的话，可以通过 URL 重写机制 将 sessionid 传回服务器。

(3). Session 与 Cookie 的对比：

• 实现机制：Session 的实现常常依赖于 Cookie 机制，通过 Cookie 机制回传 SessionID；

• 大小限制：Cookie 有大小限制并且浏览器对每个站点也有 cookie 的个数限制，Session 没有大小限制，理论上只与服务器的内存大小有关；

• 安全性：Cookie 存在安全隐患，通过拦截或本地文件找得到 cookie 后可以进行攻击，而 Session 由于保存在服务器端，相对更加安全；

• 服务器资源消耗：Session 是保存在服务器端上会存在一段时间才会消失，如果 session 过多会增加服务器的压力。

(4). Application：

Application （ServletContext） ：与一个Web应用程序相对应，为应用程序提供了一个全局的状态，所有客户都可以使用该状态。

---

15）滑动窗口机制

答：

由发送方和接收方在三次握手阶段，互相将自己的最大可接收的数据量告诉对方。也就是自己的数据接收缓冲池的大小。这样对方可以根据已发送的数据量来计算是否可以接着发送。在处理过程中，当接收缓冲池的大小发生变化时，要给对方发送更新窗口大小的通知。这就实现了流量的控制。

---

16）常用的 HTTP 方法有哪些？

答：

• GET：用于请求访问已经被 URI （统一资源标识符） 识别的资源，可以通过 URL 传参给服务器

• POST：用于传输信息给服务器，主要功能与 GET 方法类似，但一般推荐使用POST方式。

• PUT：传输文件，报文主体中包含文件内容，保存到对应 URI 位置。

• HEAD：获得报文首部，与 GET 方法类似，只是不返回报文主体，一般用于验证 URI 是否有效。

• DELETE：删除文件，与 PUT 方法相反，删除对应 URI 位置的文件。

• OPTIONS：查询相应 URI 支持的 HTTP 方法。

---

17）常见HTTP状态码

答：

1、1xx （临时响应）

2、2xx （成功）

3、3xx （重定向） ：表示要完成请求需要进一步操作

4、4xx （错误） ：表示请求可能出错，妨碍了服务器的处理

5、5xx （服务器错误） ：表示服务器在尝试处理请求时发生内部错误

6、常见状态码：

• 200 （成功）
• 304 （未修改） ：自从上次请求后，请求的网页未修改过。服务器返回此响应时，不会返回网页内容
• 401 （未授权） ：请求要求身份验证
• 403 （禁止） ：服务器拒绝请求
• 404 （未找到） ：服务器找不到请求的网页

---

18）SQL 注入

答：

SQL 注入就是通过把 SQL 命令插入到 Web 表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的 SQL 命令。

(1).SQL 注入攻击的总体思路：

1、寻找到 SQL 注入的位置

2、判断服务器类型和后台数据库类型

3、针对不通的服务器和数据库特点进行 SQL 注入攻击

(2). SQL注入攻击实例：

比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --
密 码：

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?下面我们分析一下：从理论上说，后台认证程序中会有如下的 SQL 语句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，当输入了上面的用户名和密码，上面的 SQL 语句变成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’

分析上述 SQL 语句我们知道，username=‘ or 1=1 这个语句一定会成功；然后后面加两个-，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

(3). 应对方法：

1.参数绑定：

使用预编译手段，绑定参数是最好的防 SQL 注入的方法。目前许多的 ORM 框架及 JDBC 等都实现了 SQL 预编译和参数绑定功能，攻击者的恶意 SQL 会被当做 SQL 的参数而不是 SQL 命令被执行。在 mybatis 的 mapper 文件中，对于传递的参数我们一般是使用#和

不能识别此Latex公式:
来获取参数值。当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所有可以防止sql注入；当使用

时，变量就是直接追加在 sql 中，一般会有 sql 注入问题。

2.使用正则表达式过滤传入的参数

---

19）XSS 攻击

答：

XSS 是一种经常出现在 web 应用中的计算机安全漏洞，与 SQL 注入一起成为 web 中最主流的攻击方式。XSS 是指恶意攻击者利用网站没有对用户提交数据进行转义处理或者过滤不足的缺点，进而添加一些脚本代码嵌入到 web 页面中去，使别的用户访问都会执行相应的嵌入代码，从而盗取用户资料、利用用户身份进行某种动作或者对访问者进行病毒侵害的一种攻击方式。

(1). XSS 攻击的危害：

•  盗取各类用户帐号，如机器登录帐号、用户网银帐号、各类管理员帐号

• 控制企业数据，包括读取、篡改、添加、删除企业敏感数据的能力

• 盗窃企业重要的具有商业价值的资料

• 非法转账

• 强制发送电子邮件

• 网站挂马

• 控制受害者机器向其它网站发起攻击

(2). 原因解析：

• 主要原因：过于信任客户端提交的数据！

• 解决办法：不信任任何客户端提交的数据，只要是客户端提交的数据就应该先进行相应的过滤处理然后方可进行下一步的操作。

• 进一步分析细节：客户端提交的数据本来就是应用所需要的，但是恶意攻击者利用网站对客户端提交数据的信任，在数据中插入一些符号以及javascript代码，那么这些数据将会成为应用代码中的一部分了，那么攻击者就可以肆无忌惮地展开攻击啦，因此我们绝不可以信任任何客户端提交的数据！！！

(3). XSS 攻击分类：

• 1. 反射性 XSS 攻击 （非持久性 XSS 攻击） ：

漏洞产生的原因是攻击者注入的数据反映在响应中。一个典型的非持久性 XSS 攻击包含一个带 XSS 攻击向量的链接 (即每次攻击需要用户的点击) ，例如，正常发送消息：

http://www.test.com/message.php?send=Hello,World！

接收者将会接收信息并显示 Hello,World；但是，非正常发送消息：

http://www.test.com/message.php?send=<script>alert(‘foolish!’)script>！

接收者接收消息显示的时候将会弹出警告窗口！

•   2. 持久性 XSS 攻击 (留言板场景) ：

XSS 攻击向量 (一般指 XSS 攻击代码) 存储在网站数据库，当一个页面被用户打开的时候执行。也就是说，每当用户使用浏览器打开指定页面时，脚本便执行。与非持久性 XSS 攻击相比，持久性 XSS 攻击危害性更大。从名字就可以了解到，持久性 XSS 攻击就是将攻击代码存入数据库中，然后客户端打开时就执行这些攻击代码。

例如，留言板表单中的表单域：

<input type=“text” name=“content” value=“这里是用户填写的数据”>

正常操作流程是：用户是提交相应留言信息 —— 将数据存储到数据库 —— 其他用户访问留言板，应用去数据并显示；而非正常操作流程是攻击者在 value 填写:

<script>alert(‘foolish!’)；script> 

并将数据提交、存储到数据库中；当其他用户取出数据显示的时候，将会执行这些攻击性代码。

(4). 修复漏洞方针：

漏洞产生的根本原因是 太相信用户提交的数据，对用户所提交的数据过滤不足所导致的，因此解决方案也应该从这个方面入手，具体方案包括：

• 将重要的cookie标记为http only, 这样的话Javascript 中的 document.cookie 语句就不能获取到 cookie 了 （如果在 cookie 中设置了 HttpOnly 属性，那么通过js脚本将无法读取到 cookie 信息，这样能有效的防止 XSS 攻击） ；

• 表单数据规定值的类型，例如：年龄应为只能为 int、name 只能为字母数字组合

•