Web攻擊

在互聯(lián)網(wǎng)中，攻擊手段數(shù)不勝數(shù)，我們平時不能以自己只是普通的開發(fā)程序員而不是安全方向的開發(fā)者為理由，而不去掌握基本的 Web 攻擊手段！我們來熟悉一下有哪幾種常見的 Web 攻擊手段

常見的 Web 攻擊手段主要有 XSS 攻擊、CSRF 攻擊、SQL 注入攻擊、DDos 攻擊、文件漏洞攻擊等。這幾種攻擊方式的防護(hù)手段并不復(fù)雜，卻還是有很多企業(yè)遭受了該攻擊，朔源到頭，還是因為人為的疏忽。

一、XSS 攻擊

XSS 攻擊的全稱為 跨站腳本攻擊（Cross Site Scripting）

為什么不叫CSS ，那是因為為了不跟層疊樣式表（Cascading Style Sheet，CSS）混淆

XSS攻擊 是 Web 應(yīng)用中最常見到的攻擊手段之一。

跨站腳本攻擊，關(guān)鍵詞 腳本。

攻擊者常常在網(wǎng)頁中嵌入了惡意的腳本程序，當(dāng)用戶打開該網(wǎng)頁的時候，腳本程序便開始在客戶端的瀏覽器后臺執(zhí)行，常用于盜取客戶端的 cookie，用戶名密碼，下載執(zhí)行病毒的木馬程序，以及獲取客戶端 Admin 權(quán)限。

1、攻擊原理

前端常用表單的形式向后臺提交信息

input type="text" name="username" value="cbuc" />

很普通的一段html代碼，向后臺提交 username 的信息，正常情況下，用戶一般會輸入自己的 username，這個時候毫無問題，但是在不正常的情況下，用戶輸入的不是一個正常的字符串，而是 "/>script> alert("bingo") /script>!- 。按這個時候表單的內(nèi)容就會變成

input type="text" name="username" value=""/>script> alert("bingo") /script>!-" />

這個時候向后臺提交參數(shù)，由于 username 的不合法性，校驗可能不通過，服務(wù)端就重定向會該頁面，并且?guī)弦陨蠀?shù)，這個時候頁面就會彈出一個警告框：

警告框問題不是很大，是因為取決于這段腳本，如果攻擊者稍做修改，那么性質(zhì)可能就不一樣了~

甚至，攻擊者可以對URL進(jìn)行操作，正常提交的地址為

www.xxx.com/login?username="/>script> alert("bingo") /script>!-"

攻擊者可以對 URL 進(jìn)行編碼用來迷惑用戶：

www.xxx.com/login?username="%2F%3E%3Cscript%3E%20alert(%22bingo%22)%20%3C%2Fscript%3E%3C!-"

2、防護(hù)手段

知道了如何攻擊，防護(hù)起來就不難，我們對癥下藥即可。既然輸入的參數(shù)不合法，我們就很有必要對入?yún)⑦M(jìn)行校驗，比如 、>、"、"、'、' 這些特殊字符我們很有必要進(jìn)行轉(zhuǎn)義與校驗。

二、CSRF 攻擊

CSRF 攻擊全稱 跨站請求偽造 (Cross site request forgery)。是一種對網(wǎng)站的惡意利用，我們上面說到的 XSS攻擊 是利用站點內(nèi)的信任用戶，自己去觸發(fā)腳本而導(dǎo)致的攻擊。而 CSRF 則是通過偽裝來自受信任用戶的請求去利用受攻擊的網(wǎng)站。

CSRF 攻擊，關(guān)鍵詞：偽造。

攻擊這盜用了訪問用戶的身份，以訪問者的名義向第三方網(wǎng)站發(fā)送惡意請求，常用于利用訪問者的身份發(fā)送消息，進(jìn)行交易轉(zhuǎn)賬以及盜取賬號。

1、攻擊原理

