什么是文件上傳漏洞

文件上傳漏洞是指
由于程序員在對用戶文件上傳部分的控制不足或者處理缺陷，而導致的用戶可以越過其本身權限向服務器上上傳可執行的動態腳本文件
這里上傳的文件可以是木馬，病毒，惡意腳本或者WebShell等。
這種攻擊方式是最為直接和有效的，“文件上傳”本身沒有問題，有問題的是文件上傳后，服務器怎么處理、解釋文件。如果服務器的處理邏輯做的不夠安全，則會導致嚴重的后果。

解析漏洞
攻擊者在利用上傳漏洞時，通常會與Web容器的解析漏洞配合在一起

造成文件上傳漏洞的原因
對于上傳文件的后綴名（擴展名）沒有做較為嚴格的限制
對于上傳文件的MIMETYPE(用于描述文件的類型的一種表述方法) 沒有做檢查
權限上沒有對于上傳的文件目錄設置不可執行權限，（尤其是對于shebang類型的文件）
對于web server對于上傳文件或者指定目錄的行為沒有做限制

防止上傳漏洞兩種策略
客戶端檢測：客戶端使用JS檢測，在文件未上傳時，就對文件進行驗證
服務器端檢測：檢測文件擴展名是否合法，檢測文件中是否嵌入惡意代碼

如何檢驗有沒有解析漏洞
上傳要求（正確的）的文件類型
上傳帶有腳本的偽造成 txt,jpg 文件上傳驗證

前端檢測繞過方法
繞過前臺腳本檢測擴展名，就是將所要上傳文件的擴展名更改為符合腳本檢測規則的擴展名，通過工具，截取數據包，并將數據包中文件擴展名更改回原來的，達到繞過的目的
如果是JS腳本檢測，在本地瀏覽器客戶端禁用JS即可。可使用火狐瀏覽器的NoScript插件、IE中禁用掉JS等方式實現

檢查擴展名
在文件被上傳到服務端的時候，對于文件名的擴展名進行檢查，如果不合法，則拒絕這次上傳
檢查擴展名是否合法的時候，有兩種策略：
1.黑名單策略，文件擴展名在黑名單中的為不合法
2.白名單策略，文件擴展名不在白名單中的均為不合法
黑名單、白名單哪種更安全？
白名單策略是更加安全的，通過限制上傳類型為只有我們接受的類型，可以較好的保證安全，因為黑名單我們可以使用各種方法來進行注入和突破
原理：當瀏覽器將文件提交到服務器端的時候，服務器端會根據設定的黑白名單對瀏覽器提交上來的文件擴展名進行檢測，如果上傳的文件擴展名不符合黑白名單的限制，則不予上傳，否則上傳成功

導致文件上傳漏洞的根本原因在于服務把用戶上傳的本應是數據的內容當作了代碼，一般來說，用戶上傳的內容都會被存儲到特定的一個文件夾下，比如我們很多人習慣于放在 ./upload/ 下面要防止數據被當作代碼執行，我們可以限制web server對于特定文件夾的行為
在默認情況下，對與 .php文件Apache會當作代碼來執行，對于 html,css,js文件，則會直接由HTTP Response交給客戶端程序對于一些資源文件，比如txt，doc，rar等等，則也會以文件下載的方式傳送的客戶端。我們希望用戶上傳的東西僅僅當作資源和數據而不能當作代碼
因此可以使用服務器程序的接口來進行限制

