一、SQL注入攻擊

SQL 注入攻擊主要是由于程序員在開(kāi)發(fā)過(guò)程中沒(méi)有對(duì)客戶(hù)端所傳輸?shù)椒?wù)器端的參數(shù)進(jìn)行嚴(yán)格的安全檢查，同時(shí) SQL 語(yǔ)句的執(zhí)行引用了該參數(shù)，并且 SQL 語(yǔ)句采用字符串拼接的方式執(zhí)行時(shí)，攻擊者將可能在參數(shù)中插入惡意的 SQL 查詢(xún)語(yǔ)句，導(dǎo)致服務(wù)器執(zhí)行了該惡意 SQL 語(yǔ)句。

SQL 注入可能造成的危害有：網(wǎng)頁(yè)、數(shù)據(jù)被篡改，核心數(shù)據(jù)被竊取，數(shù)據(jù)庫(kù)所在的服務(wù)器被攻擊，變成傀儡主機(jī)。

1.測(cè)試方法

在需要進(jìn)行查詢(xún)的頁(yè)面，輸入正確查詢(xún)條件 and 1=1 等簡(jiǎn)單 sql 語(yǔ)句，查看應(yīng)答結(jié)果，如與輸入正確查詢(xún)條件返回結(jié)果一致，表明應(yīng)用程序?qū)τ脩?hù)輸入未進(jìn)行過(guò)濾，可以初步判斷此處存在 SQL 注入漏洞。

2.防止sql注入

（1）JBDC 方式查詢(xún)，我們可以利用 PreparedStatement，這樣不光能提升查詢(xún)效率，而且他的 set 方法已經(jīng)為我們處理好了 sql 注入的問(wèn)題。

（2）hibernate 方式查詢(xún)，我們利用 name：parameter 方式查詢(xún)，例如利用 find(String queryString, Object value…Object value) 方法查詢(xún)，就可以避免 sql 注入.

（3）在查詢(xún)方法中我們檢查 sql，將非法字符轉(zhuǎn)換，導(dǎo)致 sql 注入的字符串，過(guò)濾掉或者轉(zhuǎn)化。

（4）在頁(yè)面中限制，我們通過(guò) js 設(shè)置，不讓用戶(hù)輸入非法字符。

（5）攔截請(qǐng)求的每一個(gè)參數(shù)，并將這個(gè)參數(shù)的非法字符轉(zhuǎn)化，下面的為提交的參數(shù)中沒(méi)有附件的，實(shí)現(xiàn)方式。首先在 web.xml 配置文件中添加這個(gè)類(lèi)的 filter，繼承類(lèi) HttpServletRequestWrapper,如圖

（6）攔截請(qǐng)求的每一個(gè)參數(shù)，并將這個(gè)參數(shù)的非法字符轉(zhuǎn)化，下面的為提交的參數(shù)中 有含附件的，實(shí)現(xiàn)方式。在 xml 中配置上傳的時(shí)候，配置這個(gè)類(lèi).繼承類(lèi) CommonsMultipartResolver 如圖

（7）使用服務(wù)器安全狗，安裝好網(wǎng)頁(yè)安全狗和服務(wù)器安全狗，可以有效的避免 sql 被注入入侵的風(fēng)險(xiǎn)，如果有更高級(jí)的需求還可以聯(lián)系安全狗可以提供更為強(qiáng)大的云安全服務(wù)，幫助用戶(hù)抵御外來(lái)入侵。

二、CSRF跨站偽造請(qǐng)求

CSRF（Cross-Site Request Forgery，跨站點(diǎn)偽造請(qǐng)求）是一種網(wǎng)絡(luò)攻擊方式，該攻擊可以在用戶(hù)毫不知情的情況下以用戶(hù)自身的名義偽造請(qǐng)求發(fā)送給受攻擊站點(diǎn)，從而在未授權(quán)的情況下執(zhí)行在權(quán)限保護(hù)之下的操作。具體來(lái)講，可以這樣理解 CSRF 攻擊：攻擊者盜用了你的身份，以你的名義發(fā)送惡意請(qǐng)求，對(duì)服務(wù)器來(lái)說(shuō)這個(gè)請(qǐng)求是完全合法的。

CSRF攻擊攻擊原理及過(guò)程如下：

1.用戶(hù) C 打開(kāi)瀏覽器，訪問(wèn)受信任網(wǎng)站 A，輸入用戶(hù)名和密碼請(qǐng)求登錄網(wǎng)站 A；

2.在用戶(hù)信息通過(guò)驗(yàn)證后，網(wǎng)站 A 產(chǎn)生 Cookie 信息并返回給瀏覽器，此時(shí)用戶(hù)登錄網(wǎng)站 A 成功，可以正常發(fā)送請(qǐng)求到網(wǎng)站 A；