受害者首先在信任站點完成了登錄，并且生成了 Cookie，Cookie會在瀏覽器保存一定的時間。到這一步，用戶如果在沒有登出 信任站點 的情況下，訪問了 惡意站點，這個時候 惡意站點 就會向 信任站點 發(fā)起請求，這個請求就會帶上以上生成的 Cookie，當(dāng)惡意請求來到 信任站點，信任站點 看到請求攜帶的 Cookie，就會判斷該請求是 受害者 發(fā)出的。因此 信任站點 就會根據(jù) 受害者 的權(quán)限來完成 惡意請求 的指令，而這個指令可能是利用 受害者 的身份發(fā)送消息，轉(zhuǎn)賬支付等等操作，這樣 惡意站點 就達(dá)到了偽造 受害者 請求 信任站點 的目的。

看到這個流程不知道你是否有所啟發(fā)，不知道屏幕前的小伙伴是否有過 QQ 被盜用的經(jīng)歷，當(dāng)然，有些盜用的手段與上面的流程是相似的。

該攻擊手段在日常中十分常見。如果某個支付系統(tǒng)的轉(zhuǎn)賬地址為 www.xxx.com/pay?accountNum=xxxxmoney=xxx。其中 accountNum 為轉(zhuǎn)賬目的的賬戶，money 為轉(zhuǎn)賬金額。那這個時候如果你剛巧登錄過了該支付系統(tǒng)，又沒有及時的登出，在訪問惡意站點的時候，如果你點開了某張圖片，而圖片的地址為 ：

img src="www.xxx.com/pay?accountNum=xxxxmoney=xxx" />

當(dāng)你美滋滋地瀏覽圖片的時候，卻不知道此時你的賬戶上已經(jīng)悄悄的少了指定金額！

這就是因為你沒有及時的登出支付系統(tǒng)，而又點擊了 惡意站點的 惡意鏈接，攜帶了你未過期的 Cookie，成功竊取了你的金額。

2、防護(hù)手段

同樣知其癥下其藥！防護(hù)手段如下：

1）將 cookie 設(shè)置為 HttpOnly

CSRF 攻擊的關(guān)鍵就在于利用了用戶未過期的 Cookie，那么為了防止 Cookie 的盜取，就需要在 Cookie 中設(shè)置 HttpOnly 屬性，這樣通過程序（XSS 攻擊）就無法讀取到 Cookie 信息，避免了攻擊者偽造 Cookie 的情況出現(xiàn)。

2）增加 token

該防護(hù)手段還是針對 Cookie 的盜取，由于請求中所有的用戶驗證信息都存放于 Cookie 中，因為我們抵御 CSRF 的關(guān)鍵就在于：如何在請求中放入攻擊者所不能偽造的信息，并且該信息不能存放在 Cookie 中。那么我們就可以在請求返回中加入一個隨機(jī)生成的 token，當(dāng)請求來到時進(jìn)行 token 的校驗，如果校驗不通過則認(rèn)為是 CSRF 攻擊而拒絕該請求。

3）通過 Referer

根據(jù) HTTP 協(xié)議，在 HTTP 請求頭上有一個字段叫做 referer，它記錄了該Http 請求的來源地址。在通常情況下，訪問一個安全受限的頁面的請求都來自同一個網(wǎng)站。

在 CSRF 中惡意請求是從 惡意站點 發(fā)出的，因此要防御 CSRF 攻擊，需要對每一個請求驗證其 referer 值即可。

三、SQL 注入攻擊

SQL注入 是程序員最經(jīng)常遇到的，所謂 SQL注入，就是通過把 SQL 命令偽裝成正常的請求參數(shù)，傳遞到服務(wù)端，欺騙服務(wù)器最終執(zhí)行惡意的 SQL命令，達(dá)到入侵的目的。攻擊者常常利用 SQL 注入的漏洞，來查詢非授權(quán)的關(guān)鍵信息，修改數(shù)據(jù)庫服務(wù)器的數(shù)據(jù)，改變表結(jié)構(gòu)，危害極大！

