最近讀了一本書《圖解HTTP》，讀完后在大體上對HTTP協議有了更深層次的了解，以下是我以前不懂的問題，通過閱讀此書后，這些問題都有了答案：
問題：
-
URI和URL的區別？
-
cookie到底是什么？有什么用？為什么要有？
-
為什么下載時可以隨時停止，隨時繼續下載？
-
什么是內容協商機制？
-
Http協議中回應頭的vary欄位到底是什么意思？
-
最近讀了一本書《圖解HTTP》，讀完后在大體上對HTTP協議有了更深層次的了解，以下是我以前不懂的問題，通過閱讀此書后，這些問題都有了答案：
問題：
- URI和URL的區別？
- cookie到底是什么？有什么用？為什么要有？
- 為什么下載時可以隨時停止，隨時繼續下載？
- 什么是內容協商機制？
- Http協議中回應頭的vary欄位到底是什么意思？
- Cookie的path屬性和domain屬性究竟是什么？
- 為什么要有HTTPS？它與HTTP的區別在哪？
- 什么是SSL和TSL？
- HTTPS的混合加密機制+證書是怎樣的？
- 什么是WebSocket？為什么要有WebSocket？
- 什么是XSS攻擊、CSRF攻擊？
以下是我對問題的理解以及總結上了其他人的理解，
問題：URI和URL的區別？
首先要明確一點，在網路上的所有資源都需要被定位，且它們都會有名稱，這樣才能按需獲取這些資源，
URI就是這些資源的名稱，而URL就是這些資源的位置，但有時候資源的名稱中如果包含了位置，那么此時URI就和URL一樣了，
因此可以看出URL是URI的子集，當URI中包含了資源位置，那URI就等同于URL，
問題：cookie到底是什么？有什么用？為什么要有？
HTTP協議是無狀態協議，也就是說協議不會去保存用戶的狀態，那么在這個情況下假設Web網站是需要登陸的，而進行頁面跳轉之后，用戶的狀態也就消失了，需要重新登陸一次，去獲取用戶狀態，即進行一次頁面跳轉，就要登陸一次，這樣是很繁瑣的，
要解決這種問題，就是把用戶狀態進行保存，而用戶狀態保存到Web服務器也是不現實的，因為當出現很多個用戶狀態時會對Web服務器造成存盤上的負擔，所以用戶狀態必須保存到客戶端上，因為客戶端和服務器的關系是一對多，每個客戶端只需要保存一個份用戶狀態，這樣就能提高Web服務器的存盤性能，
所以有了Cookie，使用Cookie，可以把用戶狀態存盤到客戶端上，客戶端每次向服務器發送請求時都會帶上Cookie，因此在服務器上只需要對這個Cookie的內容進行校驗即可，
Cookie通常會搭配Session一起使用，可以維持客戶端與服務器之間的通信，只需要把SessionID通過Cookie發送給客戶端，然后客戶端每次請求服務器時，都通過Cookie把SessionID發給服務器，服務器對SeesionId進行校驗，這樣就能維持客戶端和服務器之間的通信了，
問題：為什么下載時可以隨時停止，隨時繼續下載？
首先，資源在服務器上是以位元組來進行存盤的，本質上一份資源就是多個0和1的組合，因此下載資源也就是復制這一份0和1的組合，
所以下載時停止了，那么也就是往客戶端的磁盤上寫這個01組合的動作被停止了，如果此時想要繼續下載，就必須得知道這個01組合寫到哪了，客戶端需要從哪開始繼續寫01組合，也就是說客戶端必須要告訴服務器一個范圍，從這個范圍開始繼續把資源復制給客戶端，
因此有了range欄位，客戶端在發送請求時，往請求頭上設定range欄位，就能設定這個范圍，
問題：什么是內容協商機制？
在單機情況下，一份資源通常只會有一個版本，但是對于一個多語言應用程式，可能需要為每種語言版本單獨創建一個檔案，這些檔案可能會被分別存盤在單機中的不同位置上，這樣在使用時可以根據用戶選擇的語言版本來讀取相應的檔案，因此，可以說在單機情況下，一份多語言資源可能會有多個語言版本，
而在分布式系統中，同一份資源的不同版本可能存盤在不同的服務器上，由不同的服務器提供服務，這些服務器之間可以通過負載均衡或者其他技術來實作對用戶請求的處理，因此，不同國家的用戶請求的資源版本可能來自不同的服務器，
無論在單機情況下還是分布式系統中都存在一個問題： 客戶端怎么決定要使用哪一個版本的資源呢？
HTTP的內容協商機制很好的解決了這問題，內容協商機制是指：某一資源，服務器有多個版本，客戶端告知服務器自己的偏好，服務器根據偏好選擇合適的版本回應客戶端的請求，
在內容協商機制中有以下三種方法來決定使用哪個版本資源：
- 客戶端驅動協商（讓客戶端來選擇）： 客戶端發起請求，服務器發送資源的可選項串列，客戶端作出選擇后再發送第二次請求，
- 服務器驅動協商（讓服務器來選擇）： 客戶端發送請求時把需要哪個版本的資源通過請求頭發送給服務器，讓服務器來決定使用哪個版本的資源，
- 透明協商（讓中間代理來選擇）： 使用某個中間設備（通常是快取代理）來代表客戶端進行協商，可以說是客戶端驅動協商的變種，
問題：Http協議中回應頭的vary欄位到底是什么意思？
假設整個請求程序是這樣的：客戶端 -> 代理服務器（具備快取功能） ->web服務器，
第一個支持gzip壓縮的客戶端向中間代理服務器發送請求，代理服務器轉發該請求，向web服務器拉取內容，拿到內容后代理服務器快取該內容（由于請求首部有Accept-Encoding: gzip 所以內容會被壓縮），
第二個不支持gzip壓縮的客戶端也向中間代理服務器發送同一個請求，代理服務器發現該請求已經被快取了，于是就把壓縮后的內容回應給該客戶端，悲劇了，因為該客戶端根本不支持gzip壓縮，也就沒法解壓，
這種問題出現在透明協商機制中，問題的根源就在于代理把同一份資源回應給了不同的客戶端，而客戶端對份資源是有不同版本的要求的，
為了解決這個問題，于是有了vary欄位,vary欄位用于列出一個回應欄位串列，告訴快取服務器遇到同一個 URL 對應著不同版本檔案的情況時，如何快取和篩選合適的版本，
有了vary欄位之后，代理快取可以為通過單個URL訪問的檔案保存不同的副本，如果服務器把它們的決策程序傳給快取，這些代理就能代表服務器與客戶端進行協商，快取同時也是進行內容轉碼的好地方，因為部署在快取里的通用轉碼器能對任意服務器，而不僅僅是一臺服務器傳來的內容進行轉碼，
更加詳細的介紹可以看這篇文章：https://codeleading.com/article/90534722641/
問題：Cookie的path屬性和domain屬性究竟是什么？
cookie一定會隨著客戶端發送的請求而到達服務器，而服務器上可能會出現多個域名的情況（服務器有多個域名的情況通常是因為同一個應用程式需要提供不同的服務或介面），那么就有個問題： cookie一定要被服務器的所有域名識別嗎？我想讓某些域名不能識別這個cookie那怎么辦？
于是有了domain屬性，domain屬性用于用于指定哪些域名可以接受該Cookie，具體來說，如果設定了該屬性，則只有在該屬性值所指定的域名及其子域名下發送請求時，瀏覽器才會將該Cookie發送給服務器，
舉個例子，假設我們有一個名為“example.com”的域名，并且在其上設定了一個Cookie，domain屬性值為“example.com”，此時，無論是在"ohj.example.com"子域名下，還是在“blog.example.com”子域名下，當瀏覽器發送請求時，都會將該Cookie附加在請求頭中發送給服務器，但如果發送請求的域名為“test.com”，則瀏覽器不會發送該Cookie，
需要注意的是，domain屬性的值必須是當前域名或其子域名，否則瀏覽器不會發送該Cookie，同時，該屬性值不能包含協議名和埠號，
現在Cookie發送到服務器的指定域名了，但是又有一個問題： 這個域名上的所有路徑都要使用這個cookie嗎？某些路徑不想使用怎么辦？
于是有了path屬性，使用path屬性可以指定Cookie可以被哪些路徑使用，舉個例子，cookie的path屬性的值為/head，那么路徑為/head/ohj/、/head/xxx/都能使用到這個cookie，而/abc/test/路徑都不能使用到這個cookie，
即cookie只會發往path屬性指定的路徑，只有path屬性的路徑與請求URL路徑一致時，cookie才會發送給服務器，
總結： domain屬性用于控制cookie能夠發送給哪些域名，path屬性用于控制cookie在服務器上哪些路徑可以訪問，
問題：為什么要有HTTPS？它與HTTP的區別在哪？
首先，HTTP協議是存在安全隱患的，HTTP傳輸內容時，都是明文傳輸，存在被竊聽風險，而HTTP的內容也有可能被修改，
于是有了HTTPS，HTTP+加密+認證+完整性保護=HTTPS，因此使用HTTPS能夠防止竊聽和篡改的風險，
問題：什么是SSL和TSL？
SSL（安全套接層）和TSL（傳輸層安全協議）是用于保護網路通信安全的協議，TLS是SSL的繼任者，它們的作用是在應用層和傳輸層之間提供一層安全協議，保護通信程序中的機密性、完整性和可靠性，
問題：HTTPS的混合加密機制+證書是怎樣的？
先了解一下共享密鑰加密和公開密鑰加密，
共享密鑰加密： 使用一對完全一樣的公鑰來對資料進行加密解密，因此稱為共享密鑰加密，假設有個服務器A，服務器A用公鑰加密內容，然后發送給服務器B，服務器B用另一把相同的公鑰進行解密，
公開密鑰加密： 使用一個非對稱的公鑰來對資料進行加密解密，一個密鑰叫公開密鑰，用于到處分享；一個密鑰叫私有密鑰，用于解密資料，不會到處分享，假設有個服務A，它先把公開密鑰發給服務器B，然后服務器B用公開密鑰加密內容，然后發送給服務器A，服務器A用私有密鑰進行解密，
在HTTPS協議中使用的是混合密鑰加密，也就是把共享密鑰加密和公開密鑰加密結合結合在一起，
- 公開密鑰加密通常只用于在建立連接時對客戶端和服務器之間的通信進行加密，（也就是用公開密鑰加密來確保共享密鑰能夠安全傳輸到客戶端，）
- 共享密鑰對后續的請求和回應進行加密和解密，這種方式也被稱為對稱密鑰加密，
到此，有個問題：客戶端怎么知道這個公開密鑰就是服務器發來的呢？
為了解決這個問題，必須依賴第三方機構，于是有了證書，使用證書，可以確保這個公開密鑰就是服務器發來的，
在我的理解中使用HTTPS的客戶端和服務器之間是這樣從連接-通信的：
- 服務器先把自己的公開密鑰在數字證書認證機構中登記，然后獲取公鑰證書，
- 服務器把認證過的公開密鑰和證書發給客戶端
- 客戶端使用瀏覽器內置的資料證書認證機構的公開密鑰對證書進行認證，認證通過后證明確實是服務器的公開密鑰，
- 客戶端用這個公開密鑰對客戶端生成的共享密鑰進行加密，然后發送給服務器，
- 服務器用自己的私有密鑰進行解密，得到客戶端發送的共享密鑰，
- 之后服務器和客戶端的通信就只用共享密鑰進行加密，
問題：什么是WebSocket？為什么要有WebSocket？
在HTTP協議中有以下缺點：
- 一次連接只能發送一個請求，
- 請求只能從客戶端開始，客戶端不可以接受除回應意外的指令，也就是服務器不能主動發送回應到客戶端，
- 每次請求都會傳輸完整的請求頭，且請求頭都沒有壓縮過，請求頭資訊越多延遲越大，
為了彌補HTTP的缺點，于是有了WebSocket，WebSocket是一種在單個TCP連接上提供全雙工通信的協議，通過這種協議，Web應用程式可以建立與服務器的持久性連接，實作實時通信和資料傳輸，
WebSocket協議是在HTTP協議的基礎上進行升級得到的，在初始連接建立時，客戶端會發送一份HTTP協議的請求，該請求中包含升級為WebSocket協議的要求，如果服務器同意升級，則接下來的通信將采用WebSocket協議進行，這時候HTTP協議就不再使用了，因此，WebSocket協議也被稱為HTTP協議的升級版或擴展版，
問題：什么是XSS攻擊、CSRF攻擊？
XSS（跨站腳本攻擊）：攻擊者通過注入惡意腳本代碼到受害者訪問的網頁上，從而獲取受害者的敏感資訊或者執行惡意操作的一種攻擊方式，XSS攻擊分為存盤型、反射型和DOM型三種形式， XSS攻擊的共同點為：將一些隱私資料像 cookie、session 發送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作，
CSRF（跨站請求偽造）：攻擊者通過偽造合法的請求來欺騙用戶執行操作的一種攻擊方式，攻擊者可以利用用戶已經登錄的身份，向服務器發送請求來執行一些惡意操作，例如，攻擊者可以通過偽造提交表單的請求來更改受害者的賬戶資訊，CSRF攻擊是攻擊者借助受害者的 Cookie 騙取服務器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請求發送給受攻擊服務器，從而在并未授權的情況下執行在權限保護之下的操作，
-
Cookie的path屬性和domain屬性究竟是什么？
-
為什么要有HTTPS？它與HTTP的區別在哪？
-
什么是SSL和TSL？
-
HTTPS的混合加密機制+證書是怎樣的？
-
什么是WebSocket？為什么要有WebSocket？
-
什么是XSS攻擊、CSRF攻擊？
以下是我對問題的理解以及總結上了其他人的理解，
問題：URI和URL的區別？
首先要明確一點，在網路上的所有資源都需要被定位，且它們都會有名稱，這樣才能按需獲取這些資源，
URI就是這些資源的名稱，而URL就是這些資源的位置，但有時候資源的名稱中如果包含了位置，那么此時URI就和URL一樣了，
因此可以看出URL是URI的子集，當URI中包含了資源位置，那URI就等同于URL，
問題：cookie到底是什么？有什么用？為什么要有？
HTTP協議是無狀態協議，也就是說協議不會去保存用戶的狀態，那么在這個情況下假設Web網站是需要登陸的，而進行頁面跳轉之后，用戶的狀態也就消失了，需要重新登陸一次，去獲取用戶狀態，即進行一次頁面跳轉，就要登陸一次，這樣是很繁瑣的，
要解決這種問題，就是把用戶狀態進行保存，而用戶狀態保存到Web服務器也是不現實的，因為當出現很多個用戶狀態時會對Web服務器造成存盤上的負擔，所以用戶狀態必須保存到客戶端上，因為客戶端和服務器的關系是一對多，每個客戶端只需要保存一個份用戶狀態，這樣就能提高Web服務器的存盤性能，
所以有了Cookie，使用Cookie，可以把用戶狀態存盤到客戶端上，客戶端每次向服務器發送請求時都會帶上Cookie，因此在服務器上只需要對這個Cookie的內容進行校驗即可，
Cookie通常會搭配Session一起使用，可以維持客戶端與服務器之間的通信，只需要把SessionID通過Cookie發送給客戶端，然后客戶端每次請求服務器時，都通過Cookie把SessionID發給服務器，服務器對SeesionId進行校驗，這樣就能維持客戶端和服務器之間的通信了，
問題：為什么下載時可以隨時停止，隨時繼續下載？
首先，資源在服務器上是以位元組來進行存盤的，本質上一份資源就是多個0和1的組合，因此下載資源也就是復制這一份0和1的組合，
所以下載時停止了，那么也就是往客戶端的磁盤上寫這個01組合的動作被停止了，如果此時想要繼續下載，就必須得知道這個01組合寫到哪了，客戶端需要從哪開始繼續寫01組合，也就是說客戶端必須要告訴服務器一個范圍，從這個范圍開始繼續把資源復制給客戶端，
因此有了range欄位，客戶端在發送請求時，往請求頭上設定range欄位，就能設定這個范圍，
問題：什么是內容協商機制？
在單機情況下，一份資源通常只會有一個版本，但是對于一個多語言應用程式，可能需要為每種語言版本單獨創建一個檔案，這些檔案可能會被分別存盤在單機中的不同位置上，這樣在使用時可以根據用戶選擇的語言版本來讀取相應的檔案，因此，可以說在單機情況下，一份多語言資源可能會有多個語言版本，
而在分布式系統中，同一份資源的不同版本可能存盤在不同的服務器上，由不同的服務器提供服務，這些服務器之間可以通過負載均衡或者其他技術來實作對用戶請求的處理，因此，不同國家的用戶請求的資源版本可能來自不同的服務器，
無論在單機情況下還是分布式系統中都存在一個問題： 客戶端怎么決定要使用哪一個版本的資源呢？
HTTP的內容協商機制很好的解決了這問題，內容協商機制是指：某一資源，服務器有多個版本，客戶端告知服務器自己的偏好，服務器根據偏好選擇合適的版本回應客戶端的請求，
在內容協商機制中有以下三種方法來決定使用哪個版本資源：
- 客戶端驅動協商（讓客戶端來選擇）： 客戶端發起請求，服務器發送資源的可選項串列，客戶端作出選擇后再發送第二次請求，
- 服務器驅動協商（讓服務器來選擇）： 客戶端發送請求時把需要哪個版本的資源通過請求頭發送給服務器，讓服務器來決定使用哪個版本的資源，
- 透明協商（讓中間代理來選擇）： 使用某個中間設備（通常是快取代理）來代表客戶端進行協商，可以說是客戶端驅動協商的變種，
問題：Http協議中回應頭的vary欄位到底是什么意思？
假設整個請求程序是這樣的：客戶端 -> 代理服務器（具備快取功能） ->web服務器，
第一個支持gzip壓縮的客戶端向中間代理服務器發送請求，代理服務器轉發該請求，向web服務器拉取內容，拿到內容后代理服務器快取該內容（由于請求首部有Accept-Encoding: gzip 所以內容會被壓縮），
第二個不支持gzip壓縮的客戶端也向中間代理服務器發送同一個請求，代理服務器發現該請求已經被快取了，于是就把壓縮后的內容回應給該客戶端，悲劇了，因為該客戶端根本不支持gzip壓縮，也就沒法解壓，
這種問題出現在透明協商機制中，問題的根源就在于代理把同一份資源回應給了不同的客戶端，而客戶端對份資源是有不同版本的要求的，
為了解決這個問題，于是有了vary欄位,vary欄位用于列出一個回應欄位串列，告訴快取服務器遇到同一個 URL 對應著不同版本檔案的情況時，如何快取和篩選合適的版本，
有了vary欄位之后，代理快取可以為通過單個URL訪問的檔案保存不同的副本，如果服務器把它們的決策程序傳給快取，這些代理就能代表服務器與客戶端進行協商，快取同時也是進行內容轉碼的好地方，因為部署在快取里的通用轉碼器能對任意服務器，而不僅僅是一臺服務器傳來的內容進行轉碼，
問題：Cookie的path屬性和domain屬性究竟是什么？
cookie一定會隨著客戶端發送的請求而到達服務器，而服務器上可能會出現多個域名的情況（服務器有多個域名的情況通常是因為同一個應用程式需要提供不同的服務或介面），那么就有個問題： cookie一定要被服務器的所有域名識別嗎？我想讓某些域名不能識別這個cookie那怎么辦？
于是有了domain屬性，domain屬性用于用于指定哪些域名可以接受該Cookie，具體來說，如果設定了該屬性，則只有在該屬性值所指定的域名及其子域名下發送請求時，瀏覽器才會將該Cookie發送給服務器，
舉個例子，假設我們有一個名為“example.com”的域名，并且在其上設定了一個Cookie，domain屬性值為“example.com”，此時，無論是在"ohj.example.com"子域名下，還是在“blog.example.com”子域名下，當瀏覽器發送請求時，都會將該Cookie附加在請求頭中發送給服務器，但如果發送請求的域名為“test.com”，則瀏覽器不會發送該Cookie，
需要注意的是，domain屬性的值必須是當前域名或其子域名，否則瀏覽器不會發送該Cookie，同時，該屬性值不能包含協議名和埠號，
現在Cookie發送到服務器的指定域名了，但是又有一個問題： 這個域名上的所有路徑都要使用這個cookie嗎？某些路徑不想使用怎么辦？
于是有了path屬性，使用path屬性可以指定Cookie可以被哪些路徑使用，
舉個例子，cookie的path屬性的值為/head，那么路徑為/head/ohj/、/head/xxx/都能使用到這個cookie，而/abc/test/路徑都不能使用到這個cookie，
即cookie只會發往path屬性指定的路徑，只有path屬性的路徑與請求URL路徑一致時，cookie才會發送給服務器，
總結： domain屬性用于控制cookie能夠發送給哪些域名，path屬性用于控制cookie在服務器上哪些路徑可以訪問，
問題：為什么要有HTTPS？它與HTTP的區別在哪？
首先，HTTP協議是存在安全隱患的，HTTP傳輸內容時，都是明文傳輸，存在被竊聽風險，而HTTP的內容也有可能被修改，
于是有了HTTPS，HTTP+加密+認證+完整性保護=HTTPS，因此使用HTTPS能夠防止竊聽和篡改的風險，
問題：什么是SSL和TSL？
SSL（安全套接層）和TSL（傳輸層安全協議）是用于保護網路通信安全的協議，TLS是SSL的繼任者，它們的作用是在應用層和傳輸層之間提供一層安全協議，保護通信程序中的機密性、完整性和可靠性，
問題：HTTPS的混合加密機制+證書是怎樣的？
先了解一下共享密鑰加密和公開密鑰加密，
共享密鑰加密： 使用一對完全一樣的公鑰來對資料進行加密解密，因此稱為共享密鑰加密，假設有個服務器A，服務器A用公鑰加密內容，然后發送給服務器B，服務器B用另一把相同的公鑰進行解密，
公開密鑰加密： 使用一個非對稱的公鑰來對資料進行加密解密，一個密鑰叫公開密鑰，用于到處分享；一個密鑰叫私有密鑰，用于解密資料，不會到處分享，假設有個服務A，它先把公開密鑰發給服務器B，然后服務器B用公開密鑰加密內容，然后發送給服務器A，服務器A用私有密鑰進行解密，
在HTTPS協議中使用的是混合密鑰加密，也就是把共享密鑰加密和公開密鑰加密結合結合在一起，
- 公開密鑰加密通常只用于在建立連接時對客戶端和服務器之間的通信進行加密，（也就是用公開密鑰加密來確保共享密鑰能夠安全傳輸到客戶端，）
- 共享密鑰對后續的請求和回應進行加密和解密，這種方式也被稱為對稱密鑰加密，
到此，有個問題：客戶端怎么知道這個公開密鑰就是服務器發來的呢？
為了解決這個問題，必須依賴第三方機構，于是有了證書，使用證書，可以確保這個公開密鑰就是服務器發來的，
在我的理解中使用HTTPS的客戶端和服務器之間是這樣從連接-通信的：
- 服務器先把自己的公開密鑰在數字證書認證機構中登記，然后獲取公鑰證書，
- 服務器把認證過的公開密鑰和證書發給客戶端
- 客戶端使用瀏覽器內置的資料證書認證機構的公開密鑰對證書進行認證，認證通過后證明確實是服務器的公開密鑰，
- 客戶端用這個公開密鑰對客戶端生成的共享密鑰進行加密，然后發送給服務器，
- 服務器用自己的私有密鑰進行解密，得到客戶端發送的共享密鑰，
- 之后服務器和客戶端的通信就只用共享密鑰進行加密，
問題：什么是WebSocket？為什么要有WebSocket？
在HTTP協議中有以下缺點：
- 一次連接只能發送一個請求，
- 請求只能從客戶端開始，客戶端不可以接受除回應意外的指令，也就是服務器不能主動發送回應到客戶端，
- 每次請求都會傳輸完整的請求頭，且請求頭都沒有壓縮過，請求頭資訊越多延遲越大，
為了彌補HTTP的缺點，于是有了WebSocket，WebSocket是一種在單個TCP連接上提供全雙工通信的協議，通過這種協議，Web應用程式可以建立與服務器的持久性連接，實作實時通信和資料傳輸，
WebSocket協議是在HTTP協議的基礎上進行升級得到的，在初始連接建立時，客戶端會發送一份HTTP協議的請求，該請求中包含升級為WebSocket協議的要求，如果服務器同意升級，則接下來的通信將采用WebSocket協議進行，這時候HTTP協議就不再使用了，因此，WebSocket協議也被稱為HTTP協議的升級版或擴展版，
問題：什么是XSS攻擊、CSRF攻擊？
XSS（跨站腳本攻擊）：攻擊者通過注入惡意腳本代碼到受害者訪問的網頁上，從而獲取受害者的敏感資訊或者執行惡意操作的一種攻擊方式，XSS攻擊分為存盤型、反射型和DOM型三種形式， XSS攻擊的共同點為：將一些隱私資料像 cookie、session 發送給攻擊者，將受害者重定向到一個由攻擊者控制的網站，在受害者的機器上進行一些惡意操作，
CSRF（跨站請求偽造）：攻擊者通過偽造合法的請求來欺騙用戶執行操作的一種攻擊方式，攻擊者可以利用用戶已經登錄的身份，向服務器發送請求來執行一些惡意操作，例如，攻擊者可以通過偽造提交表單的請求來更改受害者的賬戶資訊，CSRF攻擊是攻擊者借助受害者的 Cookie 騙取服務器的信任，可以在受害者毫不知情的情況下以受害者名義偽造請求發送給受攻擊服務器，從而在并未授權的情況下執行在權限保護之下的操作，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/551831.html
標籤：其他
上一篇：網站被攻擊了！！！！！！
下一篇：返回列表