3.用戶(hù)未退出網(wǎng)站 A 之前，在同一瀏覽器中，打開(kāi)一個(gè) TAB 頁(yè)訪問(wèn)網(wǎng)站 B；

4.網(wǎng)站 B 接收到用戶(hù)請(qǐng)求后，返回一些攻擊性代碼，并發(fā)出一個(gè)請(qǐng)求要求訪問(wèn)第三方站點(diǎn) A；

5.瀏覽器在接收到這些攻擊性代碼后，根據(jù)網(wǎng)站 B 的請(qǐng)求，在用戶(hù)不知情的情況下攜帶 Cookie 信息，向網(wǎng)站 A 發(fā)出請(qǐng)求。網(wǎng)站 A 并不知道該請(qǐng)求其實(shí)是由 B 發(fā)起的，所以會(huì)根據(jù)用戶(hù) C 的 Cookie 信息以 C 的權(quán)限處理該請(qǐng)求，導(dǎo)致來(lái)自網(wǎng)站 B 的惡意代碼被執(zhí)行。

測(cè)試方法

同個(gè)瀏覽器打開(kāi)兩個(gè)頁(yè)面，一個(gè)頁(yè)面權(quán)限失效后，另一個(gè)頁(yè)面是否可操作成功；

使用工具發(fā)送請(qǐng)求，在 http 請(qǐng)求頭中不加入 referer 字段，檢驗(yàn)返回消息的應(yīng)答。

防御 CSRF 攻擊

比如請(qǐng)求的 Referer 是指向黑客自己的網(wǎng)站 B 而不是網(wǎng)站 A。因此，要防御 CSRF 攻擊，網(wǎng)站 A 只需要對(duì)于每一個(gè)請(qǐng)求驗(yàn)證其 Referer 值，如果是 A 網(wǎng)站的域名，則說(shuō)明該請(qǐng)求是來(lái)自己的請(qǐng)求，是合法的。如果 Referer 是其他網(wǎng)站的話，則有可能是黑客的 CSRF 攻擊，拒絕該請(qǐng)求。

Referer 的值是由瀏覽器提供的，并不能保證瀏覽器自身沒(méi)有安全漏洞。對(duì)于某些瀏覽器，目前已經(jīng)有一些方法可以篡改 Referer 值，黑客完全可以修改 Referer 值，這樣就可以通過(guò)驗(yàn)證，從而進(jìn)行 CSRF 攻擊?？稍谡?qǐng)求中添加 token 并驗(yàn)證。

三、XSS跨站腳本攻擊

由于 web 程序?qū)τ脩?hù)的輸入過(guò)濾不足，導(dǎo)致用戶(hù)輸入的惡意 HTML/Javascript 代碼注入到網(wǎng)頁(yè)中，混淆原有語(yǔ)義，產(chǎn)生新的惡意語(yǔ)句。在其他用戶(hù)訪問(wèn)網(wǎng)頁(yè)時(shí)，瀏覽器就會(huì)觸發(fā)惡意的網(wǎng)頁(yè)代碼，從而達(dá)到 XSS 攻擊的目的。

XSS(Cross Site Script)，與 SQL 注入相似，XSS 是通過(guò)網(wǎng)頁(yè)插入惡意腳本，主要用到的技術(shù)也是前端的 HTML 和 JavaScript 腳本。當(dāng)用戶(hù)瀏覽網(wǎng)頁(yè)時(shí)，實(shí)現(xiàn)控制用戶(hù)瀏覽器行為的攻擊方式。一次成功的 XSS，可以獲取到用戶(hù)的 cookie，利用該 cookie 盜取用戶(hù)對(duì)該網(wǎng)站的操作權(quán)限；也可以獲取到用戶(hù)聯(lián)系人列表，利用被攻擊者的身份向特定的目標(biāo)群發(fā)送大量的垃圾信息，等等。

XSS 分為三類(lèi)：存儲(chǔ)型 (持久性 XSS)、反射型 (非持久性 XSS)、DOM 型。所造成的影響主要是竊取用戶(hù)登錄憑證（Cookies）、掛馬攻擊、頁(yè)面訪問(wèn)挾持等。

1.持久型跨站：最直接的危害類(lèi)型，跨站代碼存儲(chǔ)在服務(wù)器（數(shù)據(jù)庫(kù)）。

攻擊者把惡意腳本注入服務(wù)器并存儲(chǔ)起來(lái)，等待受害者請(qǐng)求此腳本并在瀏覽器中自動(dòng)運(yùn)行。
使用場(chǎng)景：攻擊者在評(píng)論區(qū)提交帶有惡意腳本的評(píng)論，如果服務(wù)器檢查不出惡意腳本，那么此惡意評(píng)論會(huì)被存入服務(wù)器數(shù)據(jù)庫(kù)，下一個(gè)用戶(hù)訪問(wèn)時(shí)，評(píng)論會(huì)被自動(dòng)獲取并展示，其中惡意腳本也被自動(dòng)運(yùn)行了。