防范文件上傳漏洞常見的幾種方法：
1.文件上傳的目錄設置為不可執行
只要web容器無法解析該目錄下面的文件，即使攻擊者上傳了腳本文件，服務器本身也不會受到影響，因此這一點至關重要。
2.判斷文件類型
在判斷文件類型時，可以結合使用MIME Type、后綴檢查等方式。在文件類型檢查中，強烈推薦白名單方式，黑名單的方式已經無數次被證明是不可靠的。此外，對于圖片的處理，可以使用壓縮函數或者resize函數，在處理圖片的同時破壞圖片中可能包含的HTML代碼。
3.使用隨機數改寫文件名和文件路徑
文件上傳如果要執行代碼，則需要用戶能夠訪問到這個文件。在某些環境中，用戶能上傳，但不能訪問。如果應用了隨機數改寫了文件名和路徑，將極大地增加攻擊的成本。再來就是像shell.php.rar.rar和crossdomain.xml這種文件，都將因為重命名而無法攻擊。
4.單獨設置文件服務器的域名
由于瀏覽器同源策略的關系，一系列客戶端攻擊將失效，比如上傳crossdomain.xml、上傳包含Javascript的XSS利用等問題將得到解決。
-------------------------------------------------------------

XSS

?

又叫CSS（Cross Site Scripting），即跨站腳本攻擊，指攻擊者在網頁中嵌入客戶端腳本，通常是JavaScript編寫的惡意代碼，當用戶使用瀏覽器被嵌入惡意代碼的網頁時，惡意代碼將會在用戶的瀏覽器上執行
產生的原因
?Web應用程序對用戶的輸入過濾不嚴而產生的

危害
網絡釣魚，包括竊取各類用戶賬號
竊取用戶cookie
竊取用戶瀏覽會話
強制彈出廣告頁面、刷流量
網頁掛馬
提升用戶權限，進一步滲透網站
傳播跨站腳本蠕蟲等

類型
反射型XSS
存儲型XSS
DOM XSS

反射型跨站腳本也稱做非持久型、參數型跨站腳本、這類型的腳本是最常見的，也是使用最為廣泛的一種
可以將惡意的腳本附加到URL地址的參數
例如：http://www.xxcc.com/search.php?key=“><script>alert(“xss”)</script>
一般使用將構造好的URL發給受害者，使受害者點擊觸發，而且只執行一次，非持久化
或者將惡意腳本附加到帶參數的輸出函數中

什么是存儲型XSS
當用戶提交一段XSS代碼后，被服務器端接收并存儲，當攻擊者再次訪問某個頁面時，這段XSS代碼被程序讀出來響應給瀏覽器，造成XSS跨站攻擊

什么情況容易出現存儲型XSS
運行用戶存儲數據的Web應用程序

存儲型XSS漏洞，一次提交之后，每當有用戶訪問這個頁面都會受到XSS攻擊，危害巨大。

手工檢測
輸入一些敏感字符，如“<、>、’、（）”，提交后查看HTML源代碼，看這些是否被轉義
全自動檢測XSS
借助于掃描工具
awvs、netsparke、appscan、burpsuit、xsser、xsscrapy、brutexssr、OWASP Xenotix

通用的補充性防御手段?
在輸出html時，加上Content Security Policy的Http Header?
（作用：可以防止頁面被XSS攻擊時，嵌入第三方的腳本文件等）
（缺陷：IE或低版本的瀏覽器可能不支持）
?2.在設置Cookie時，加上HttpOnly參數?
（作用：可以防止頁面被XSS攻擊時，Cookie信息被盜取，可兼容至IE6）?
（缺陷：網站本身的JS代碼也無法操作Cookie，而且作用有限，只能保證Cookie的安全）
?3.在開發API時，檢驗請求的Referer參數?
（作用：可以在一定程度上防止CSRF攻擊）
?（缺陷：IE或低版本的瀏覽器中，Referer參數可以被偽造）
-------------------------------------------------------------

什么是SQL注入漏洞

通過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令

SQL 注入帶來的威脅主要有如下幾點
猜解后臺數據庫，這是利用最多的方式，盜取網站的敏感信息
繞過認證，例如繞過驗證登錄網站后臺
注入可以借助數據庫的存儲過程進行提權等操作?? ?

SQL注入方法
通過字符串注入
猜測：猜表名，猜列名，猜數據庫名等等
后臺身份驗證繞過漏洞

