黑客攻擊與反黑客防禦

網站應用攻擊最主要的兩個手段:XSS攻擊SQL注入攻擊。此外,常用的 Web應用還包括 CSRF、Session 劫持等手段。

一、XSS 攻擊


XSS 攻擊即跨站點腳本攻擊Cross Site Script),指黑客通過篡改網頁,注入惡意 HTML 腳本,在用戶瀏覽網頁時,控制用戶瀏覽器進行惡意操作的一種攻擊方式。

常見 XSS 攻擊有兩種,第一種是反射型,用戶點擊的鏈接中被黑客嵌入了惡意腳本,達到攻擊的目的。如下圖所示:攻擊者可以採用XSS 攻擊,偷取用戶Cookie、密碼等重要數據,僞造用戶身份與 Web應用程序交互,從而盜取用戶財產、竊取情報

第二種攻擊方式是:持久型 XSS 攻擊,黑客提交含有惡意腳本的請求,保持在被攻擊的 Web 站點的數據庫中,用戶瀏覽網頁時,惡意腳本被包含在正常頁面中,達到攻擊的目的,如下圖:這種攻擊經常使用 在論壇,博客等Web應用中。

XSS 攻擊相對而言是一種“古老”的攻擊手段,但不斷的變化出新的攻擊花樣,許多以前認爲不可能用來攻擊的漏洞也逐漸被攻擊這利用,因此 XSS 防攻擊也非常複雜。

二、XSS 防禦手段


【1】消毒:XSS 攻擊者一般都是通過在請求中嵌入惡意腳本達到攻擊的目的,這些腳本一般用戶輸入中不會出現,可以對輸入進行過濾和消毒處理,即對某些 html 危險字符轉義,如">"轉義爲“&gt”,"<" 轉義爲"&It"等,就可發防止大部分攻擊。爲了避免對不必要的內容錯誤轉義,如“3<5”中的“<”需要進行文本匹配後再轉義,如“<img src=”這樣的上下文中的“<”才轉義。事實上消毒是所有網站最必備的 XSS 防攻擊手段。
【2】HttpOnly:最早由微軟提出,即瀏覽器禁止頁面 JavaScript 訪問帶有 HttpOnly 屬性的 Cookie。HttpOnly 並不是直接對抗 XSS 攻擊的,而是防止 XSS 攻擊者竊取 Cookie。對於存放敏感信息的 Cookie,如有用戶認證信息等,可通過對該 Cookie 添加 HttpOnly 屬性,避免被攻擊腳本竊取。設置如下:

response.setHeader("Set-Cookie", "cookiename=value;Path=/;Domain=domainvalue;Max-Age=seconds;HTTPOnly");

如果需要訪問Cookie 信息可以通過如下方式訪問:

Cookie cookies[]=request.getCookies();  

三、注入攻擊


注入攻擊主要有兩種,SQL 注入攻擊和 OS 注入[指程序提供了直接執行 Shell 命令的函數的場景]攻擊。SQL 注入攻擊的原理如下圖所示:攻擊者在 HTTP 請求中注入惡意 SQL 命令(drop table users),服務器用請求參數構造數據庫 SQL 命令時,惡意 SQL 被一起構造,並在數據庫中執行。

SQL 注入攻擊需要攻擊者對數據庫結構有所瞭解才能進行,攻擊者獲取數據庫表結構信息的手段有如下幾種:
【1】開源:如果網站採取開源軟件搭建,那麼網站數據庫結構就是公開的,攻擊者可以直接獲取。
【2】錯誤回顯:如果網站開啓錯誤回顯,即服務內部 500錯誤會顯示到瀏覽器上,攻擊者通過故意構造非法參數,使服務器端異常信息輸出到瀏覽器端,爲攻擊者猜測數據庫表結構提供了便利。
【3】盲注:網站關閉錯誤回顯,攻擊者根據網頁變化情況判斷 SQL 語句的執行情況,據此猜測數據庫結構,此方法難度較大。

四、SQL 注入防禦措施