2.非持久型跨站：反射型跨站腳本漏洞，最普遍的類(lèi)型。用戶(hù)訪問(wèn)服務(wù)器 - 跨站鏈接 - 返回跨站代碼。

通過(guò)用戶(hù)點(diǎn)擊惡意鏈接，獲取用戶(hù)已登錄的會(huì)話 cookie（黑客在留言板中插入惡意代碼
受害者訪問(wèn)被植入惡意代碼的頁(yè)面，惡意代碼將 cookie 發(fā)送給黑客的服務(wù)器，一般使用 xss 平臺(tái)生成 payload，受害者執(zhí)行之后 cookie 會(huì)被發(fā)送到 xss 平臺(tái)）

3.DOM 跨站（DOM XSS）:DOM(document object model 文檔對(duì)象模型)，客戶(hù)端腳本處理邏輯導(dǎo)致的安全問(wèn)題，在用戶(hù)瀏覽的頁(yè)面中直接注入代碼。

實(shí)例：HTML 中有個(gè)錨的功能，也就是通過(guò) #id 來(lái)實(shí)現(xiàn)當(dāng)頁(yè)面的跳轉(zhuǎn)。

（1）測(cè)試方法

a.在數(shù)據(jù)輸入界面，輸入：alert(/123/)，保存成功后如果彈出對(duì)話框，表明此處存在一個(gè) XSS 漏洞。(或輸入框中輸入)

b.或把 url 請(qǐng)求中參數(shù)改為 alert(/123/)，如果頁(yè)面彈出對(duì)話框，表明此處存在一個(gè) XSS 漏洞。(或 url 請(qǐng)求參數(shù)中值改為)

（2）怎么防止 XSS 攻擊？

XSS 來(lái)源于用戶(hù)提供的內(nèi)容，只要過(guò)濾掉其中的惡意代碼即可，Node.js 項(xiàng)目中推薦使用 xss 庫(kù)來(lái)完成這個(gè)工作

四、URL跳轉(zhuǎn)漏洞

URL 跳轉(zhuǎn)漏洞，即未經(jīng)驗(yàn)證的重定向漏洞，是指 Web 程序直接跳轉(zhuǎn)到參數(shù)中的 URL，或者在頁(yè)面中引入了任意開(kāi)發(fā)者的 URL，將程序引導(dǎo)到不安全的第三方區(qū)域，從而導(dǎo)致安全問(wèn)題。

1.測(cè)試方法

（1）使用抓包工具抓取請(qǐng)求。

（2）抓取 302 的 url，修改目標(biāo)地址，查看是否能跳轉(zhuǎn)。

ps：不過(guò)現(xiàn)在很多跳轉(zhuǎn)都加了 referer 的校驗(yàn)導(dǎo)致攻擊者跳轉(zhuǎn)失敗

2.繞過(guò)URL跳轉(zhuǎn)限制

（1）利用?號(hào)繞過(guò)限制

比如：http://www.aaa.com/acb?Url=http://login.aaa.com
這是一個(gè)跳轉(zhuǎn)鏈接，跳轉(zhuǎn)到它的二級(jí)域名下，那么這個(gè)問(wèn)號(hào)放哪里可以繞過(guò)呢？其實(shí)就是放到它自身的域名前面也就是你添加的想要跳轉(zhuǎn)的域名的后面，如：http://www.aaa.com/acb?Url=http://test.com?login.aaa.com 。它其實(shí)是會(huì)跳轉(zhuǎn)到這個(gè) test.com 域名下，這個(gè)域名是我想要跳轉(zhuǎn)的任意域名，而后面的它自身域名一定要帶上，不帶上就無(wú)法輔助用問(wèn)號(hào)?這個(gè)特性來(lái)跳轉(zhuǎn)到指定域名了，而跳轉(zhuǎn)后，問(wèn)號(hào)和問(wèn)號(hào)后面的內(nèi)容會(huì)變?yōu)檫@樣：http://www.test.com/?login.aaa.com

（2）利用反斜杠和正斜杠繞過(guò)限制

比如：http://www.aaa.com/acb?Url=http://login.aaa.com/ 同樣是在它本身域名錢(qián)加上正斜杠，然后正斜杠前面跟上你想跳轉(zhuǎn)的域名地址
如：http://www.aaa.com/acb?Url=http://test.com/login.aaa.com

反斜杠有三種思路:

兩個(gè)反斜杠繞過(guò)方法

比如：http://www.aaa.com/acb?Url=http://login.aaa.com/ 同樣是在它本身域名前加上兩個(gè)反斜杠，然后兩個(gè)反斜杠前面跟上你想跳轉(zhuǎn)的域名地址
如：http://www.aaa.com/acb?Url=http://test.comlogin.aaa.com\

一個(gè)反斜杠繞過(guò)方法