1、攻擊原理

我們查詢用戶存不存在往往是通過以下 SQL：

SELECT * FROM s_user WHERE username = '' and password = '' 

當(dāng)我們后端使用以下代碼查詢時，便會出現(xiàn)致命的漏洞

Connection  con = getConnection();
Statement st = (Statement) con.createStatement();
String sql = "SELECT * FROM s_user WHERE username = '"+ username +"' and password = '"+ passward+"' ";
ResultSet rs = st.executeQuery(sql);
while(rs.next()){
    ...
}

上面代碼邏輯便是利用前端傳入的參數(shù)進(jìn)行數(shù)據(jù)庫查詢，乍看之下感覺毫無問題，但是這個時候如果 password 前端傳過來的值是 ' or '1'='1

那這個時候 SQL 就會變成

SELECT * FROM s_user WHERE username = '' and password = '' or '1'='1' 

這樣的 SQL 不用試都知道會把數(shù)據(jù)庫中的用戶全都查出來，明明沒有輸入正確的密碼，卻返回了登錄成功。而這便是一次簡單且典型的 SQL 注入攻擊。

' or '1'='1 危害是讓用戶免密碼登錄，如果傳過來的值為 '; drop table xxx; -- 這個時候問題就大了！

2、防護(hù)手段

1）使用預(yù)編譯語句

預(yù)編譯語句 PreparedStatement 是 java.sql 中的一個接口，繼承自 Statement 接口。

預(yù)編譯語句和 Statement 的不同之處在于，創(chuàng)建 PreparedStatement 對象時就指定了 SQL 語句，該語句立即發(fā)送給 DBMS 進(jìn)行編譯，當(dāng)該編譯語句需要被執(zhí)行時，DBMS 直接運行編譯后的 SQL 語句，而不需要像其他 SQL 語句那樣先將其編譯：

String sql = "SELECT * FROM s_user WHERE username = ? and password = ? ";
PreparedStatement st = conn.preparedStatement(sql);
st.setString(1, username);
st.setString(2, password);
ResultSet rs = st.executeQUery();

可以看到，SQL 語句中原有的白能量已經(jīng)用占位符 ？ 替代了，變量通過 setString() 方法進(jìn)行設(shè)置。

2）使用 ORM 框架

防止 SQL 注入的關(guān)鍵手段在于對一些關(guān)鍵字進(jìn)行轉(zhuǎn)義，而常見的一些 ORM 框架，如 Mybatis，Hibernate等，都支持對響應(yīng)的關(guān)鍵字或者特殊符號進(jìn)行轉(zhuǎn)義，可以通過簡單的配置，很好的預(yù)防 SQL 注入的漏洞，降低普通開發(fā)人員進(jìn)行安全編程的門檻。

四、文件上傳漏洞

很多網(wǎng)站都有上傳的功能，如上傳圖片、文件、壓縮包等等。而這些資源往往是保存在遠(yuǎn)端服務(wù)器上。文件上傳攻擊指的就是攻擊者利用一些站點沒有對文件類型做很好的校驗，上傳了可執(zhí)行的文件或腳本，并且通過腳本對服務(wù)器進(jìn)行一定的權(quán)限操作，或是通過誘導(dǎo)外部用戶訪問該腳本文件，達(dá)到攻擊的目的。

當(dāng)然，這種攻擊防護(hù)上也是比較簡單，為了防止用戶上傳惡意的可執(zhí)行腳本文件，以及將文件上傳服務(wù)器當(dāng)做免費的文件存儲服務(wù)器來使用，我們需要對上傳文件的類型進(jìn)行白名單校驗，并且需要限制上傳文件的大小，上傳的文件需要進(jìn)行重新命名，使攻擊這無法猜測到上傳文件的訪問路徑。

其中對上傳文件的類型進(jìn)行白名單校驗，并不能單單通過后綴名稱來判斷文件的類型，因為攻擊者很有可能可以通過將可執(zhí)行文件的后綴名稱改為其他可上傳的后綴名稱進(jìn)行上傳，因為判斷文件類型就需要使用更加安全的方式。

