（一）網絡基礎知識
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 碼錶示為：
服務端在接收到該數據後就可以遍歷該字節流，一個字節一個字節的吃，當吃到 3D 這字節後，服務端就知道前面吃得字節表示一個 key，再往後吃，如果遇到 26，說明從剛才吃的 3D 到 26 子節之間的是上一個 key 的 value，以此類推就可以解析出客戶端傳過來的參數。6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
6E616D6531：name1
3D：=
76616C756531：value1
26：&
6E616D6532：name2
3D：=
76616C756532：value2
現在考慮這樣一個問題，如果我們的參數值中就包含=或&這種特殊字符的時候該怎麼辦？比如，“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注入攻擊實例：
比如，在一個登錄界面，要求輸入用戶名和密碼，可以這樣輸入實現免帳號登錄：
用戶一旦點擊登錄，如若沒有做特殊處理，那麼這個非法用戶就很得意的登陸進去了。這是為什麼呢?下面我們分析一下：從理論上說，後臺認證程序中會有如下的 SQL 語句：<code>String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;/<code>因此，當輸入了上面的用戶名和密碼，上面的 SQL 語句變成：<code>SELECT * FROM user_table WHERE username=’’or 1 = 1 – and password=’’/<code>分析上述 SQL 語句我們知道，username=‘ or 1=1 這個語句一定會成功；然後後面加兩個-，這意味著註釋，它將後面的語句註釋，讓他們不起作用。這樣，上述語句永遠都能正確執行，用戶輕易騙過系統，獲取合法身份。用戶名： ‘or 1 = 1 --
密 碼：
(3). 應對方法：
1.參數綁定：
使用預編譯手段，綁定參數是最好的防 SQL 注入的方法。目前許多的 ORM 框架及 JDBC 等都實現了 SQL 預編譯和參數綁定功能，攻擊者的惡意 SQL 會被當做 SQL 的參數而不是 SQL 命令被執行。在 mybatis 的 mapper 文件中，對於傳遞的參數我們一般是使用#和
時，變量就是直接追加在 sql 中，一般會有 sql 注入問題。不能識別此Latex公式:
來獲取參數值。當使用#時，變量是佔位符，就是一般我們使用javajdbc的PrepareStatement時的佔位符，所有可以防止sql注入；當使用
2.使用正則表達式過濾傳入的參數
19）XSS 攻擊
答：XSS 是一種經常出現在 web 應用中的計算機安全漏洞，與 SQL 注入一起成為 web 中最主流的攻擊方式。XSS 是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些腳本代碼嵌入到 web 頁面中去，使別的用戶訪問都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動作或者對訪問者進行病毒侵害的一種攻擊方式。
(1). XSS 攻擊的危害：
• 盜取各類用戶帳號，如機器登錄帳號、用戶網銀帳號、各類管理員帳號• 控制企業數據，包括讀取、篡改、添加、刪除企業敏感數據的能力• 盜竊企業重要的具有商業價值的資料• 非法轉賬• 強制發送電子郵件• 網站掛馬• 控制受害者機器向其它網站發起攻擊 (2). 原因解析：
• 主要原因：過於信任客戶端提交的數據！• 解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理然後方可進行下一步的操作。• 進一步分析細節：客戶端提交的數據本來就是應用所需要的，但是惡意攻擊者利用網站對客戶端提交數據的信任，在數據中插入一些符號以及javascript代碼，那麼這些數據將會成為應用代碼中的一部分了，那麼攻擊者就可以肆無忌憚地展開攻擊啦，因此我們絕不可以信任任何客戶端提交的數據！！！
(3). XSS 攻擊分類：
• 1. 反射性 XSS 攻擊（非持久性 XSS 攻擊）：
漏洞產生的原因是攻擊者注入的數據反映在響應中。一個典型的非持久性 XSS 攻擊包含一個帶 XSS 攻擊向量的鏈接(即每次攻擊需要用戶的點擊)，例如，正常發送消息：
接收者將會接收信息並顯示 Hello,World；但是，非正常發送消息：http://www.test.com/message.php?send=Hello,World！
http://www.test.com/message.php?send=<script>alert(‘foolish!’)script>！
接收者接收消息顯示的時候將會彈出警告窗口！
• 2. 持久性 XSS 攻擊 (留言板場景)：
XSS 攻擊向量(一般指 XSS 攻擊代碼)存儲在網站數據庫，當一個頁面被用戶打開的時候執行。也就是說，每當用戶使用瀏覽器打開指定頁面時，腳本便執行。與非持久性 XSS 攻擊相比，持久性 XSS 攻擊危害性更大。從名字就可以瞭解到，持久性 XSS 攻擊就是將攻擊代碼存入數據庫中，然後客戶端打開時就執行這些攻擊代碼。
例如，留言板表單中的表單域：
正常操作流程是：用戶是提交相應留言信息 —— 將數據存儲到數據庫 —— 其他用戶訪問留言板，應用去數據並顯示；而非正常操作流程是攻擊者在 value 填寫:<input type=“text” name=“content” value=“這裡是用戶填寫的數據”>
並將數據提交、存儲到數據庫中；當其他用戶取出數據顯示的時候，將會執行這些攻擊性代碼。<script>alert(‘foolish!’)；script>
(4). 修復漏洞方針：
漏洞產生的根本原因是 太相信用戶提交的數據，對用戶所提交的數據過濾不足所導致的，因此解決方案也應該從這個方面入手，具體方案包括：
• 將重要的cookie標記為http only, 這樣的話Javascript 中的 document.cookie 語句就不能獲取到 cookie 了（如果在 cookie 中設置了 HttpOnly 屬性，那麼通過js腳本將無法讀取到 cookie 信息，這樣能有效的防止 XSS 攻擊）；• 表單數據規定值的類型，例如：年齡應為只能為 int、name 只能為字母數字組合• 對數據進行Html Encode 處理• 過濾或移除特殊的Html標籤，例如:
分享到:
閱讀更多 鮑家大少 的文章