如：http://www.aaa.com/acb?Url=http://test.comlogin.aaa.com\

另一種思路，一個(gè)反斜杠一個(gè)點(diǎn)

利用.這樣的格式，也就是一個(gè)反斜杠加一個(gè)點(diǎn)來(lái)跳過(guò)限制，

如：http://www.aaa.com/acb?Url=http://test.com.login.aaa.com\

（3）利用@繞過(guò)URL 限制

如果你用這方法在火狐里進(jìn)行跳轉(zhuǎn)，會(huì)有彈窗提示，在其它游覽器則沒(méi)有。

如：http://www.aaa.com/acb?Url=http//login.aaa.com@test.com 后面的 test.com 就是要跳轉(zhuǎn)到的域名，前面的域名都是用來(lái)輔助以繞過(guò)限制的：

（4）利用 # 號(hào)繞過(guò)

如：http://www.aaa.com/acb?Url=http://test.com#login.aaa.com

（5）利用白名單缺陷繞過(guò)

有的域名白名單限制是不全的，比如如果想利用一個(gè)跳轉(zhuǎn)，而這個(gè)跳轉(zhuǎn)是通用，在這個(gè)公司網(wǎng)站很多子域名等都可以跳轉(zhuǎn)，那么你買(mǎi)個(gè)域名也不算貴對(duì)吧，為什么這么說(shuō)呢，這個(gè)問(wèn)題就是白名單限制不當(dāng)，比如，當(dāng)跳轉(zhuǎn)的域名包含這個(gè)網(wǎng)站下的所有域名，比如：
http://www.aaa.com/acb?Url=http://login.aaa.comlogin.aaa.com 也可以改成 aaa.com 同樣可以跳轉(zhuǎn)對(duì)吧，因?yàn)榘酌麊卫镏灰邪@個(gè)域名就直接成功跳轉(zhuǎn)。那么當(dāng)我在這個(gè)域名前面加上如 testaaa.com，白名單里會(huì)檢查是否包含 aaa.com 這個(gè)域名，包含，然后直接跳轉(zhuǎn)，而并沒(méi)有檢查這個(gè)域名的整個(gè)信息，然后可以利用這個(gè)問(wèn)題，直接注冊(cè)一個(gè) testaaa.com 這個(gè)域名就可以利用這個(gè)跳轉(zhuǎn)。

3.預(yù)防或修復(fù)漏洞方法

（1）若跳轉(zhuǎn)的 URL 事先是可以確定的，包括 url 和參數(shù)的值，則可以在后臺(tái)先配置好，url 參數(shù)只需傳對(duì)應(yīng) url 的索引即可，通過(guò)索引找到對(duì)應(yīng)具體 url 再進(jìn)行跳轉(zhuǎn)；

（2）若跳轉(zhuǎn)的 URL 事先不確定，但其輸入是由后臺(tái)生成的（不是用戶(hù)通過(guò)參數(shù)傳入），則可以先生成好跳轉(zhuǎn)鏈接然后進(jìn)行簽名，而跳轉(zhuǎn) cg 首先需要進(jìn)行驗(yàn)證簽名通過(guò)才能進(jìn)行跳轉(zhuǎn)；注：“簽名 (sign):就是在應(yīng)用程序的特定字段寫(xiě)入特定的標(biāo)記信息,表示該軟件已經(jīng)通過(guò)了簽署者的審核。簽署者對(duì)該軟件的安全性負(fù)責(zé)；

（3）若 1 和 2 都不滿(mǎn)足，url 事先無(wú)法確定，只能通過(guò)前端參數(shù)傳入，則必須在跳轉(zhuǎn)的時(shí)候?qū)?url 進(jìn)行按規(guī)則校驗(yàn)：即控制 url 是否是你們公司授權(quán)的白名單或者是符合你們公司規(guī)則的 url：

（4）XSS 漏洞的注意事項(xiàng) ：跳轉(zhuǎn) url 檢測(cè)中也加入了 CRLF 頭部注入漏洞的檢測(cè)邏輯, 具體就是在請(qǐng)求參數(shù)中加入了%0d%0a 這種測(cè)試代碼，需要對(duì)這些參數(shù)進(jìn)行刪除處理 (事實(shí)上：在判斷到一個(gè)參數(shù)中包含 %00 -> %1f 的控制字符時(shí)都是不合法的，需對(duì)其進(jìn)行刪除)。

（5）開(kāi)源項(xiàng)目及時(shí)進(jìn)行升級(jí)，如 Django 升級(jí) pip install django --upgrade 比如中華 GIS 對(duì) nacos、Log4j2、nginx 等進(jìn)行升級(jí)，應(yīng)中華要求對(duì)存在漏洞的服務(wù)進(jìn)行升級(jí)。

五、任意文件上傳