很多類型的文件，其實的幾個字節(jié)內(nèi)容是固定的，因此根據(jù)這幾個字節(jié)的內(nèi)容，就可以確定文件類型，而這幾個字節(jié)也被成為 魔數(shù)

以上便是文件類型的魔數(shù)，然后我們通過獲取文件的文件頭與文件類型的魔數(shù)相比較來判斷文件類型

五、DDOS攻擊

DDos攻擊 又稱為 分布式拒絕服務(wù)攻擊 (Distributed Denial of Service)，是目前最為強(qiáng)大，最難以防御的攻擊方式之一。

在了解 DDoS 之前，我們需要先知道什么是 DoS。最基本的 DoS 就是利用合理的客戶端請求里占用過多的服務(wù)器資源，從而使合法用戶無法得到服務(wù)器的響應(yīng)。DDoS 攻擊便是在傳統(tǒng)的 DoS 攻擊的基礎(chǔ)上產(chǎn)生的一類攻擊方式。傳統(tǒng)的 DoS攻擊一般是一對一的方式，當(dāng)攻擊目標(biāo)的CPU速度、內(nèi)存或者網(wǎng)絡(luò)帶寬等各項性能指標(biāo)不高的情況下，它的效果是明顯的，但隨著計算機(jī)與網(wǎng)絡(luò)技術(shù)的發(fā)展，計算機(jī)的處理能力顯著增加，內(nèi)存不斷增大，這便使得 DoS 攻擊逐漸失去了效果。

這就跟單體應(yīng)用向分布式架構(gòu)的演進(jìn)一樣，傳統(tǒng)的 DoS 演進(jìn)到了分布式DoS (DDoS) 。

1、攻擊原理

DDoS 攻擊指的便是攻擊者借助公共網(wǎng)絡(luò)，將數(shù)量龐大的計算機(jī)設(shè)備聯(lián)合起來作為攻擊平臺，對一個或多個目標(biāo)發(fā)動攻擊，從而達(dá)到癱瘓目標(biāo)主機(jī)的目的。通常在攻擊開始之前，攻擊者會提前控制大量的用戶計算機(jī)，這類計算機(jī)稱之為 肉雞，并通過指令使大量的的肉雞在同一時刻對某個主機(jī)進(jìn)行訪問，從而達(dá)到癱瘓目標(biāo)主機(jī)的目的。

2、DDoS分類

DDoS 是一種攻擊手段，其中又分為好幾種 DDoS攻擊

1）SYN Flood

SYN Flood 是互聯(lián)網(wǎng)中最經(jīng)典的攻擊方式之一，要了解該攻擊方式，我們需要從 TCP 協(xié)議連接的過程說起。眾所周知，TCP 協(xié)議在通信之前，必須先建立基于 TCP 協(xié)議的一個連接，以下是建立連接的過程：

這是一張非常建議的 TCP 三次握手的過程。

1. 第一步，客戶端發(fā)送一個包含 SYN 標(biāo)識的 TCP 報文，SYN 即同步（Synchronized）的意思，SYN報文會指明客戶端的端口號以及 TCP 連接的初始序列號
2. 第二步，服務(wù)器在收到客戶端的 SYN 報文后，會返回一個 SYN+ACK 的報文，表示客戶端請求被接收，同時 TCP 序列號被加 1，ACK 即確認(rèn)（Acknowledgment）的意思
3. 第三步，客戶端在接收到服務(wù)端的 SYN + ACK 報文后，也會返回一個 ACK 報給服務(wù)端，同樣，TCP 的序列號加 1，這時，TCP連接便建立好了，接下來便可以進(jìn)行數(shù)據(jù)通信了。