實驗步驟：
猜字段
猜數據庫名字
猜用戶名
猜數據庫版本
猜當前操作系統
猜數據庫表名
獲取用戶名和密碼

如何防御
使用參數化的過濾性語句
輸入驗證
錯誤消息處理
加密處理
存儲過程來執行所有的查詢
使用專業的漏洞掃描工具
保數據庫安全
-------------------------------------------------------------

什么是瀏覽器安全

瀏覽器端具備安全功能

為什么提瀏覽器安全
作為客戶端，如果具備安全功能，就可以像安全軟件一樣對用戶上網起到較好的保護作用
瀏覽器安全也成為瀏覽器廠商之間競爭的底牌，能夠針對安全建立起技術門檻，以獲得競爭優勢

同源策略總結：
瀏覽器的同源策略是瀏覽器安全的基礎，理解同源策略對于客戶端腳本攻擊有著重要意義。同源策略一旦出現漏洞被繞過，也將帶來非常嚴重的后果，很多基于同源策略制定的安全方案都將失去效果

同源策略的意義
限制了來自不同源的“document”或腳本，對當前“document”讀取或設置某些屬性
舉例：
如果沒有同源策略，可能a.com的一段JS腳本，在b.com未曾加載此腳本時，也可以隨意涂改b.com的頁面（在瀏覽器的顯示中）。為了不讓瀏覽器的頁面行為發生混亂，瀏覽器提出了“Origin”（源）這一概念來自不同Origin的對象無法互相干擾

為什么瀏覽器要使用同源策略
主要目的是為了安全，瀏覽器中JS的同源策略決定了，當瀏覽器認為來自不同源時，請求被拒絕
如果沒有同源限制，在瀏覽器中的cookie等其他數據可以任意讀取，不同域下的DOM任意操作，ajax任意請求其他網站的數據，包括隱私數據

掛馬：在網頁中插入一段惡意代碼，利用瀏覽器漏洞執行任意代碼的攻擊方式，被稱為“掛馬”
“掛馬”是瀏覽器需要面對的一個主要威脅，近年來，獨立于殺毒軟件之外，瀏覽器廠商根據掛馬的特點研究出了一些對抗掛馬的技術

典型對抗掛馬的技術
多進程架構
將瀏覽器的各個功能模塊分開，各個瀏覽器實例分開，當一個進程崩潰時，不會影響到其他的的進程
Google Chrome主要進程有：瀏覽器進程、渲染進程、插件進程、擴展進程等
插件進程如flash、java、pdf等于瀏覽器進程嚴格隔離，因此不會互相影響

沙箱（Sandbox）:泛指“資源隔離類模塊”的代名詞
設計沙箱的目的：
讓不可信任的代碼運行在一定的環境中，限制不可信任的代碼訪問隔離去之外的資源
如果一定要跨越沙箱邊界產生數據交換，則只能通過指定的數據通道，比如經過封裝的API來完成，在這些API中會嚴格檢查請求的合法性

很多時候“掛馬”攻擊在實施時會在一個正常的網頁中通過<script>或者<iframe>等標簽加載一個惡意網址
除了加載惡意網址外，瀏覽器端還有沒有別的威脅
釣魚網站
詐騙網站
為了保護用戶安全，瀏覽器廠商紛紛推出各自的攔截惡意網址功能
目前各個瀏覽器的攔截惡意網址的功能都是基于“黑名單”的
-------------------------------------------------------------

什么是點擊劫持（ClickJacking）

攻擊者使用一個透明的、不可見的iframe,覆蓋在一個網頁上,然后誘使用戶在該網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上