文件上傳漏洞是 web 安全中經(jīng)常用到的一種漏洞形式。是對(duì)數(shù)據(jù)與代碼分離原則的一種攻擊。上傳漏洞顧名思義，就是攻擊者上傳了一個(gè)可執(zhí)行文件如木馬，病毒，惡意腳本，WebShell 等到服務(wù)器執(zhí)行，并最終獲得網(wǎng)站控制權(quán)限的高危漏洞。

文件上傳漏洞危害：上傳漏洞與 SQL 注入或 XSS 相比 , 其風(fēng)險(xiǎn)更大 , 如果 Web 應(yīng)用程序存在上傳漏洞 , 攻擊者上傳的文件是 Web 腳本語(yǔ)言，服務(wù)器的 Web 容器解釋并執(zhí)行了用戶(hù)上傳的腳本，導(dǎo)致代碼執(zhí)行。如果上傳的文件是 Flash 的策略文件 crossdomain.xml，黑客用以控制 Flash 在該域下的行為。如果上傳的文件是病毒、木馬文件，黑客用以誘騙用戶(hù)或者管理員下載執(zhí)行。如果上傳的文件是釣魚(yú)圖片或?yàn)榘四_本的圖片，在某些版本的瀏覽器中會(huì)被作為腳本執(zhí)行，被用于釣魚(yú)和欺詐。甚至攻擊者可以直接上傳一個(gè) webshell 到服務(wù)器上 完全控制系統(tǒng)或致使系統(tǒng)癱瘓。

1.常見(jiàn)的防護(hù)方法

網(wǎng)站常見(jiàn)的防護(hù)方法，知道了網(wǎng)站是如何防護(hù)該漏洞的，有利于我們更好地開(kāi)展?jié)B透測(cè)試。

對(duì)文件上傳的防護(hù)大體上可以分為兩類(lèi)，一類(lèi)是客戶(hù)端檢測(cè)，另一類(lèi)是服務(wù)端檢測(cè)。

（1）客戶(hù)端檢測(cè)

客戶(hù)端檢測(cè)是指依靠瀏覽器，用 JS 代碼去檢測(cè)。一般是在網(wǎng)頁(yè)上寫(xiě)一段 Js 腳本，用 Js 去檢測(cè)，在文件未上傳時(shí)，校驗(yàn)文件的后綴名，檢測(cè)的方式有白名單和黑名單兩種。
那么如何判斷是否為客戶(hù)端檢測(cè)？

在瀏覽加載文件，但還未點(diǎn)擊上傳按鈕時(shí)便彈出對(duì)話框，內(nèi)容如：只允許上傳.jpg/.jpeg/.png 后綴名的文件，而此時(shí)并沒(méi)有發(fā)送數(shù)據(jù)包，所以可以通過(guò)抓包來(lái)判斷，如果彈出不準(zhǔn)上傳，但是沒(méi)有抓到數(shù)據(jù)包，那么就是采用了前端驗(yàn)證。

從安全的角度來(lái)看，前端驗(yàn)證非常不可靠，上傳正常文件再改數(shù)據(jù)包就可以繞過(guò)，甚至關(guān)閉 JS 都可以嘗試?yán)@過(guò)。很多程序員使用 JavaScript 來(lái)拒絕非法文件的上傳，這種驗(yàn)證方式對(duì)一些普通用戶(hù)防止上傳錯(cuò)誤還可以，但是對(duì)專(zhuān)業(yè)的技術(shù)人員來(lái)說(shuō)，這是非常低級(jí)的驗(yàn)證方式。攻擊者可以用非常多的方法來(lái)突破客戶(hù)端的驗(yàn)證。

由于前端代碼對(duì)用戶(hù)完全開(kāi)放，因此很容易通過(guò)分析前端代碼來(lái)繞過(guò)，所以相當(dāng)于沒(méi)有檢測(cè)。可以用以下三種方式去繞過(guò)或者刪除前端的檢測(cè)：

用 burp 抓個(gè)返回包然后把前端代碼里面文件檢測(cè)的部分代碼刪掉 (這種方式也叫中間人攻擊)；

