- 白帽子講Web安全（紀念版）
- 吳翰清
- 10字
- 2019-01-04 14:20:30
第二篇 客戶端腳本安全
第2章 瀏覽器安全
近年來隨著互聯網的發展，人們發現瀏覽器才是互聯網最大的入口，絕大多數用戶使用互聯網的工具是瀏覽器。因此瀏覽器市場的競爭也日趨白熱化。
瀏覽器安全在這種激烈競爭的環境中被越來越多的人所重視。一方面，瀏覽器天生就是一個客戶端，如果具備了安全功能，就可以像安全軟件一樣對用戶上網起到很好的保護作用；另一方面，瀏覽器安全也成為瀏覽器廠商之間競爭的一張底牌，瀏覽器廠商希望能夠針對安全建立起技術門檻，以獲得競爭優勢。
因此近年來隨著瀏覽器版本的不斷更新，瀏覽器安全功能變得越來越強大。在本章中，我們將介紹一些主要的瀏覽器安全功能。
2.1 同源策略
同源策略（Same Origin Policy）是一種約定，它是瀏覽器最核心也最基本的安全功能，如果缺少了同源策略，則瀏覽器的正常功能可能都會受到影響?？梢哉fWeb是構建在同源策略的基礎之上的，瀏覽器只是針對同源策略的一種實現。
對于客戶端Web安全的學習與研究來說，深入理解同源策略是非常重要的，也是后續學習的基礎。很多時候瀏覽器實現的同源策略是隱性、透明的，很多因為同源策略導致的問題并沒有明顯的出錯提示，如果不熟悉同源策略，則可能一直都會想不明白問題的原因。
瀏覽器的同源策略，限制了來自不同源的“document”或腳本，對當前“document”讀取或設置某些屬性。
這一策略極其重要，試想如果沒有同源策略，可能a.com的一段JavaScript腳本，在b.com未曾加載此腳本時，也可以隨意涂改b.com的頁面（在瀏覽器的顯示中）。為了不讓瀏覽器的頁面行為發生混亂，瀏覽器提出了“Origin”（源）這一概念，來自不同Origin的對象無法互相干擾。
對于JavaScript來說，以下情況被認為是同源與不同源的。
瀏覽器中JavaScript的同源策略（當JavaScript被瀏覽器認為來自不同源時，請求被拒絕）
由上表可以看出，影響“源”的因素有：host（域名或IP地址，如果是IP地址則看做一個根域名）、子域名、端口、協議。
需要注意的是，對于當前頁面來說，頁面內存放JavaScript文件的域并不重要，重要的是加載JavaScript頁面所在的域是什么。
換言之，a.com通過以下代碼：
<script src=http://b.com/b.js ></script>
加載了b.com上的b.js，但是b.js是運行在a.com頁面中的，因此對于當前打開的頁面（a.com頁面）來說，b.js的Origin就應該是a.com而非b.com。
在瀏覽器中，<script>、<img>、<iframe>、<link>等標簽都可以跨域加載資源，而不受同源策略的限制。這些帶“src”屬性的標簽每次加載時，實際上是由瀏覽器發起了一次GET請求。不同于XMLHttpRequest的是，通過src屬性加載的資源，瀏覽器限制了JavaScript的權限，使其不能讀、寫返回的內容。
對于XMLHttpRequest來說，它可以訪問來自同源對象的內容。比如下例：
<html>
<head>
<script type="text/javascript">
var xmlhttp;
function loadXMLDoc(url)
{
xmlhttp=null;
if (window.XMLHttpRequest)
{// code for Firefox, Opera, IE7, etc.
xmlhttp=new XMLHttpRequest();
}
else if (window.ActiveXObject)
{// code for IE6, IE5
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
if (xmlhttp! =null)
{
xmlhttp.onreadystatechange=state_Change;
xmlhttp.open("GET", url, true);
xmlhttp.send(null);
}
else
{
alert("Your browser does not support XMLHTTP.");
}
}
function state_Change()
{
if (xmlhttp.readyState==4)
{// 4 = "loaded"
if (xmlhttp.status==200)
{// 200 = "OK"
document.getElementById('T1').innerHTML=xmlhttp.responseText;
}
else
{
alert("Problem retrieving data:" + xmlhttp.statusText);
}
}
}
</script>
</head>
<body onload="loadXMLDoc('/example/xdom/test_xmlhttp.txt')">
<div id="T1" style="border:1px solid black; height:40; width:300; padding:5"></div><br />
<button onclick="loadXMLDoc('/example/xdom/test_xmlhttp2.txt')">Click</button>
</body>
</html>
但XMLHttpRequest受到同源策略的約束，不能跨域訪問資源，在AJAX應用的開發中尤其需要注意這一點。
如果XMLHttpRequest能夠跨域訪問資源，則可能會導致一些敏感數據泄露，比如CSRF的token，從而導致發生安全問題。
但是互聯網是開放的，隨著業務的發展，跨域請求的需求越來越迫切，因此W3C委員會制定了XMLHttpRequest跨域訪問標準。它需要通過目標域返回的HTTP頭來授權是否允許跨域訪問，因為HTTP頭對于JavaScript來說一般是無法控制的，所以認為這個方案可以實施。注意：這個跨域訪問方案的安全基礎就是信任“JavaScript無法控制該HTTP頭”，如果此信任基礎被打破，則此方案也將不再安全。
跨域訪問請求過程
具體的實現過程，在本書的“HTML 5安全”一章中會繼續探討。
對于瀏覽器來說，除了DOM、Cookie、XMLHttpRequest會受到同源策略的限制外，瀏覽器加載的一些第三方插件也有各自的同源策略。最常見的一些插件如Flash、Java Applet、Silverlight、Google Gears等都有自己的控制策略。
以Flash為例，它主要通過目標網站提供的crossdomain.xml文件判斷是否允許當前“源”的Flash跨域訪問目標資源。
以www.qq.com的策略文件為例，當瀏覽器在任意其他域的頁面里加載了Flash后，如果對www.qq.com發起訪問請求，Flash會先檢查www.qq.com上此策略文件是否存在。如果文件存在，則檢查發起請求的域是否在許可范圍內。
www.qq.com的crossdomain.xml文件
在這個策略文件中，只有來自*.qq.com和 *.gtimg.com域的請求是被允許的。依靠這種方式，從Origin的層面上控制了Flash行為的安全性。
在Flash 9及其之后的版本中，還實現了MIME檢查以確認crossdomain.xml是否合法，比如查看服務器返回HTTP頭的Content-Type是否是text/*、application/xml、application/xhtml+xml。這樣做的原因，是因為攻擊者可以通過上傳crossdomain.xml文件控制Flash的行為，繞過同源策略。除了MIME檢查外，Flash還會檢查crossdomain.xml是否在根目錄下，也可以使得一些上傳文件的攻擊失效。
然而瀏覽器的同源策略也并非是堅不可摧的堡壘，由于實現上的一些問題，一些瀏覽器的同源策略也曾經多次被繞過。比如下面這個IE 8的CSS跨域漏洞。
www.a.com/test.html：
<body>
{}body{font-family:
aaaaaaaaaaaaaa
bbbbbbbbbbbbbbbb
</body>
www.b.com/test2.html：
<style>
@import url("http://www.a.com/test.html");
</style>
<script>
setTimeout(function(){
var t = document.body.currentStyle.fontFamily;
alert(t);
},2000);
</script>
在www.b.com/test2.html中通過@import加載了http://www.a.com/test.html為CSS文件，渲染進入當前頁面DOM，同時通過document.body.currentStyle.fontFamily訪問此內容。問題發生在IE的CSS Parse的過程中，IE將fontFamily后面的內容當做了value，從而可以讀取www.a.com/test.html的頁面內容。
在www.b.com下讀取到了www.a.com的頁面內容
我們前面提到，比如<script>等標簽僅能加載資源，但不能讀、寫資源的內容，而這個漏洞能夠跨域讀取頁面內容，因此繞過了同源策略，成為一個跨域漏洞。
瀏覽器的同源策略是瀏覽器安全的基礎，在本書后續章節中提到的許多客戶端腳本攻擊，都需要遵守這一法則，因此理解同源策略對于客戶端腳本攻擊有著重要意義。同源策略一旦出現漏洞被繞過，也將帶來非常嚴重的后果，很多基于同源策略制定的安全方案都將失去效果。
2.2 瀏覽器沙箱
針對客戶端的攻擊近年來呈現爆發趨勢：
2009年全年掛馬網站狀況趨勢圖
這種在網頁中插入一段惡意代碼，利用瀏覽器漏洞執行任意代碼的攻擊方式，在黑客圈子里被形象地稱為“掛馬”。
“掛馬”是瀏覽器需要面對的一個主要威脅。近年來，獨立于殺毒軟件之外，瀏覽器廠商根據掛馬的特點研究出了一些對抗掛馬的技術。
比如在Windows系統中，瀏覽器密切結合DEP、ASLR、SafeSEH等操作系統提供的保護技術，對抗內存攻擊。與此同時，瀏覽器還發展出了多進程架構，從安全性上有了很大的提高。
瀏覽器的多進程架構，將瀏覽器的各個功能模塊分開，各個瀏覽器實例分開，當一個進程崩潰時，也不會影響到其他的進程。
Google Chrome是第一個采取多進程架構的瀏覽器。Google Chrome的主要進程分為：瀏覽器進程、渲染進程、插件進程、擴展進程。插件進程如flash、java、pdf等與瀏覽器進程嚴格隔離，因此不會互相影響。
Google Chrome的架構
渲染引擎由Sandbox隔離，網頁代碼要與瀏覽器內核進程通信、與操作系統通信都需要通過IPC channel，在其中會進行一些安全檢查。
Sandbox即沙箱，計算機技術發展到今天，Sandbox已經成為泛指“資源隔離類模塊”的代名詞。Sandbox的設計目的一般是為了讓不可信任的代碼運行在一定的環境中，限制不可信任的代碼訪問隔離區之外的資源。如果一定要跨越Sandbox邊界產生數據交換，則只能通過指定的數據通道，比如經過封裝的API來完成，在這些API中會嚴格檢查請求的合法性。
Sandbox的應用范圍非常廣泛。比如一個提供hosting服務的共享主機環境，假設支持用戶上傳PHP、Python、Java等語言的代碼，為了防止用戶代碼破壞系統環境，或者是不同用戶之間的代碼互相影響，則應該設計一個Sandbox對用戶代碼進行隔離。Sandbox需要考慮用戶代碼針對本地文件系統、內存、數據庫、網絡的可能請求，可以采用默認拒絕的策略，對于有需要的請求，則可以通過封裝API的方式實現。
而對于瀏覽器來說，采用Sandbox技術，無疑可以讓不受信任的網頁代碼、JavaScript代碼運行在一個受到限制的環境中，從而保護本地桌面系統的安全。
Google Chrome實現了一個相對完整的Sandbox：
Google Chrome的Sandbox架構
IE 8也采取了多進程架構，每一個Tab頁即是一個進程，如下是IE 8的架構：
IE 8的架構
多進程架構最明顯的一個好處是，相對于單進程瀏覽器，在發生崩潰時，多進程瀏覽器只會崩潰當前的Tab頁，而單進程瀏覽器則會崩潰整個瀏覽器進程。這對于用戶體驗是很大的提升。
但是瀏覽器安全是一個整體，在現今的瀏覽器中，雖然有多進程架構和Sandbox的保護，但是瀏覽器所加載的一些第三方插件卻往往不受Sandbox管轄。比如近年來在Pwn2Own大會上被攻克的瀏覽器，往往都是由于加載的第三方插件出現安全漏洞導致的。Flash、Java、PDF、.Net Framework在近年來都成為瀏覽器攻擊的熱點。
也許在不遠的未來，在瀏覽器的安全模型中會更加重視這些第三方插件，不同廠商之間會就安全達成一致的標準，也只有這樣，才能將這個互聯網的入口打造得更加牢固。
2.3 惡意網址攔截
上節提到了“掛馬”攻擊方式能夠破壞瀏覽器安全，在很多時候，“掛馬”攻擊在實施時會在一個正常的網頁中通過<script>或者<iframe>等標簽加載一個惡意網址。而除了掛馬所加載的惡意網址之外，釣魚網站、詐騙網站對于用戶來說也是一種惡意網址。為了保護用戶安全，瀏覽器廠商紛紛推出了各自的攔截惡意網址功能。目前各個瀏覽器的攔截惡意網址的功能都是基于“黑名單”的。
惡意網址攔截的工作原理很簡單，一般都是瀏覽器周期性地從服務器端獲取一份最新的惡意網址黑名單，如果用戶上網時訪問的網址存在于此黑名單中，瀏覽器就會彈出一個警告頁面。
Google Chrome的惡意網址攔截警告
常見的惡意網址分為兩類：一類是掛馬網站，這些網站通常包含有惡意的腳本如JavaScript或Flash，通過利用瀏覽器的漏洞（包括一些插件、控件漏洞）執行shellcode，在用戶電腦中植入木馬；另一類是釣魚網站，通過模仿知名網站的相似頁面來欺騙用戶。
要識別這兩種網站，需要建立許多基于頁面特征的模型，而這些模型顯然是不適合放在客戶端的，因為這會讓攻擊者得以分析、研究并繞過這些規則。同時對于用戶基數巨大的瀏覽器來說，收集用戶訪問過的歷史記錄也是一種侵犯隱私的行為，且數據量過于龐大。
基于這兩個原因，瀏覽器廠商目前只是以推送惡意網址黑名單為主，瀏覽器收到黑名單后，對用戶訪問的黑名單進行攔截；而很少直接從瀏覽器收集數據，或者在客戶端建立模型?，F在的瀏覽器多是與專業的安全廠商展開合作，由安全廠商或機構提供惡意網址黑名單。
一些有實力的瀏覽器廠商，比如Google和微軟，由于本身技術研發實力較強，且又掌握了大量的用戶數據，因此自建有安全團隊做惡意網址識別工作，用以提供瀏覽器所使用的黑名單。對于搜索引擎來說，這份黑名單也是其核心競爭力之一。
PhishTank是互聯網上免費提供惡意網址黑名單的組織之一，它的黑名單由世界各地的志愿者提供，且更新頻繁。
PhishTank的惡意網址列表
類似地，Google也公開了其內部使用的SafeBrowsing API，任何組織或個人都可以在產品中接入，以獲取Google的惡意網址庫。
除了惡意網址黑名單攔截功能外，主流瀏覽器都開始支持EV SSL證書（Extended Validation SSL Certificate），以增強對安全網站的識別。
EVSSL證書是全球數字證書頒發機構與瀏覽器廠商一起打造的增強型證書，其主要特色是瀏覽器會給予EVSSL證書特殊待遇。EVSSL證書也遵循X509標準，并向前兼容普通證書。如果瀏覽器不支持EV模式，則會把該證書當做普通證書；如果瀏覽器支持（需要較新版本的瀏覽器）EV模式，則會在地址欄中特別標注。
在IE中：
EV證書在IE中的效果
在Firefox中：
EV證書在Firefox中的效果
而普通的https證書則沒有綠色的醒目提示：
普通證書在IE中的效果
因此網站在使用了EV SSL證書后，可以教育用戶識別真實網站在瀏覽器地址欄中的“綠色”表現，以對抗釣魚網站。
使用EV證書的網站在IE中的效果
雖然很多用戶對瀏覽器的此項功能并不熟悉，EVSSL證書的效果并非特別好，但隨著時間的推移，有望讓EVSSL證書的認證功能逐漸深入人心。
2.4 高速發展的瀏覽器安全
“瀏覽器安全”領域涵蓋的范圍非常大，且今天瀏覽器仍然在不斷更新，不斷推出新的安全功能。
為了在安全領域獲得競爭力，微軟率先在IE 8中推出了XSS Filter功能，用以對抗反射型XSS。一直以來，XSS（跨站腳本攻擊）都被認為是服務器端應用的漏洞，應該由服務器端應用在代碼中修補，而微軟率先推出了這一功能，就使得IE 8在安全領域極具特色。
當用戶訪問的URL中包含了XSS攻擊的腳本時，IE就會修改其中的關鍵字符使得攻擊無法成功完成，并對用戶彈出提示框。
IE 8攔截了XSS攻擊
有安全研究員通過逆向工程反編譯了IE 8的可執行文件，得到下面這些規則：
{(v|(&[#()\[\].]x?0＊((86)|(56)|(118)|(76)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(10)|A|D)
;? ))＊(b|(&[#()\[\].]x?0＊((66)|(42)|(98)|(62)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(10)|A
|D); ? ))＊(s|(&[#()\[\].]x?0＊((83)|(53)|(115)|(73)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(1
0)|A|D); ? ))＊(c|(&[#()\[\].]x?0＊((67)|(43)|(99)|(63)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)
|(10)|A|D); ? ))＊{(r|(&[#()\[\].]x?0＊((82)|(52)|(114)|(72)); ? ))}([\t]|(&[#()\[\].]x?0＊(
9|(13)|(10)|A|D); ? ))＊(i|(&[#()\[\].]x?0＊((73)|(49)|(105)|(69)); ? ))([\t]|(&[#()\[\].]x
?0＊(9|(13)|(10)|A|D); ? ))＊(p|(&[#()\[\].]x?0＊((80)|(50)|(112)|(70)); ? ))([\t]|(&[#()\[\
].]x?0＊(9|(13)|(10)|A|D); ? ))＊(t|(&[#()\[\].]x?0＊((84)|(54)|(116)|(74)); ? ))([\t]|(&[#(
)\[\].]x?0＊(9|(13)|(10)|A|D); ? ))＊(:|(&[#()\[\].]x?0＊((58)|(3A)); ? )).}
{(j|(&[#()\[\].]x?0＊((74)|(4A)|(106)|(6A)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(10)|A|D)
;? ))＊(a|(&[#()\[\].]x?0＊((65)|(41)|(97)|(61)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(10)|A
|D); ? ))＊(v|(&[#()\[\].]x?0＊((86)|(56)|(118)|(76)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)|(1
0)|A|D); ? ))＊(a|(&[#()\[\].]x?0＊((65)|(41)|(97)|(61)); ? ))([\t]|(&[#()\[\].]x?0＊(9|(13)
|(10)|A|D); ? ))＊(s|(&[#()\[\].]x?0＊((83)|(53)|(115)|(73)); ? ))([\t]|(&[#()\[\].]x?0＊(9|
(13)|(10)|A|D); ? ))＊(c|(&[#()\[\].]x?0＊((67)|(43)|(99)|(63)); ? ))([\t]|(&[#()\[\].]x?0＊
(9|(13)|(10)|A|D); ? ))＊{(r|(&[#()\[\].]x?0＊((82)|(52)|(114)|(72)); ? ))}([\t]|(&[#()\[\]
.]x?0＊(9|(13)|(10)|A|D); ? ))＊(i|(&[#()\[\].]x?0＊((73)|(49)|(105)|(69)); ? ))([\t]|(&[#()
\[\].]x?0＊(9|(13)|(10)|A|D); ? ))＊(p|(&[#()\[\].]x?0＊((80)|(50)|(112)|(70)); ? ))([\t]|(&
[#()\[\].]x?0＊(9|(13)|(10)|A|D); ? ))＊(t|(&[#()\[\].]x?0＊((84)|(54)|(116)|(74)); ? ))([\t
]|(&[#()\[\].]x?0＊(9|(13)|(10)|A|D); ? ))＊(:|(&[#()\[\].]x?0＊((58)|(3A)); ? )).}
{<st{y}le.＊? >.＊? ((@[i\\])|(([:=]|(&[#()\[\].]x?0＊((58)|(3A)|(61)|(3D)); ? )).＊? ([(\\]|(
&[#()\[\].]x?0＊((40)|(28)|(92)|(5C)); ? ))))}
{[ /+\t\"\'`]st{y}le[ /+\t]＊? =.＊? ([:=]|(&[#()\[\].]x?0＊((58)|(3A)|(61)|(3D)); ? )).＊? ([
(\\]|(&[#()\[\].]x?0＊((40)|(28)|(92)|(5C)); ? ))}
{<OB{J}ECT[ /+\t].＊? ((type)|(codetype)|(classid)|(code)|(data))[ /+\t]＊=}
{<AP{P}LET[ /+\t].＊? code[ /+\t]＊=}
{[ /+\t\"\'`]data{s}rc[ +\t]＊? =.}
{<BA{S}E[ /+\t].＊? href[ /+\t]＊=}
{<LI{N}K[ /+\t].＊? href[ /+\t]＊=}
{<ME{T}A[ /+\t].＊? http-equiv[ /+\t]＊=}
{<\? im{p}ort[ /+\t].＊? implementation[ /+\t]＊=}
{<EM{B}ED[ /+\t].＊? SRC.＊? =}
{[ /+\t\"\'`]{o}n\c\c\c+? [ +\t]＊? =.}
{<.＊[:]vmlf{r}ame.＊? [ /+\t]＊? src[ /+\t]＊=}
{<[i]? f{r}ame.＊? [ /+\t]＊? src[ /+\t]＊=}
{<is{i}ndex[ /+\t>]}
{<fo{r}m.＊? >}
{<sc{r}ipt.＊? [ /+\t]＊? src[ /+\t]＊=}
{<sc{r}ipt.＊? >}
{[\"\'][ ]＊(([^a-z0-9～_:\'\" ])|(in)).＊? (((l|(\\u006C))(o|(\\u006F))({c}|(\\u00{6}3))
(a|(\\u0061))(t|(\\u0074))(i|(\\u0069))(o|(\\u006F))(n|(\\u006E)))|((n|(\\u006E))(a|(
\\u0061))({m}|(\\u00{6}D))(e|(\\u0065)))).＊? =}
{[\"\'][ ]＊(([^a-z0-9～_:\'\" ])|(in)).+? {[\[]}.＊? {[\]]}.＊? =}
{[\"\'][ ]＊(([^a-z0-9～_:\'\" ])|(in)).+? {[.]}.+? =}
{[\"\'].＊? {\)}[ ]＊(([^a-z0-9～_:\'\" ])|(in)).+? {\(}}
{[\"\'][ ]＊(([^a-z0-9～_:\'\" ])|(in)).+? {\().＊? {\}}}
這些規則可以捕獲URL中的XSS攻擊，其他的安全產品可以借鑒。
而Firefox也不甘其后，在Firefox 4中推出了Content Security Policy（CSP）。這一策略是由安全專家Robert Hanson最早提出的，其做法是由服務器端返回一個HTTP頭，并在其中描述頁面應該遵守的安全策略。
由于XSS攻擊在沒有第三方插件幫助的情況下，無法控制HTTP頭，所以這項措施是可行的。
而這種自定義的語法必須由瀏覽器支持并實現，Firefox是第一個支持此標準的瀏覽器。
使用CSP的方法如下，插入一個HTTP返回頭：
X-Content-Security-Policy: policy
其中policy的描述極其靈活，比如：
X-Content-Security-Policy: allow 'self' ＊.mydomain.com
瀏覽器將信任來自mydomain.com及其子域下的內容。
又如：
X-Content-Security-Policy: allow 'self'; img-src ＊; media-src media1.com; script-src
userscripts.example.com
瀏覽器除了信任自身的來源外，還可以加載任意域的圖片、來自media1.com的媒體文件，以及userscripts.example.com的腳本，其他的則一律拒絕。
CSP的設計理念無疑是出色的，但是CSP的規則配置較為復雜，在頁面較多的情況下，很難一個個配置起來，且后期維護成本也非常巨大，這些原因導致CSP未能得到很好的推廣。
除了這些新的安全功能外，瀏覽器的用戶體驗也越來越好，隨之而來的是許多標準定義之外的“友好”功能，但很多程序員并不知道這些新功能，從而可能導致一些安全隱患。
比如，瀏覽器地址欄對于畸形URL的處理就各自不同。在IE中，如下URL將被正常解析：
www.google.com\abc
會變為
www.google.com/abc
具有同樣行為的還有Chrome，將“\”變為標準的“/”。
但是Firefox卻不如此解析，www.google.com\abc將被認為是非法的地址，無法打開。
同樣“友好”的功能還有，Firefox、IE、Chrome都會認識如下的URL：
www.google.com? abc
會變為
www.google.com/? abc
Firefox比較有意思，還能認識如下的URL：
[http://www.cnn.com]
[http://]www.cnn.com
[http://www].cnn.com
……
這些功能雖然很“友好”，但是如果被黑客所利用，可能會用于繞過一些安全軟件或者安全模塊，反而不美了。
瀏覽器加載的插件也是瀏覽器安全需要考慮的一個問題。近年來瀏覽器所重點打造的一大特色，就是豐富的擴展與插件。
擴展和插件極大地豐富了瀏覽器的功能，但安全問題也隨之而來，除了插件可能存在漏洞外，插件本身也可能會有惡意行為。擴展和插件的權限都高于頁面JavaScript的權限，比如可以進行一些跨域網絡請求等。
在插件中，也曾經出現過一些具有惡意功能的程序，比如代號為Trojan.PWS.ChromeInject.A的惡意插件，其目標是竊取網銀密碼。它有兩個文件：
"%ProgramFiles%\Mozilla Firefox\plugins\npbasic.dll"
"%ProgramFiles%\Mozilla Firefox\chrome\chrome\content\browser.js"
它將監控所有Firefox瀏覽的網站，如果發現用戶在訪問網銀，就準備開始記錄密碼，并發送到遠程服務器。新的功能，也給我們帶來了新的挑戰。
2.5 小結
瀏覽器是互聯網的重要入口，在安全攻防中，瀏覽器的作用也越來越被人們所重視。在以往研究攻防時，大家更重視的是服務器端漏洞；而在現在，安全研究的范圍已經涵蓋了所有用戶使用互聯網的方式，瀏覽器正是其中最為重要的一個部分。
瀏覽器的安全以同源策略為基礎，加深理解同源策略，才能把握住瀏覽器安全的本質。在當前瀏覽器高速發展的形勢下，惡意網址檢測、插件安全等問題都會顯得越來越重要。緊跟瀏覽器發展的腳步來研究瀏覽器安全，是安全研究者需要認真對待的事情。
- Extending Symfony2 Web Application Framework
- 網絡安全與管理
- 白話網絡安全2：網安戰略篇
- Metasploit Penetration Testing Cookbook（Second Edition）
- 黑客攻防技巧
- 網絡運維親歷記 (網絡運維紀實文學)
- Testing and Securing Android Studio Applications
- Applied Network Security
- 云原生安全與DevOps保障
- 軟件安全保障體系架構
- 數據安全領域指南
- 互聯網企業安全高級指南
- 捍衛隱私
- Android Application Security Essentials
- 信息系統安全等級化保護原理與實踐