主要有：
點擊劫持概述
攻擊者使用一個透明的、不可見的iframe,覆蓋在一個網頁上,然后誘使用戶在該網頁上進行操作，此時用戶將在不知情的情況下點擊透明的iframe頁面。通過調整iframe的位置，可以誘使用戶恰好點擊在iframe頁面的一些功能性按鈕上
Flash點擊劫持
攻擊者通過Flash構造出點擊劫持
圖片覆蓋攻擊
通過調整圖片的style使得圖片能夠覆蓋在他所指定的任意位置

觸屏劫持是一種視覺上的欺騙，如何防御？
通過禁止跨域的iframe來防范
寫一段 JS 代碼，以禁止iframe的嵌套，這種方法叫frame busting(框架破壞),如 :
if(top.location != location){
?? ?top.location = self.location;
}

其他防御方法
HTML5中iframe的sandbox屬性
IE中iframe的security屬性等，都可以限制iframe頁面中JS腳本的執行，從而使得frame busting失效
Firfox中的“Content Security Policy”以及Firfox的NoScript擴展也能有效防御觸屏劫持

觸屏劫持相對于XSS、CSRF來說，因為需要誘使用戶與頁面產生交互行為，因此實施攻擊的成本更高，在網絡犯罪中比較少見
但是，未來觸屏劫持仍然有可能被攻擊者利用在釣魚、欺詐和廣告作弊等方面，不可不察
-------------------------------------------------------------

什么是CSRF

全名：Cross Site Request Forgery（跨站點請求偽造）
攻擊者通過盜用身份，并用盜用來的身份發送惡意請求
CSRF能夠做什么?
以盜用者身份發送郵件，發消息，盜取賬號，甚至用于購買商品，虛擬貨幣轉賬等等
?造成的問題包括：個人隱私泄露以及財產安全

怎樣防御CSRF攻擊？
CSRF的防御可以從服務端和客戶端兩方面著手
防御效果是從服務端著手效果比較好
現在一般的CSRF防御也都在服務端進行
服務端進行CSRF防御
服務端的CSRF方式方法很多樣，但總的思想都是一致的，就是在客戶端頁面增加偽隨機數
在表單里增加Hash值，以認證這確實是用戶發送的請求；然后在服務器端進行Hash值驗證
方法二：驗證碼
方法三：One-Time Tokens(不同的表單包含一個不同的偽隨機值)
在實現One-Time Tokens時，需要注意一點： “并行會話的兼容”。如果用戶在一個站點上同時打開了兩個不同的表單，CSRF保護措施不應該影響到他對任何表單的提交
如果每次表單被裝入時站點生成一個偽隨機值來覆蓋以前的偽隨機值將會發生什么情況?
用戶只能成功地提交他最后打開的表單，因為所有其他的表單都含有非法的偽隨機值。必須小心操作以確保CSRF保護措施不會影響選項卡式的瀏覽或者利用多個瀏覽器窗口瀏覽一個站點
-------------------------------------------------------------

HTML5新增一些標簽和屬性，使得XSS等Web攻擊產生了新的變化

iframe的sandbox
<iframe>標簽一直以來都存在隱患，如：掛馬、XSS、點擊劫持等；瀏覽器廠商也一直在想辦法限制iframe執行腳本的權限，比如：跨窗口訪問會有限制，以及IE中支持security屬性限制腳本的執行
HTML5中，專門為iframe定義了一個新的屬性，叫sandbox。使用sandbox這一屬性后，<iframe>標簽加載的內容將被視為一個獨立的“源”，其中的腳本將被禁止執行，表單將被禁止提交，插件被禁止加載，指向其他瀏覽器對象的鏈接也會被禁止

Cross—Origin—Resource Sharing
瀏覽器的同源策略限制了腳本的跨域請求，但互聯網的發展趨勢越來越開放，因此跨域訪問的需求也變得越來越迫切，同源策略給Web開發者帶來了很多困擾
開發者不得不想方設法地實現一些“合法”的跨域技術，由此誕生了jsonp、iframe跨域等技巧，W3C委員會決定制定一個新的標準來解決日益迫切的跨域訪問問題
?