點(diǎn)檢查，然后找到文件檢測(cè)部分的 JS 代碼，刪掉即可，(但是最保險(xiǎn)的辦法還是抓包后再去刪）;

根據(jù)前端代碼允許上傳的類(lèi)型，預(yù)先把木馬文件后綴改成相應(yīng)的后綴，比如 jpg，通過(guò)前端代碼的檢測(cè)以后，會(huì)自動(dòng)往服務(wù)器發(fā)包，然后通過(guò) burp 去攔截這個(gè)包，把后綴名改回來(lái)。

（2）服務(wù)端檢測(cè)

服務(wù)端檢測(cè)是先將文件上傳到服務(wù)器，然后服務(wù)器依靠后端代碼去檢測(cè)上傳的文件是否合規(guī)。服務(wù)器腳本一般會(huì)檢測(cè)文件的 MIME 類(lèi)型（文件的媒體類(lèi)型）、擴(kuò)展名是否合法，甚至可能會(huì)去檢測(cè)文件中是否嵌入惡意代碼。

服務(wù)端檢測(cè)幾個(gè)常見(jiàn)的手段有：檢查 Content-Type(內(nèi)容類(lèi)型)、檢查后綴 (檢查后綴是主流，根據(jù)后綴來(lái)決定用什么方式來(lái)處理這個(gè)文件)、檢查文件頭等。

（3）白名單和黑名單的區(qū)別

黑名單:不允許某某類(lèi)型的文件上傳；

白名單:只允許某某類(lèi)型的文件上傳。

顯然白名單的方式比黑名單更安全，黑名單很容易就會(huì)被繞過(guò)。

那么如何判斷目標(biāo)是黑名單還是白名單呢，其實(shí)很簡(jiǎn)單，只要上傳一個(gè)莫名其妙的后綴，比如 1.czczxca，這個(gè)后綴的文件肯定不存在，所以如果能上傳成功，說(shuō)明目標(biāo)是黑名單檢測(cè)，如果上傳失敗，則目標(biāo)是白名單檢測(cè)。

2.文件上傳漏洞繞過(guò)技巧

一般來(lái)說(shuō)文件上傳過(guò)程中檢測(cè)部分由客戶(hù)端 javascript 檢測(cè)、服務(wù)端 Content-Type 類(lèi)型檢測(cè)、服務(wù)端 path 參數(shù)檢測(cè)、服務(wù)端文件擴(kuò)展名檢測(cè)、服務(wù)端內(nèi)容檢測(cè)組成。但這些檢測(cè)并不完善，且都有繞過(guò)方法。

客戶(hù)端檢測(cè)繞過(guò)（js 檢測(cè)）：

利用 firebug 禁用 js 或使用 burp 代理工具可輕易突破。

如果只對(duì).jpg 后綴設(shè)置了白名單，我們可以先把后綴改為.jpg 繞過(guò)，再到 Burp Suite 抓包把后綴改回.php

?服務(wù)端 MIME 檢測(cè)繞過(guò)（Content-Type 檢測(cè)）：

使用 burpsuit 代理，修改 Content-Type 的參數(shù)

對(duì)于只允許指定 Content-Type（內(nèi)容類(lèi)型）這種防護(hù)手段，最簡(jiǎn)單的繞過(guò)方法是直接上傳一個(gè)允許的文件類(lèi)型再抓包修改后綴名。以上傳 jpg 文件為例，先上傳該文件，抓包修改后綴名為實(shí)際的后綴名.php，由于上傳的時(shí)候是 jpg，所以瀏覽器發(fā)送的數(shù)據(jù)包中，Content-Type 的類(lèi)型默認(rèn)為 jpg，那么此時(shí)發(fā)送的文件就可以繞過(guò)后端的檢測(cè)。

?服務(wù)端擴(kuò)展名檢測(cè)繞過(guò)：

文件名大小寫(xiě)繞過(guò)，例如 Php，AsP 等類(lèi)似的文件名

對(duì)于那種老版本的 WEB 容器，是區(qū)分大小寫(xiě)的，所以這種方法只對(duì) WEB 容器非常古老的版本有效。原理很簡(jiǎn)單，在解析的時(shí)候，windows 的文件和文件夾都是不區(qū)分大小寫(xiě)的，而 WEB 容器區(qū)分大小寫(xiě)，因此上傳的時(shí)候就有可能繞過(guò)該 WEB 容器，從而實(shí)現(xiàn)繞過(guò)后綴名檢測(cè)。

后綴名字雙寫(xiě)嵌套，例如 pphphp，asaspp 等

來(lái)看一段源代碼：

$fil{e}_{n}ame=st{r}_{i}replace($deny_ext,“”, $file_name);

這里的意思就是把檢測(cè)到的危險(xiǎn)字符替換為空，php 被替換為空，那么假設(shè)上傳的文件后綴名為 pphphp，被替換為空后就會(huì)變?yōu)?php,從而實(shí)現(xiàn)了繞過(guò)。

可以利用系統(tǒng)會(huì)對(duì)一些特殊文件名做默認(rèn)修改的系統(tǒng)特性繞過(guò)

文件后綴加空格或點(diǎn)繞過(guò)后綴名檢測(cè)

在文件名后面留一個(gè)空格，然后上傳上去后空格會(huì)被自動(dòng)的省略，但是看源碼可知道，源碼中黑名單中沒(méi)有過(guò)濾空值，那么 php 和 php 空格，當(dāng)然是不一樣的。

注意：windows 會(huì)自動(dòng)去除文件末尾的空格，所以需要先上傳正常的文件，然后抓包在后綴名的地方加空格，再放包，就可以了。這里的空格改成點(diǎn)也是一樣的。