首先避免被攻擊者猜測到表名等數據庫表結構信息:
【1】消毒:和防止 XSS 攻擊一樣,請求參數消毒是一種比較有效的手段。通過正則匹配,過濾請求數據中可能注入的 SQL。
【2】參數綁定:使用預編譯手段,綁定參數是最好的防 SQL 注入方法,目前許多數據訪問層框架,如 MyBatis,Hibernate等,都實現 SQL 預編譯和參數綁定,攻擊者的惡意 SQL 會被當做 SQL 的參數,而不是 SQL 命令被執行。
除了 SQL 注入,攻擊者還根據具體應用,注入 OS 命令,編程語言代碼等,利用程序漏洞,達到攻擊目的。

五、CSRF 攻擊


CSRF(Cross Site Request Forgery跨站點請求僞造),攻擊者通過跨站請求,以合法用戶的身份進行非法操作,如轉賬交易、發表評論等,如下圖所示:CSRF 的主要手段是利用跨站點請求,在用戶不知情的情況下,以用戶的身份僞造請求,其核心是利用了瀏覽器Cookie 或服務器 Session 策略,盜取用戶身份。

響應地,CSRF 的防禦手段主要是識別請求者身份。主要有以下幾種方法:
  ■  表單 Token:CSRF 是一個僞造用戶請求的操作,所有需要構造用戶請求的所有參數纔可以。表單 Token 通過在請求參數中增加隨機數的辦法來阻止攻擊者獲得所有請求參數:在頁面表單中增加一個隨機數作爲 Token,每次響應頁面的 Token 都不同,從正常頁面提交的請求會包含該 Token 值,而僞造的請求無法獲得該值,服務器檢查請求參數中 Token 的值是否存在並且正確以確定提交者是否合法。
  ■ 驗證碼:相對說來,驗證碼更加簡單有效,即請求提交時,需要用戶輸入驗證碼,以避免在用戶不知情的情況下被攻擊者僞造請求。但是輸入驗證碼是一個糟糕的用戶體驗,所以請在必要時使用,如支付交易等關鍵頁面。
  ■ Referer checkHTTP 請求頭的 Referer 域中記錄着請求來源,可通過檢查請求來源,驗證其是否合法,很多網站使用這個功能實現圖片防盜鏈(如果圖片訪問的頁面來源不是自己網站的網頁就拒絕)。空 Referer是指 Referer頭部的內容爲空,或者一個HTTP 請求頭中根本不包含Referer,那麼什麼時候HTTP請求會不包含Referer字段呢?根據 Referer的定義,它的作用是指示一個請求是從哪裏鏈接過來,那麼當一個請求並不是由鏈接觸發產生的,那麼自然也就不需要指定這個請求的鏈接來源。比如,直接在瀏覽器的地址欄中輸入一個資源的URL地址,那麼這種請求是不會包含Referer字段的,因爲這是一個“憑空產生”的HTTP請求,並不是從一個地方鏈接過去的。

1、None:絕不允許referrer data通過
標籤寫法:<meta name="referrer" content="none">

2、None When Downgrade:發送referrer信息去安全的HTTPS站點,而非不穩定的HTTP站點。
標籤寫法:<meta name="referrer" content="none-when-downgrade">

3、Origin Only: 發送協議、主機和端口(即子域)沒有一個完整的URL作爲來源,
即https://moz.com/example.html只會發送https://moz.com
標籤寫法:<meta name="referrer" content="origin">

4、Origin When Cross-Origin: 當傳origin-only來路信息發送給外部站點時,如果目標有相同的協議、主機和端口(即子域),無論它是HTTP或HTTPS,都將全部的URL作爲Referrer發送出去。(註解:官方說明書上有一處排印錯誤,將來的版本應該是"origin-when-cross-origin")
標籤寫法:<meta name="referrer" content="origin-when-crossorigin">

5、Unsafe URL: 總是將URL字串作爲一個referrer通過。
注意:如果你的URL中存在任何敏感信息,這不是最安全的選擇。其中URL的片段、用戶名、密碼被自動剝去。
標籤寫法:<meta name="referrer" content="unsafe-url">

