常見的Web攻擊手段,拿捏了!

Cbuc丶 2021-08-15 18:55:18 阅读数:311

本文一共[544]字,预计阅读时长:1分钟~
web 手段 拿捏

大家好,我是小菜。
一個希望能够成為 吹著牛X談架構 的男人!如果你也想成為我想成為的人,不然點個關注做個伴,讓小菜不再孤單!

本文主要介紹 互聯網中常見的 Web 攻擊手段

如有需要,可以參考

如有幫助,不忘 點贊 *

微信公眾號已開啟,小菜良記,沒關注的同學們記得關注哦!

午飯期間,讀者小李與我閑聊,談到上周去面試的過程。經典的高開低走,面試初期答的還可以,但是到後面卻不盡人意。其中有個面試問題引起了我的注意,面試官當時問小李:你知道有哪幾種常見的 Web 攻擊手段嗎?

Web 攻擊手段?對於開發程序員來說應當是隨口就來,而小李卻遮遮掩掩地只回答了 SQL注入攻擊。問了小李才得知,Web攻擊手段一般是在平時的博客上才見過,但是在開發中幾乎沒有做防護,因為他負責的產品大部分是 TB 的,所以攻擊手段平時看的時候知道,但是看過也就忘得差不多了。看到這裏的小夥伴,思考下,自己能說出幾種 Web攻擊方式,以及如何防護?如果有些許模糊,那我們這篇就來複習一下有哪幾種常見的 Web 攻擊手段~!

Web攻擊

在互聯網中,攻擊手段數不勝數,我們平時不能以自己只是普通的開發程序員而不是安全方向的開發者為理由,而不去掌握基本的 Web 攻擊手段!我們來熟悉一下有哪幾種常見的 Web 攻擊手段

常見的 Web 攻擊手段主要有 XSS 攻擊CSRF 攻擊SQL 注入攻擊DDos 攻擊文件漏洞攻擊等。這幾種攻擊方式的防護手段並不複雜,卻還是有很多企業遭受了該攻擊,朔源到頭,還是因為人為的疏忽。

一、XSS 攻擊

XSS 攻擊的全稱為 跨站脚本攻擊(Cross Site Scripting)

為什麼不叫CSS ,那是因為為了不跟層疊樣式錶(Cascading Style Sheet,CSS)混淆

XSS攻擊Web 應用中最常見到的攻擊手段之一。

跨站脚本攻擊,關鍵詞 脚本

攻擊者常常在網頁中嵌入了惡意的脚本程序,當用戶打開該網頁的時候,脚本程序便開始在客戶端的瀏覽器後臺執行,常用於盜取客戶端的 cookie,用戶名密碼,下載執行病毒的木馬程序,以及獲取客戶端 Admin 權限。

1、攻擊原理

前端常用錶單的形式向後臺提交信息

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

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

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

這個時候向後臺提交參數,由於 username 的不合法性,校驗可能不通過,服務端就重定向會該頁面,並且帶上以上參數,這個時候頁面就會彈出一個警告框:

警告框問題不是很大,是因為取决於這段脚本,如果攻擊者稍做修改,那麼性質可能就不一樣了~

甚至,攻擊者可以對URL進行操作,正常提交的地址為

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

攻擊者可以對 URL 進行編碼用來迷惑用戶:

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

2、防護手段

知道了如何攻擊,防護起來就不難,我們對症下藥即可。既然輸入的參數不合法,我們就很有必要對入參進行校驗,比如 <、>、"、"、'、' 這些特殊字符我們很有必要進行轉義與校驗。

二、CSRF 攻擊

CSRF 攻擊全稱 跨站請求偽造 (Cross site request forgery)。是一種對網站的惡意利用,我們上面說到的 XSS攻擊 是利用站點內的信任用戶,自己去觸發脚本而導致的攻擊。而 CSRF 則是通過偽裝來自受信任用戶的請求去利用受攻擊的網站。

CSRF 攻擊,關鍵詞:偽造

攻擊這盜用了訪問用戶的身份,以訪問者的名義向第三方網站發送惡意請求,常用於利用訪問者的身份發送消息,進行交易轉賬以及盜取賬號。

1、攻擊原理

image-20210814155503658

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

看到這個流程不知道你是否有所啟發,不知道屏幕前的小夥伴是否有過 QQ 被盜用的經曆,當然,有些盜用的手段與上面的流程是相似的。

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

<img src="www.xxx.com/pay?accountNum=xxxx&money=xxx" />