可以利用 asp 程序中的漏洞，使用截?cái)嘧址@過(guò)

%00 截?cái)嗪?00 截?cái)?/p>

了解%00 之前我們要先了解 0x00。

00 截?cái)啵侯?lèi)似我們用對(duì)講機(jī)或者電報(bào)通話時(shí)，說(shuō)完一句話會(huì)用 over 表示一句話說(shuō)完了，而電腦也需要一個(gè)截?cái)嗟男盘?hào)，而這個(gè)信號(hào)就是 00 截?cái)唷?/p>

0x 是一個(gè)十六進(jìn)制表示方式，聲明這是十六進(jìn)制數(shù)，00 實(shí)際上就是表示 ascii 碼值為 0，有些函數(shù)在處理這個(gè)字符的時(shí)候會(huì)把這個(gè)字符當(dāng)做結(jié)束符，他們就讀取到這里認(rèn)為這一段結(jié)束了。

了解這個(gè)有什么用呢？

在文件上傳時(shí)，如果遇到了白名單機(jī)制只允許上傳 jpg 后綴的，我們?cè)撛趺崔k？JPG 格式并不會(huì)被解析，那么我們需要繞過(guò)上傳過(guò)濾。

假如我寫(xiě)了 1.php%00.jpg 傳參之后，有些過(guò)濾都是直接匹配字符串，他強(qiáng)行匹配到了結(jié)尾是.jpg，然后允許上傳，但是 php 的函數(shù)去執(zhí)行的時(shí)候他讀取到 0x00 認(rèn)為結(jié)束了，那么這個(gè)文件就變成了 1.php，從而實(shí)現(xiàn)繞過(guò)白名單。

%00 實(shí)際上和 00 截?cái)嗍且荒Ｒ粯拥脑恚徊贿^(guò)%00 是經(jīng)過(guò) URL 編碼的，%00 解碼后就是 0x00 截?cái)嗟哪莻€(gè)字符。

需要注意%00 和 00 的區(qū)別，只有 GET 傳參會(huì)進(jìn)行一次 URL 編碼，其他的傳參方式不會(huì)，所以只有 GET 傳參能夠識(shí)別這種%00 的截?cái)唷?/p>

可以利用不在黑名單列表中卻能夠成功執(zhí)行的同義后綴名繞過(guò)黑名單的限制

換一個(gè)后綴名繞過(guò)黑名單檢測(cè)

假設(shè)我們要上傳的文件為 php 文件，那么就要去嘗試，看看什么樣的后綴名會(huì)被當(dāng)成 php 文件解析。實(shí)際上，除了后綴為.php 的文件會(huì)被當(dāng)成 php 文件解析， 還有 phtml php3 php4 php5 之類(lèi)的后綴也會(huì)，可以都去嘗試一下，看看能否上傳成功。

對(duì)于不同的文件，可以采用不同的后綴去測(cè)試，雖然概率很小，但萬(wàn)一成功了呢？

可以利用解析/包含漏洞配合上傳一個(gè)代碼注入過(guò)的白名單文件繞過(guò)

用.htaccess 文件巧妙繞過(guò)黑名單

假如開(kāi)發(fā)者把后端代碼寫(xiě)的很?chē)?yán)格，甚至后綴名的大小寫(xiě)也寫(xiě)進(jìn)了黑名單，那么就可以嘗試用.htaccess 文件來(lái)繞過(guò)了。

.htaccess 全稱(chēng)是 Hypertext Access(超文本入口)。htaccess 文件也被稱(chēng)為分布式配置文件，是 Apache 特有的的針對(duì)目錄改變配置的方法。通過(guò)在一個(gè)特定的文檔目錄中放置一個(gè)包含一個(gè)或多個(gè)指令的文件， 以作用于此目錄及其所有子目錄。該文件可以針對(duì)不同的目錄采用不同的策略。

一般后端的黑名單不會(huì)過(guò)濾把.htaccess 后綴寫(xiě)進(jìn)去，那么我們可以先上傳一個(gè).htaccess 文件上去，提前設(shè)置好讓它把.jpg 文件當(dāng)做 php 文件來(lái)解析，這樣后續(xù)只需要上傳.jpg 文件就可以了。

.htaccess 文件的內(nèi)容如下：

AddType application/x-httpd-php .jpg

這個(gè)指令代表著.jpg 文件會(huì)當(dāng)做 php 文件來(lái)解析。

3.文件上傳漏洞預(yù)防

系統(tǒng)運(yùn)行時(shí)的防御

（1）文件上傳的目錄設(shè)置為不可執(zhí)行。只要 web 容器無(wú)法解析該目錄下面的文件，即使攻擊者上傳了腳本文件，服務(wù)器本身也不會(huì)受到影響，因此這一點(diǎn)至關(guān)重要。