六、其他攻擊和漏洞


【1】Error Code:也稱作錯誤回顯,許多 Web 服務器默認是打開異常信息輸出的,即服務器端未處理的異常堆棧信息直接輸出到客戶端瀏覽器,這種方式雖然對程序調試和錯誤報告有好處,但同時也給黑客可乘之機。通過故意製造非法輸入,使系統運行時出錯,獲得異常信息,從而尋找系統漏洞進行攻擊。防禦手段也簡單,通過配置 Web服務器參數,跳轉500頁面到專門的頁面即可,Web 應用常用的 MVC 框架也有着這個功能。

<!-- 僅僅在調試的時候注視掉,在正式部署的時候不能註釋 -->  
<!-- 這樣配置也是可以的,表示發生500錯誤的時候,轉到500.jsp頁面處理。 -->  
<error-page>   
	<error-code>500</error-code>   
	<location>/500.html</location>   
</error-page>   
  
<!-- 這樣的配置表示如果jsp頁面或者servlet發生java.lang.Exception類型(當然包含子類)的異常就會轉到500.jsp頁面處理。 -->  
<error-page>   
	<exception-type>java.lang.Exception</exception-type>   
	<location>/500.jsp</location>   
</error-page>   

【2】HTML 註釋:爲了調試方便,有時候開發人員會在 JSP 等服務器頁面程序中使用 HTML 註釋語法進行註釋,這些 HTML 註釋會顯示在客戶端瀏覽器,給黑客造成攻擊便利。程序最終發佈前需要進行代碼 review 或自動掃描,避免 HTML 註釋漏洞。
【3】文件上傳:一般網站都有文件上傳功能,設置頭像、分享視頻、上傳附件等。如果上傳的是可執行程序並通過該程序獲得服務器端執行能力,那麼攻擊者幾乎可以在服務器上爲所欲爲,並以此爲跳板攻擊集羣環境的其他機器。最有效的預防手段是設置上傳文件白名單,只允許上傳可靠的文件類型。此外還可以修改文件名、使用專門的存儲等手段,保護服務器受上傳文件攻擊。
【4】路徑遍歷:攻擊者在請求的 URL 中使用相對路徑,遍歷系統未開放的目錄和文件防禦方法主要是將 JS、CSS 等資源文件部署在獨立服務器、使用獨立域名,其他文件不使用靜態 URL 訪問,動態參數不包含文件路徑信息。

七、Web 應用防火牆


網站面臨的安全問題複雜多樣,各種攻擊手段日新月異,新型漏洞不斷被報告。如果有一款產品能夠統一攔截請求,過濾惡意參數,自動消毒、添加Token,並且能夠根據最新攻擊和漏洞情報,不斷升級對策,處理掉大多數令人頭疼的網站攻擊,就是一件很美妙的事了。比如 ModSecurity 產品,採用處理邏輯與攻擊規則集合分離的架構模式處理邏輯(執行引擎)負責請求和響應的攔截過濾,規則加載執行等功能。而攻擊規則集合則負責描述對具體攻擊的規則定義、模式識別、防禦策略等功能。處理邏輯比較穩定,規則集合需要不斷針對漏洞進行升級,這是一種可擴展的架構設計。除了開源的 ModSecurity,還有一些商業產品也實現 Web 應用防火牆功能,如 NEC 的 SiteShell和 naxsi爲 Nginx 提供的 WAF。目前已經支持 Nginx和 IIS,配合 Nginx的靈活和高效,可以打造成生產級的WAF,是保護和審覈 Web安全的利器。

八、網站安全漏洞掃描


和計算機漏洞掃描一樣,網站也需要安全漏洞掃描。網站安全漏洞掃描工具是根據內置規則,構造具有攻擊性的 URL請求,模擬黑客攻擊行爲,用以發現網站安全漏洞工具。許多大型網站的安全團隊都有自己開發的漏洞掃描工具,不定期地掃描,查漏補缺。市場上也有很多商用的網站安全漏洞掃描平臺。

----如果喜歡,點個  紅心♡  支持以下,謝謝----

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章