TCP 協(xié)議 是可靠的傳輸協(xié)議，在三次握手的過程中設(shè)置了一些異常處理機(jī)制。第三步中如果服務(wù)器沒有收到客戶端的 ACK 報文，服務(wù)端一般會進(jìn)行重試，也就是再次發(fā)送 SYN + ACK 報文給客戶端，并且一直處于 SYN_RECV 的狀態(tài)，將客戶端加入等待列表；另一方面，服務(wù)器在發(fā)出 SYN + ACK 報文后，會預(yù)先分配一部分資源給即將建立的 TCP 連接，這個資源在等待重試期間一直保留，由于服務(wù)器的資源有限，可以維護(hù)的等待列表超過極限之后就不會再接收新的 SYN 報文，也就是拒絕建立新的 TCP 連接。

這個時候我們便可以說說 SYN Flood 是怎么回事了，SYN Flood就是利用了 TCP 協(xié)議三次握手的過程來達(dá)到攻擊的目的。攻擊者偽造大量的 IP 地址給服務(wù)器發(fā)送 SYN 報文，因為偽造的 IP 地址不可能存在，也就不可能從客戶端得到任何響應(yīng)，就會一直卡在第三步，服務(wù)端就得維護(hù)一個非常大的半連接等待列表，并且不斷對這個列表中的 IP 地址進(jìn)行遍歷重試，占用了大量的系統(tǒng)資源。而由于服務(wù)器資源有限，惡意的連接占滿了服務(wù)器的等待隊列，導(dǎo)致服務(wù)器不再接收新的 SYN 請求，使正常的用戶無法完成通信。

2）DNS Query Flood

DNS Query Flood 實際上就是 UDP Flood 攻擊的一種變形，因為 DNS 服務(wù)在互聯(lián)網(wǎng)中具有不可替代的作用，因此一旦 DNS 服務(wù)器 癱瘓，影響將非常大！

DNS Query Flood 攻擊采用的方法是向被攻擊的服務(wù)器發(fā)送海量的域名解析請求。而這部分請求解析的域名一般都是隨機(jī)生成的，大部分不存在，并且通過偽造端口和客戶端IP，防止查詢請求被 ACL（訪問控制列表）過濾。被攻擊的 DNS服務(wù)器 在收到域名解析的請求后，首先會在自己的服務(wù)器上查找是否該域名的 IP，因為域名的不存在，在自身自然是找不到的，因此DNS 服務(wù)器便會向上層的 DNS服務(wù)器遞歸查詢域名，直到全球互聯(lián)網(wǎng)的 13臺 根DNS服務(wù)器。大量不存在的域名解析請求給服務(wù)器帶來了很大的負(fù)載，當(dāng)解析請求超過一定量級的時候，就會造成 DNS服務(wù)器 解析域名超時，使正常的域名都查詢不到對應(yīng)的 IP，達(dá)到了攻擊的效果。

3）CC 攻擊

CC（Challenge Collapsar）攻擊是基于應(yīng)用層 HTTP 協(xié)議發(fā)起的攻擊，也稱為 HTTP Flood

CC攻擊的原理是通過控制大量的 “肉雞” 或者利用從互聯(lián)網(wǎng)上搜尋的大量匿名的 HTTP 代理，模擬正常用戶給網(wǎng)站發(fā)起請求直到該網(wǎng)站拒絕服務(wù)為止。大部分網(wǎng)站會通過 CDN 以及分布式緩存來加快服務(wù)端的響應(yīng)，提高網(wǎng)站的吞吐量。而這些惡意的 HTTP 請求會有意的避開這些緩存，需要進(jìn)行多次 DB 查詢操作或者一次請求會返回大量的數(shù)據(jù)，加速系統(tǒng)資源的消耗，從而拖垮后端的業(yè)務(wù)處理系統(tǒng)。

以上便是常見的 Web 攻擊手段，知其然知其所以然，安全是極為重要也是極難防護(hù)的，每個開發(fā)人員都應(yīng)該引起重視！更多關(guān)于web攻擊手段的資料請關(guān)注腳本之家其它相關(guān)文章！