（2）判斷文件類(lèi)型。在判斷文件類(lèi)型時(shí)，可以結(jié)合使用 MIME Type、后綴檢查等方式。在文件類(lèi)型檢查中，強(qiáng)烈推薦白名單方式，黑名單的方式已經(jīng)無(wú)數(shù)次被證明是不可靠的。此外，對(duì)于圖片的處理，可以使用壓縮函數(shù)或者 resize 函數(shù)，在處理圖片的同時(shí)破壞圖片中可能包含的 HTML 代碼。

（3）使用隨機(jī)數(shù)改寫(xiě)文件名和文件路徑。文件上傳如果要執(zhí)行代碼，則需要用戶(hù)能夠訪問(wèn)到這個(gè)文件。在某些環(huán)境中，用戶(hù)能上傳，但不能訪問(wèn)。如果應(yīng)用了隨機(jī)數(shù)改寫(xiě)了文件名和路徑，將極大地增加攻擊的成本。再來(lái)就是像 shell.php.rar.rar 和 crossdomain.xml 這種文件，都將因?yàn)橹孛鵁o(wú)法攻擊。

（4）單獨(dú)設(shè)置文件服務(wù)器的域名。由于瀏覽器同源策略的關(guān)系，一系列客戶(hù)端攻擊將失效，比如上傳 crossdomain.xml、上傳包含 Javascript 的 XSS 利用等問(wèn)題將得到解決。

（5）使用安全設(shè)備防御。文件上傳攻擊的本質(zhì)就是將惡意文件或者腳本上傳到服務(wù)器，專(zhuān)業(yè)的安全設(shè)備防御此類(lèi)漏洞主要是通過(guò)對(duì)漏洞的上傳利用行為和惡意文件的上傳過(guò)程進(jìn)行檢測(cè)。惡意文件千變?nèi)f化，隱藏手法也不斷推陳出新，對(duì)普通的系統(tǒng)管理員來(lái)說(shuō)可以通過(guò)部署安全設(shè)備來(lái)幫助防御。

系統(tǒng)開(kāi)發(fā)階段的防御

（1）系統(tǒng)開(kāi)發(fā)人員應(yīng)有較強(qiáng)的安全意識(shí)，尤其是采用 PHP 語(yǔ)言開(kāi)發(fā)系統(tǒng)。在系統(tǒng)開(kāi)發(fā)階段應(yīng)充分考慮系統(tǒng)的安全性。

（2）對(duì)文件上傳漏洞來(lái)說(shuō)，最好能在客戶(hù)端和服務(wù)器端對(duì)用戶(hù)上傳的文件名和文件路徑等項(xiàng)目分別進(jìn)行嚴(yán)格的檢查?？蛻?hù)端的檢查雖然對(duì)技術(shù)較好的攻擊者來(lái)說(shuō)可以借助工具繞過(guò)，但是這也可以阻擋一些基本的試探。服務(wù)器端的檢查最好使用白名單過(guò)濾的方法，這樣能防止大小寫(xiě)等方式的繞過(guò)，同時(shí)還需對(duì)%00 截?cái)喾M(jìn)行檢測(cè)，對(duì) HTTP 包頭的 content-type 也和上傳文件的大小也需要進(jìn)行檢查。

系統(tǒng)維護(hù)階段的防御

（1）系統(tǒng)上線后運(yùn)維人員應(yīng)有較強(qiáng)的安全意思，積極使用多個(gè)安全檢測(cè)工具對(duì)系統(tǒng)進(jìn)行安全掃描，及時(shí)發(fā)現(xiàn)潛在漏洞并修復(fù)。

（2）定時(shí)查看系統(tǒng)日志，web 服務(wù)器日志以發(fā)現(xiàn)入侵痕跡。定時(shí)關(guān)注系統(tǒng)所使用到的第三方插件的更新情況，如有新版本發(fā)布建議及時(shí)更新，如果第三方插件被爆有安全漏洞更應(yīng)立即進(jìn)行修補(bǔ)。

（3）對(duì)于整個(gè)網(wǎng)站都是使用的開(kāi)源代碼或者使用網(wǎng)上的框架搭建的網(wǎng)站來(lái)說(shuō)，尤其要注意漏洞的自查和軟件版本及補(bǔ)丁的更新，上傳功能非必選可以直接刪除。除對(duì)系統(tǒng)自生的維護(hù)外，服務(wù)器應(yīng)進(jìn)行合理配置，非必選一般的目錄都應(yīng)去掉執(zhí)行權(quán)限，上傳目錄可配置為只讀。

資源分享

下方這份完整的軟件測(cè)試視頻學(xué)習(xí)教程已經(jīng)上傳CSDN官方認(rèn)證的二維碼，朋友們?nèi)绻枰梢宰孕忻赓M(fèi)領(lǐng)取 【保證100%免費(fèi)】

文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-482139.html

到了這里，關(guān)于常見(jiàn)的安全測(cè)試漏洞的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！