當你美滋滋地瀏覽圖片的時候,卻不知道此時你的賬戶上已經悄悄的少了指定金額!

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

2、防護手段

同樣知其症下其藥!防護手段如下:

CSRF 攻擊的關鍵就在於利用了用戶未過期的 Cookie,那麼為了防止 Cookie 的盜取,就需要在 Cookie 中設置 HttpOnly 屬性,這樣通過程序(XSS 攻擊)就無法讀取到 Cookie 信息,避免了攻擊者偽造 Cookie 的情况出現。

2)增加 token

該防護手段還是針對 Cookie 的盜取,由於請求中所有的用戶驗證信息都存放於 Cookie 中,因為我們抵禦 CSRF 的關鍵就在於:如何在請求中放入攻擊者所不能偽造的信息,並且該信息不能存放在 Cookie 中。那麼我們就可以在請求返回中加入一個隨機生成的 token,當請求來到時進行 token 的校驗,如果校驗不通過則認為是 CSRF 攻擊而拒絕該請求。

3)通過 Referer

根據 HTTP 協議,在 HTTP 請求頭上有一個字段叫做 referer,它記錄了該Http 請求的來源地址。在通常情况下,訪問一個安全受限的頁面的請求都來自同一個網站。

CSRF 中惡意請求是從 惡意站點 發出的,因此要防禦 CSRF 攻擊,需要對每一個請求驗證其 referer 值即可。

image-20210814161915170

三、SQL 注入攻擊

SQL注入 是程序員最經常遇到的,所謂 SQL注入,就是通過把 SQL 命令偽裝成正常的請求參數,傳遞到服務端,欺騙服務器最終執行惡意的 SQL命令,達到入侵的目的。攻擊者常常利用 SQL 注入的漏洞,來查詢非授權的關鍵信息,修改數據庫服務器的數據,改變錶結構,危害極大!

1、攻擊原理

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

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

當我們後端使用以下代碼查詢時,便會出現致命的漏洞

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()){
...
}

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

那這個時候 SQL 就會變成

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

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

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

2、防護手段

1)使用預編譯語句

預編譯語句 PreparedStatement 是 java.sql 中的一個接口,繼承自 Statement 接口。

預編譯語句和 Statement 的不同之處在於,創建 PreparedStatement 對象時就指定了 SQL 語句,該語句立即發送給 DBMS 進行編譯,當該編譯語句需要被執行時,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 語句中原有的白能量已經用占比特符 ? 替代了,變量通過 setString() 方法進行設置。

2)使用 ORM 框架

防止 SQL 注入的關鍵手段在於對一些關鍵字進行轉義,而常見的一些 ORM 框架,如 Mybatis,Hibernate等,都支持對響應的關鍵字或者特殊符號進行轉義,可以通過簡單的配置,很好的預防 SQL 注入的漏洞,降低普通開發人員進行安全編程的門檻。

四、文件上傳漏洞

很多網站都有上傳的功能,如上傳圖片、文件、壓縮包等等。而這些資源往往是保存在遠端服務器上。文件上傳攻擊指的就是攻擊者利用一些站點沒有對文件類型做很好的校驗,上傳了可執行的文件或脚本,並且通過脚本對服務器進行一定的權限操作,或是通過誘導外部用戶訪問該脚本文件,達到攻擊的目的。

當然,這種攻擊防護上也是比較簡單,為了防止用戶上傳惡意的可執行脚本文件,以及將文件上傳服務器當做免費的文件存儲服務器來使用,我們需要對上傳文件的類型進行白名單校驗,並且需要限制上傳文件的大小,上傳的文件需要進行重新命名,使攻擊這無法猜測到上傳文件的訪問路徑。

其中對上傳文件的類型進行白名單校驗,並不能單單通過後綴名稱來判斷文件的類型,因為攻擊者很有可能可以通過將可執行文件的後綴名稱改為其他可上傳的後綴名稱進行上傳,因為判斷文件類型就需要使用更加安全的方式。

很多類型的文件,其實的幾個字節內容是固定的,因此根據這幾個字節的內容,就可以確定文件類型,而這幾個字節也被成為 魔數

以上便是文件類型的魔數,然後我們通過獲取文件的文件頭與文件類型的魔數相比較來判斷文件類型

五、DDOS攻擊

DDos攻擊 又稱為 分布式拒絕服務攻擊 (Distributed Denial of Service),是目前最為强大,最難以防禦的攻擊方式之一。

