http介紹及網路安全
Http
http在網路傳輸中的作用
![此處輸入圖片的描述][1]
http（超文字傳輸協議）是一個基於請求與響應模式的、無狀態的、應用層的協議，常基於TCP的連線方式，HTTP1.1版本中給出一種持續連線的機制，絕大多數的Web開發，都是構建在HTTP協議之上的Web應用.
http是建立在傳輸層tcp上的 （三次握手，四次揮手）
1.三次握手
第一次握手：建立連線時，客戶端A傳送SYN包(SYN=j)到伺服器B，並進入SYN_SEND狀態，等待伺服器B確認。
第二次握手：伺服器B收到SYN包，必須確認客戶A的SYN(ACK=j+1)，同時自己也傳送一個SYN包(SYN=k)，即SYN+ACK包，此時伺服器B進入SYN_RECV狀態。
第三次握手：客戶端A收到伺服器B的SYN＋ACK包，向伺服器B傳送確認包ACK(ACK=k+1)，此包傳送完畢，客戶端A和伺服器B進入ESTABLISHED狀態，完成三次握手。
2.四次揮手
1）客戶端A傳送一個FIN，用來關閉客戶A到伺服器B的資料傳送。
2）伺服器B收到這個FIN，它發回一個ACK，確認序號為收到的序號加1(報文段5)。和SYN一樣，一個FIN將佔用一個序號。
3）伺服器B關閉與客戶端A的連線，傳送一個FIN給客戶端A。
4）客戶端A發回ACK報文確認，並將確認序號設定為收到序號加1。
一，http中的url
http://user:[email protected]:80/dir/index.html?uid=1#ch1
1.http://,”:”號之前的http 可以是ftp https 等協議名，不區分字母大小寫。
2.user:pass,指定使用者名稱和密碼作為服務端獲取的登入資訊(可選項)
3.www.example.jp，伺服器地址，地址可以是 haxckr.xxx這種DNS可解析的名稱，或者是 192.168.1.1這類IPV4的地址名，還可以是[0:0:0:0:0:0:0:1]這種方括號括起來的IPv6的地址名。
4.:80,伺服器埠號。可選項，HTTP協議代理伺服器常用埠號：80/8080/3128/8081/9080
5./dir/index.html，指定伺服器上的檔案路徑來定位特定的資源。
6.?uid=1,查詢字串引數，多個用&隔開(可選項)、
7.#ch1，片段識別符號，標記出已獲取資源中的子資源(可選項)
二，http的請求
http請求由三部分組成，分別是：請求行、請求報頭、請求正文
1. 請求行以一個方法符號開頭，以空格分開，後面跟著請求的URI和協議的版本，格式如下：Method Request-URI HTTP-Version CRLF
其中 Method表示請求方法；Request-URI是一個統一資源識別符號(url)；HTTP-Version表示請求的HTTP協議版本；CRLF表示回車和換行（除了作為結尾的CRLF外，不允許出現單獨的CR或LF字元）。 比如 GET /index.html HTTP/1.1
即 方法+URL+協議版本、
請求方法（所有方法全為大寫）有多種，各個方法的解釋如下：
GET 請求獲取Request-URI所標識的資源
POST 在Request-URI所標識的資源後附加新的資料
HEAD 請求獲取由Request-URI所標識的資源的響應訊息報頭
PUT 請求伺服器儲存一個資源，並用Request-URI作為其標識
DELETE 請求伺服器刪除Request-URI所標識的資源
TRACE 請求伺服器回送收到的請求資訊，主要用於測試或診斷
CONNECT 保留將來使用
OPTIONS 請求查詢伺服器的效能，或者查詢與資源相關的選項和需求
HEAD方法與GET方法幾乎是一樣的，對於HEAD請求的迴應部分來說，它的HTTP頭部中包含的資訊與通過GET請求所得到的資訊是相同的。利用這個方法，不必傳輸整個資源內容，就可以得到Request-URI所標識的資源的資訊。該方法常用於測試超連結的有效性，是否可以訪問，以及最近是否更新。
這裡著重講一下POST和GET 簡單來說get是從伺服器上獲取資料，post是向伺服器傳送資料（具體看圖）
2.請求報頭見後
3.請求內容略。。
三，http響應
HTTP響應也是由三個部分組成，分別是：狀態行、訊息報頭、響應正文
1.狀態行
HTTP-Version Status-Code Reason-Phrase CRLF
其中，HTTP-Version表示伺服器HTTP協議的版本；Status-Code表示伺服器發回的響應狀態程式碼；Reason-Phrase表示狀態程式碼的文字描述。
例子 HTTP/1.1 200 OK
狀態程式碼有三位數字組成，第一個數字定義了響應的類別，且有五種可能取值：
1xx：指示資訊–表示請求已接收，繼續處理
2xx：成功–表示請求已被成功接收、理解、接受
3xx：重定向–要完成請求必須進行更進一步的操作
4xx：客戶端錯誤–請求有語法錯誤或請求無法實現
5xx：伺服器端錯誤–伺服器未能實現合法的請求
這裡重點說幾個
200 OK //客戶端請求成功
400 Bad Request //客戶端請求有語法錯誤，不能被伺服器所理解
401 Unauthorized //請求未經授權
403 Forbidden //伺服器收到請求，但是拒絕提供服務
404 Not Found //請求資源不存在，eg：輸入了錯誤的URL
500 Internal Server Error //伺服器發生不可預期的錯誤
503 Server Unavailable //伺服器當前不能處理客戶端的請求，一段時間後可能恢復正常
2、響應報頭後述
3、響應正文就是伺服器返回的資源的內容
四，報頭
HTTP訊息由客戶端到伺服器的請求和伺服器到客戶端的響應組成。請求訊息和響應訊息都是由開始行（對於請求訊息，開始行就是請求行，對於響應訊息，開始行就是狀態行），訊息報頭（可選），空行（只有CRLF的行），訊息正文（可選）組成。
1、普通報頭
在普通報頭中，有少數報頭域用於所有的請求和響應訊息，但並不用於被傳輸的實體，只用於傳輸的訊息。（Cahe-Control:控制快取行為）（Connection：跳級首部，連線的管理）(Data:建立報文時間)等等
eg：
Cache-Control 用於指定快取指令，快取指令是單向的（響應中出現的快取指令在請求中未必會出現），且是獨立的（一個訊息的快取指令不會影響另一個訊息處理的快取機制），HTTP1.0使用的類似的報頭域為Pragma。
請求時的快取指令包括：no-cache（用於指示請求或響應訊息不能快取）、no-store(請求中含有機密資訊不能被快取)、max-age(指定快取時間，若小於則接受，否則反之)、max-stale(未指定引數即使過期也照常接受，若指定引數，則只要處於期限之內就接受)、min-fresh(返回至少還未過指定時間的資源)、only-if-cached(表示客戶端僅在快取伺服器本地快取目標資源的情況下才會要求返回，即快取伺服器不重新載入，也不確認資源有效性);
響應時的快取指令包括：public、private、no-cache、no-store、no-transform、must-revalidate、proxy-revalidate、max-age、s-maxage.
eg：為了指示IE瀏覽器（客戶端）不要快取頁面，伺服器端的JSP程式可以編寫如下：response.sehHeader(“Cache-Control”,”no-cache”);
//response.setHeader(“Pragma”,”no-cache”);作用相當於上述程式碼，通常兩者//合用
這句程式碼將在傳送的響應訊息中設定普通報頭域：Cache-Control:no-cache
Date普通報頭域表示訊息產生的日期和時間
Connection普通報頭域允許傳送指定連線的選項。例如指定連線是連續，或者指定“close”選項，通知伺服器，在響應完成後，關閉連線
2、請求報頭
請求報頭允許客戶端向伺服器端傳遞請求的附加資訊以及客戶端自身的資訊。
常用的請求報頭
Accept
Accept請求報頭域用於指定客戶端接受哪些型別的資訊。eg：Accept：image/gif，表明客戶端希望接受GIF圖象格式的資源；Accept：text/html，表明客戶端希望接受html文字。
Accept-Charset
Accept-Charset請求報頭域用於指定客戶端接受的字符集。eg：Accept-Charset:iso-8859-1,gb2312.如果在請求訊息中沒有設定這個域，預設是任何字符集都可以接受。
Accept-Encoding
Accept-Encoding請求報頭域類似於Accept，但是它是用於指定可接受的內容編碼。eg：Accept-Encoding:gzip.deflate.如果請求訊息中沒有設定這個域伺服器假定客戶端對各種內容編碼都可以接受。
Accept-Language
Accept-Language請求報頭域類似於Accept，但是它是用於指定一種自然語言。eg：Accept-Language:zh-cn.如果請求訊息中沒有設定這個報頭域，伺服器假定客戶端對各種語言都可以接受。
Authorization
Authorization請求報頭域主要用於證明客戶端有權檢視某個資源。當瀏覽器訪問一個頁面時，如果收到伺服器的響應程式碼為401（未授權），可以傳送一個包含Authorization請求報頭域的請求，要求伺服器對其進行驗證。
Host（傳送請求時，該報頭域是必需的）
Host請求報頭域主要用於指定被請求資源的Internet主機和埠號，它通常從HTTP URL中提取出來的，eg：
我們在瀏覽器中輸入：http://www.guet.edu.cn/index.html
瀏覽器傳送的請求訊息中，就會包含Host請求報頭域，如下：
Host：www.guet.edu.cn
此處使用預設埠號80，若指定了埠號，則變成：Host：www.guet.edu.cn:指定埠號
User-Agent
我們上網登陸論壇的時候，往往會看到一些歡迎資訊，其中列出了你的作業系統的名稱和版本，你所使用的瀏覽器的名稱和版本，這往往讓很多人感到很神奇，實際上，伺服器應用程式就是從User-Agent這個請求報頭域中獲取到這些資訊。User-Agent請求報頭域允許客戶端將它的作業系統、瀏覽器和其它屬性告訴伺服器。不過，這個報頭域不是必需的，如果我們自己編寫一個瀏覽器，不使用User-Agent請求報頭域，那麼伺服器端就無法得知我們的資訊了。
請求報頭舉例：
GET /form.html HTTP/1.1 (CRLF)
Accept:image/gif,image/x-xbitmap,image/jpeg,application/x-shockwave-flash,application/vnd.ms-excel,application/vnd.ms-powerpoint,application/msword,/ (CRLF)
Accept-Language:zh-cn (CRLF)
Accept-Encoding:gzip,deflate (CRLF)
If-Modified-Since:Wed,05 Jan 2007 11:21:25 GMT (CRLF)
If-None-Match:W/”80b1a4c018f3c41:8317” (CRLF)
User-Agent:Mozilla/4.0(compatible;MSIE6.0;Windows NT 5.0) (CRLF)
Host:www.guet.edu.cn (CRLF)
Connection:Keep-Alive (CRLF)
3、響應報頭
響應報頭允許伺服器傳遞不能放在狀態行中的附加響應資訊，以及關於伺服器的資訊和對Request-URI所標識的資源進行下一步訪問的資訊。
常用的響應報頭
Location
Location響應報頭域用於重定向接受者到一個新的位置。Location響應報頭域常用在更換域名的時候。
Server
Server響應報頭域包含了伺服器用來處理請求的軟體資訊。與User-Agent請求報頭域是相對應的。
五，Cookie和Session(解決http無狀態的辦法)
1.兩者不同點
1）Cookie將狀態儲存在客戶端，Session將狀態儲存在伺服器端。
2）Cookies是伺服器在本地機器上儲存的小段文字並隨每一個請求傳送至同一個伺服器。Cookie最早在RFC2109中實現，後續RFC2965做了增強。網路伺服器用HTTP頭向客戶端傳送cookies，在客戶終端，瀏覽器解析這些cookies並將它們儲存為一個本地檔案，它會自動將同一伺服器的任何請求縛上這些cookies。Session並沒有在HTTP的協議中定義；
3）Session是針對每一個使用者的，變數的值儲存在伺服器上，用一個sessionID來區分是哪個使用者session變數,這個值是通過使用者的瀏覽器在訪問的時候返回給伺服器，當客戶禁用cookie時，這個值也可能設定為由get來返回給伺服器；
2.Session實現
1）.cookie 見圖
2）url
URL回寫是指伺服器在傳送給瀏覽器頁面的所有連結中都攜帶JSESSIONID的引數，這樣客戶端點選任何一個連結都會把JSESSIONID帶會伺服器 如果直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。
3.與Cookie相關的HTTP擴充套件頭
1）Cookie：客戶端將伺服器設定的Cookie返回到伺服器；
2）Set-Cookie：伺服器向客戶端設定Cookie；
3）Cookie2 (RFC2965)）：客戶端指示伺服器支援Cookie的版本；
4）Set-Cookie2 (RFC2965)：伺服器向客戶端設定Cookie。
六，https(https預設的埠號是443)
HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎是SSL，因此加密的詳細內容請看SSL
有兩種基本的加解密演算法型別：
1）對稱加密：金鑰只有一個，加密解密為同一個密碼，且加解密速度快，典型的對稱加密演算法有DES、AES等；
2）非對稱加密：金鑰成對出現（且根據公鑰無法推知私鑰，根據私鑰也無法推知公鑰），加密解密使用不同金鑰（公鑰加密需要私鑰解密，私鑰加密需要公鑰解密），相對對稱加密速度較慢，典型的非對稱加密演算法有RSA、DSA等。
七.web安全問題
1.SQL注入
SQL注入是比較常見的網路攻擊方式之一，它不是利用作業系統的BUG來實現攻擊，而是針對程式設計師程式設計時的疏忽，通過SQL語句，實現無帳號登入，甚至篡改資料庫。
SQL注入攻擊的總體思路
1.尋找到SQL注入的位置
2.判斷伺服器型別和後臺資料庫型別
3.針對不通的伺服器和資料庫特點進行SQL注入攻擊
SQL注入攻擊例項:
比如在一個登入介面，要求輸入使用者名稱和密碼：
可以這樣輸入實現免帳號登入：
使用者名稱： ‘or 1 = 1 –
密 碼：
點登陸,如若沒有做特殊處理,那麼這個非法使用者就很得意的登陸進去了.(當然現在的有些語言的資料庫API已經處理了這些問題)
這是為什麼呢? 下面我們分析一下：
從理論上說，後臺認證程式中會有如下的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 使用者名稱等於 ” 或1=1 那麼這個條件一定會成功；
然後後面加兩個-，這意味著註釋，它將後面的語句註釋，讓他們不起作用，這樣語句永遠都能正確執行，使用者輕易騙過系統，獲取合法身份。
這還是比較溫柔的，如果是執行
SELECT * FROM user_table WHERE
username=” ;DROP DATABASE (DB Name) –’ and password=”
….其後果可想而知…
解決方法
1）那麼就應該在SQL被執行前，檢查確保變數id是int型別；如果是接受郵箱，那就應該檢查並嚴格確保變數一定是郵箱的格式，其他的型別比如日期、時間等也是一個道理。總結起來：只要是有固定格式的變數，在SQL語句執行前，應該嚴格按照固定格式去檢查，確保變數是我們預想的格式
2）正則表示式過濾特殊符號
3）採用預編譯語句集，它內建了處理SQL注入的能力，只要使用它的setXXX方法傳值即可
即使你後面輸入了這些sql命令，也不會被當成sql命令來執行了，因為這些sql命令的執行， 必須先的通過語法分析，生成執行計劃，既然語法分析已經完成，已經預編譯過了，那麼後面輸入的引數，是絕對不可能作為sql命令來執行的，只會被當做字串字面值引數。所以sql語句預編譯可以防禦sql注入。
2. 跨站指令碼攻擊(XSS)
跨站指令碼攻擊（XSS，Cross-site scripting）是最常見和基本的攻擊WEB網站的方法。攻擊者在網頁上釋出包含攻擊性程式碼的資料。當瀏覽者看到此網頁時，特定的指令碼就會以瀏覽者使用者的身份和許可權來執行。通過XSS可以比較容易地修改使用者資料、竊取使用者資訊，以及造成其它型別的攻擊，例如CSRF攻擊
理論上，所有可輸入的地方沒有對輸入資料進行處理的話，都會存在XSS漏洞，漏洞的危害取決於攻擊程式碼的威力，攻擊程式碼也不侷限於script
常見解決辦法:確保輸出到HTML頁面的資料以HTML的方式被轉義
例子：
1）. 做個假設，當亞馬遜在搜尋書籍，搜不到書的時候顯示提交的名稱。
2）. 在搜尋框搜尋內容，填入“”, 點選搜尋。
3）. 當前端頁面沒有對返回的資料進行過濾，直接顯示在頁面上， 這時就會alert那個字元串出來。
4）. 進而可以構造獲取使用者cookies的地址，通過QQ群或者垃圾郵件，來讓其他人點選這個地址：
安全措施：
1）. 前端在顯示服務端資料時候，不僅是標籤內容需要過濾、轉義，就連屬性值也都可能需要。
2）. 後端接收請求時，驗證請求是否為攻擊請求，攻擊則遮蔽。
<span><script>alert('handsome boy')</script></span>轉義為
<span><script>alert('handsome boy')</script></span>
3.CSRF跨站點請求偽造(Cross—Site Request Forgery)，跟XSS攻擊一樣，存在巨大的危害性，你可以這樣來理解：
攻擊者盜用了你的身份，以你的名義傳送惡意請求，對伺服器來說這個請求是完全合法的，但是卻完成了攻擊者所期望的一個操作，比如以你的名義傳送郵件、發訊息，盜取你的賬號，新增系統管理員，甚至於購買商品、虛擬貨幣轉賬等。
其中Web A為存在CSRF漏洞的網站，Web B為攻擊者構建的惡意網站，User C為Web A網站的合法使用者。
1） 使用者C開啟瀏覽器，訪問受信任網站A，輸入使用者名稱和密碼請求登入網站A；
2）在使用者資訊通過驗證後，網站A產生Cookie資訊並返回給瀏覽器，此時使用者登入網站A成功，可以正常傳送請求到網站A；
3） 使用者未退出網站A之前，在同一瀏覽器中，開啟一個TAB頁訪問網站B；
4） 網站B接收到使用者請求後，返回一些攻擊性程式碼，併發出一個請求要求訪問第三方站點A；
5） 瀏覽器在接收到這些攻擊性程式碼後，根據網站B的請求，在使用者不知情的情況下攜帶Cookie資訊，向網站A發出請求。網站A並不知道該請求其實是由B發起的，所以會根據使用者C的Cookie資訊以C的許可權處理該請求，導致來自網站B的惡意程式碼被執行
防禦CSRF攻擊：
目前防禦 CSRF 攻擊主要有三種策略：驗證 HTTP Referer 欄位；在請求地址中新增 token 並驗證；在 HTTP 頭中自定義屬性並驗證。
（1）驗證 HTTP Referer 欄位
根據 HTTP 協議，在 HTTP 頭中有一個欄位叫 Referer，它記錄了該 HTTP 請求的來源地址。在通常情況下，訪問一個安全受限頁面的請求來自於同一個網
（2）在請求地址中新增 token 並驗證
CSRF 攻擊之所以能夠成功，是因為黑客可以完全偽造使用者的請求，該請求中所有的使用者驗證資訊都是存在於 cookie 中，因此黑客可以在不知道這些驗證資訊的情況下直接利用使用者自己的 cookie 來通過安全驗證。要抵禦CSRF，關鍵在於在請求中放入黑客所不能偽造的資訊，並且該資訊不存在於 cookie 之中。可以在 HTTP 請求中以引數的形式加入一個隨機產生的 token，並在伺服器端建立一個攔截器來驗證這個 token，如果請求中沒有 token 或者 token 內容不正確，則認為可能是 CSRF 攻擊而拒絕該請求。
對於 GET 請求，token 將附在請求地址之後，這樣 URL 就變成 http://url?csrftoken=tokenvalue。 而對於 POST 請求來說，要在 form 的最後加上 ，這樣就把 token 以引數的形式加入請求了。但是，在一個網站中，可以接受請求的地方非常多，要對於每一個請求都加上 token
（3）在 HTTP 頭中自定義屬性並驗證
是很麻煩的，並且很容易漏掉，通常使用的方法就是在每次頁面載入時，使用 javascript 遍歷整個 dom 樹，對於 dom 中所有的 a 和 form 標籤後加入 token。這樣可以解決大部分的請求，但是對於在頁面載入之後動態生成的 html 程式碼，這種方法就沒有作用，還需要程式設計師在編碼時手動新增 token。
這種方法也是使用 token 並進行驗證，和上一種方法不同的是，這裡並不是把 token 以引數的形式置於 HTTP 請求之中，而是把它放到 HTTP 頭中自定義的屬性裡。通過 XMLHttpRequest 這個類，可以一次性給所有該類請求加上 csrftoken 這個 HTTP 頭屬性，並把 token 值放入其中。這樣解決了上種方法在請求中加入 token 的不便，同時，通過 XMLHttpRequest 請求的地址不會被記錄到瀏覽器的位址列，也不用擔心 token 會透過 Referer 洩露到其他網站中去。
然而這種方法的侷限性非常大。XMLHttpRequest 請求通常用於 Ajax 方法中對於頁面區域性的非同步重新整理，並非所有的請求都適合用這個類來發起，而且通過該類請求得到的頁面不能被瀏覽器所記錄下，從而進行前進，後退，重新整理，收藏等操作，給使用者帶來不便。另外，對於沒有進行 CSRF 防護的遺留系統來說，要採用這種方法來進行防護，要把所有請求都改為 XMLHttpRequest 請求，這樣幾乎是要重寫整個網站，這代價無疑是不能接受的。
4.Http Heads攻擊
凡是用瀏覽器檢視任何WEB網站，無論你的WEB網站採用何種技術和框架，都用到了HTTP協議.HTTP協議在Response header和content之間，有一個空行，即兩組CRLF（0x0D 0A）字元。這個空行標誌著headers的結束和content的開始。“聰明”的攻擊者可以利用這一點。只要攻擊者有辦法將任意字元“注入”到headers中，這種攻擊就可以發生
http://localhost/login?page=http%3A%2F%2Flocalhost%2Findex
當登入成功以後，需要重定向回page引數所指定的頁面。下面是重定向發生時的response headers.
HTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/indexHTTP/1.1 302 Moved Temporarily
Date: Tue, 17 Aug 2010 20:00:29 GMT
Server: Apache mod_fcgid/2.3.5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Location: http://localhost/checkout<CRLF>
<CRLF>
<script>alert('hello')</script>這個頁面可能會意外地執行隱藏在URL中的javascript。類似的情況不僅發生在重定向（Location header）上，也有可能發生在其它headers中，如Set-Cookie header。這種攻擊如果成功的話，可以做很多事，例如：執行指令碼、設定額外的cookie（Set-Cookie: evil=value）等。
避免這種攻擊的方法，就是過濾所有的response headers，除去header中出現的非法字元，尤其是CRLF
伺服器一般會限制request headers的大小。例如Apache server預設限制request header為8K。如果超過8K，Aapche Server將會返回400 Bad Request響應：
5.Cookie攻擊
通過Java Script非常容易訪問到當前網站的cookie。你可以開啟任何網站，然後在瀏覽器位址列中輸入：javascript:alert(doucment.cookie),立刻就可以看到當前站點的cookie（如果有的話）。攻擊者可以利用這個特性來取得你的關鍵資訊。例如，和XSS攻擊相配合，攻擊者在你的瀏覽器上執行特定的Java Script指令碼，取得你的cookie。假設這個網站僅依賴cookie來驗證使用者身份，那麼攻擊者就可以假冒你的身份來做一些事情。
現在多數瀏覽器都支援在cookie上打上HttpOnly的標記,凡有這個標誌的cookie就無法通過Java Script來取得,如果能在關鍵cookie上打上這個標記，就會大大增強cookie的安全性
6.重定向攻擊
一種常用的攻擊手段是“釣魚”。釣魚攻擊者，通常會發送給受害者一個合法連結，當連結被點選時，使用者被導向一個似是而非的非法網站，從而達到騙取使用者信任、竊取使用者資料的目的。為防止這種行為,我們必須對所有的重定向操作進行稽核,以避免重定向到一個危險的地方.常見解決方案是白名單,將合法的要重定向的url加到白名單中,非白名單上的域名重定向時拒之,第二種解決方案是重定向token,在合法的url上加上token,重定向時進行驗證
七，ajax演示