在了解 DDoS 之前,我們需要先知道什麼是 DoS。最基本的 DoS 就是利用合理的客戶端請求裏占用過多的服務器資源,從而使合法用戶無法得到服務器的響應。DDoS 攻擊便是在傳統的 DoS 攻擊的基礎上產生的一類攻擊方式。傳統的 DoS攻擊一般是一對一的方式,當攻擊目標的CPU速度、內存或者網絡帶寬等各項性能指標不高的情况下,它的效果是明顯的,但隨著計算機與網絡技術的發展,計算機的處理能力顯著增加,內存不斷增大,這便使得 DoS 攻擊逐漸失去了效果。

這就跟單體應用向分布式架構的演進一樣,傳統的 DoS 演進到了分布式DoS (DDoS)

1、攻擊原理

DDoS 攻擊指的便是攻擊者借助公共網絡,將數量龐大的計算機設備聯合起來作為攻擊平臺,對一個或多個目標發動攻擊,從而達到癱瘓目標主機的目的。通常在攻擊開始之前,攻擊者會提前控制大量的用戶計算機,這類計算機稱之為 肉雞,並通過指令使大量的的肉雞在同一時刻對某個主機進行訪問,從而達到癱瘓目標主機的目的。

2、DDoS分類

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

1)SYN Flood

SYN Flood 是互聯網中最經典的攻擊方式之一,要了解該攻擊方式,我們需要從 TCP 協議連接的過程說起。眾所周知,TCP 協議在通信之前,必須先建立基於 TCP 協議的一個連接,以下是建立連接的過程:

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

  1. 第一步,客戶端發送一個包含 SYN 標識的 TCP 報文,SYN 即同步(Synchronized)的意思,SYN報文會指明客戶端的端口號以及 TCP 連接的初始序列號

  2. 第二步,服務器在收到客戶端的 SYN 報文後,會返回一個 SYN+ACK 的報文,錶示客戶端請求被接收,同時 TCP 序列號被加 1,ACK 即確認(Acknowledgment)的意思

  3. 第三步,客戶端在接收到服務端的 SYN + ACK 報文後,也會返回一個 ACK 報給服務端,同樣,TCP 的序列號加 1,這時,TCP連接便建立好了,接下來便可以進行數據通信了。

TCP 協議 是可靠的傳輸協議,在三次握手的過程中設置了一些异常處理機制。第三步中如果服務器沒有收到客戶端的 ACK 報文,服務端一般會進行重試,也就是再次發送 SYN + ACK 報文給客戶端,並且一直處於 SYN_RECV 的狀態,將客戶端加入等待列錶;另一方面,服務器在發出 SYN + ACK 報文後,會預先分配一部分資源給即將建立的 TCP 連接,這個資源在等待重試期間一直保留,由於服務器的資源有限,可以維護的等待列錶超過極限之後就不會再接收新的 SYN 報文,也就是拒絕建立新的 TCP 連接。

這個時候我們便可以說說 SYN Flood 是怎麼回事了,SYN Flood就是利用了 TCP 協議三次握手的過程來達到攻擊的目的。攻擊者偽造大量的 IP 地址給服務器發送 SYN 報文,因為偽造的 IP 地址不可能存在,也就不可能從客戶端得到任何響應,就會一直卡在第三步,服務端就得維護一個非常大的半連接等待列錶,並且不斷對這個列錶中的 IP 地址進行遍曆重試,占用了大量的系統資源。而由於服務器資源有限,惡意的連接占滿了服務器的等待隊列,導致服務器不再接收新的 SYN 請求,使正常的用戶無法完成通信。

2)DNS Query Flood

DNS Query Flood 實際上就是 UDP Flood 攻擊的一種變形,因為 DNS 服務在互聯網中具有不可替代的作用,因此一旦 DNS 服務器 癱瘓,影響將非常大!

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

3)CC 攻擊

CC(Challenge Collapsar)攻擊是基於應用層 HTTP 協議發起的攻擊,也稱為 HTTP Flood

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

以上便是常見的 Web 攻擊手段,知其然知其所以然,安全是極為重要也是極難防護的,每個開發人員都應該引起重視!

不要空談,不要貪懶,和小菜一起做個吹著牛X做架構的程序猿吧~點個關注做個伴,讓小菜不再孤單。咱們下文見!

看完不贊,都是壞蛋

今天的你多努力一點,明天的你就能少說一句求人的話!

我是小菜,一個和你一起變强的男人。

微信公眾號已開啟,小菜良記,沒關注的同學們記得關注哦!

版权声明:本文为[Cbuc丶]所创,转载请带上原文链接,感谢。 https://gsmany.com/2021/08/20210815185449807y.html