學習HTML的小心思（踩坑經歷）

轉眼我已經是一只畢業2年的“社會狗”了，近期工作不算忙，想著自己在學習學習，增長點個人興趣。于是翻出了之前學過的HTML知識，想著自己復習復習，空了可以自己寫個網頁玩玩。開始了演練，腦子了思考這我的技術老師傳授的知識框架，借助這網絡知識庫，開始敲自己的“網頁”代碼。

今天學習html頁面知識，不曾想在簡單的“邏輯”前面就踩坑了，還差點走不出來。相對路徑問題。相對路徑的問題，本就是2在1之后、1在2之前這樣的問題。。排坑之久，讓我這只社會狗極其懷疑自己的能力。

如圖，根目錄下，有如下路徑：web\imgs下面是圖片，web\css下是樣式文件，wen\index.html 是網頁文件。就這么一個相對路徑問題處踩到坑。

文件相對路徑

在web\css\***.css文件中寫了下面這個代碼引用網頁背景圖片。

background-image: url(../imgs/background.jpg) ;

代碼

然而并不起作用，一直提示訪問不到文件。懵逼樹下懵逼果。萬般折騰，折騰了好久，廢了差不多2小時，才捋清楚應該像下面這樣寫路徑。

最后路徑

最后雖然是順利地完成圖片引用，但費了太多功夫，一條道走到黑的方式不可取。思考要靈活變通，該放松就去放松，也許就是轉念一想，問題就能想清楚。腦子不一定是越用力越能想通，牛角尖不能鉆！

學習網絡爬蟲要掌握哪些技術?#

挑戰升級！老板又為我設定了新的任務目標：利用C#開發一款超能爬蟲，它必須深入挖掘我們網站的每一個細節，不論是主體內容、相關鏈接，甚至是細微至頁面標題，都需快速精準獲取，全程保持高效穩定的運行狀態。

這不僅是一個任務，還是一次創新能力的試煉。那天，我坐在電腦前，心里琢磨著，這得怎么開始呢？

好吧，我得先熟悉我們網站的結構，就像了解一個新朋友一樣。我打開了瀏覽器，一頁一頁地翻，仔細觀察那些HTML代碼，找到了BODY、鏈接和標題的蛛絲馬跡。

根據我們網站結構,我開始了針對這個任務的計劃：

需求分析：

抓取頁面內容（BODY）：需要從目標網頁中提取出HTML的主體部分，這通常包括文字、圖片、視頻等內容。

抓取網站鏈接：我需要識別網頁中的超鏈接（如<a>標簽），并提取出它們的href屬性，以獲取其他相關頁面的鏈接。

抓取頁面標題：頁面標題通常位于<title>標簽內，我要能夠提取并存儲這些標題信息。

技術選型：

由于使用C#作為開發語言，我可以使用HttpClient來實現HTTP請求和響應處理。利用解析庫（這次用AngleSharp）來解析網頁內容，提取所需信息。

主要實現步驟：

初始化：設置爬蟲的基本配置，如并發請求數、超時時間等。網頁抓取：通過HTTP請求獲取目標網頁的HTML內容。內容解析：使用HTML解析庫提取頁面內容、鏈接和標題。數據演示（實際是要保存的）：將提取的信息展示到控制臺中顯示，以便查看、分析和處理。錯誤處理：實現適當的錯誤處理機制，如展示異常記錄等。

測試與驗證：

對爬蟲程序進行單元測試，確保每個功能模塊都能正常工作。進行集成測試，確保整個爬蟲流程的流暢性和穩定性。在實際網站上進行驗證，確保抓取到的數據準確無誤。

維護與更新：

定期檢查爬蟲程序的運行狀態，及時處理可能出現的問題。根據網站結構和內容的變化，適時更新爬蟲程序以適應新的抓取需求。當然，原來的爬蟲程序需要改進，功能需要增強。

根據這個計劃，我初步修改了原來的代碼，把要求的三個功能都完成了，看效果：

關鍵實現代碼：

        // 發送HTTP GET請求并獲取網頁內容
        public async Task<string> GetWebPageContentAsync(string url)
        {
            try
            {
                HttpResponseMessage response=await _httpClient.GetAsync(url);
                response.EnsureSuccessStatusCode();
                string content=await response.Content.ReadAsStringAsync();
                return content;
            }
            catch (HttpRequestException e)
            {
                Console.WriteLine($"從URL {url} 獲取內容時出錯: {e.Message}");
                return null;
            }
        }

        // 解析網頁內容，提取<body>、鏈接和標題
        public async Task CrawlAndParseAsync(string url)
        {
            string content=await GetWebPageContentAsync(url);
            if (content !=null)
            {
                var document=_htmlParser.ParseDocument(content);

                // 獲取并打印<body>的內容
                var bodyContent=document.Body.InnerHtml;
                Console.WriteLine($"網頁<body>內容：\n{bodyContent}\n");

                // 提取并打印所有鏈接
                foreach (var link in document.QuerySelectorAll("a[href]"))
                {
                    var href=link.GetAttribute("href");
                    Console.WriteLine($"找到的鏈接: {href}");
                }

                // 提取并打印頁面標題
                var title=document.Title;
                Console.WriteLine($"頁面標題: {title}");
            }
        }

如有需要完整代碼的朋友，請關注我并留言。

準備啟動信息收集工作，頁面上有三個地方引起了我的注意：.do 的接口地址、登錄功能、密碼找回功能。

審查 .do 接口。看到 .do 自然聯想到 struts2 命令執行全家桶。

安恒出品的 S2 漏洞驗證工具掃描下：

掃描不出漏洞

審查登錄功能。登錄功能的審查點很多，比如賬號是否可枚舉、密碼是否可暴破，但前提是沒有驗證碼，顯然這里存在圖片驗證碼，所以，我先確認驗證碼是否可繞過。

攔截登錄請求：

應答標志為 2，第二次重發，應答標志變為 1

顯然，驗證碼防御機制有效，雖然 python 調用 tesseract 識別圖片的手法可有效攻擊圖片驗證碼，但需要我爬取該站的大量圖片來訓練，這個階段無需太深入，暫時放一放。

審查密碼找回功能。密碼找回功能很容易出現邏輯錯誤，經驗來看，至少可從七個方面攻擊密碼找回功能：重置憑證接收端可篡改、重置憑證泄漏、重置憑證未校驗、重置憑證可暴破、用戶混淆、應答中存在影響后續邏輯的狀態參數、token 可預測。

訪問密碼找回頁面：

攔截密碼找回的請求：

從應答描述可知，提示該用戶不存在，重發幾次，結果相同，說明圖片驗證碼未生效，好了，第一個洞，用戶名可枚舉。

顯然，用戶名在該請求的 params 參數中，URL 解碼可得明文：

于是，將 root 設定為枚舉變量，加載中國人姓名（top500）、后臺賬號兩個字典，進行枚舉：（這里需要的注意的是，大部分的系統可能存在黑名單校驗，枚舉時可使用VPN進行IP輪換）

得到三個有效賬號：nana、admin、liufei。

隨意選個賬號進入密碼找回流程，liufei，應答為 JSON 數據，格式化后嚇我一跳：

敏感信息大贈送！有郵箱，甚至有哈希密碼。記下來，第二個漏洞，賬號相關敏感信息泄漏。

我的目的很明確，獲取登錄密碼，所以，我計劃利用泄漏信息，從信息庫和哈希反解兩方面達到目的。

信息庫。提取郵箱中的用戶名，liufei 的 liufei、nana 的 18xxxxxx56、admin 的 legxxxxxxng，在信息庫中查詢歷史密碼。

只找到 liufei 相關的多個歷史密碼，逐一驗證，均錯誤。

哈希反解。提取三個賬號的哈希密碼，liufei 的 a1e0476879cab2a76cc22c80bbf364dd、nana 的 208f0aba4a6d4b9afe94207e6c57d594、admin 的 3faf009c43bb39c5a37859bc48feaff3。

有了哈希密碼，第一時間查彩虹表(https://www.cmd5.com/)，反解明文密碼：

只有賬號 liufei 的密碼解出為 !QAZ2wsx，nana、admin 無解，暫時放下。第三個漏洞，業務系統存在弱口令賬號 liufei。

通過 liufei / !QAZ2wsx 登錄網站：

功能非常有限，只有個回收站，里面沒有業務任何數據。

上圖中有幾個輸入框，應該是個查詢功能，但是找不到查詢按鈕，嘗試在前端 HTML 源碼中翻找查詢接口，無果；在 burp 的報文歷史中審查 JS，也沒找到有用的接口。看來，還得找個高權限的賬號。

回到先前未反解出來的兩個賬號，nana 的 208f0aba4a6d4b9afe94207e6c57d594、admin 的 3faf009c43bb39c5a37859bc48feaff3。

https://www.cmd5.com/擁有海量的彩虹表數據，它反解不出來，很可能是個強口令。對于強口令的暴破，我習慣圍繞用戶名，制作具有社工屬性的密碼字典，如，用戶名 nana，社工屬性密碼可能為 NaNa、na520na、nana@19901015。如何生成社工屬性密碼字典？hashcat！對滴，hashcat 不僅是哈希暴破神器，也支持基于規則生成密碼字典，規則庫位于 hashcat/rules/：

其中，dive.rule 含有我需要的規則，選之。我把 nana 視為基礎信息存入 base.txt 中作為輸入，讓 dive.rule 模仿學習生成類似的密碼字典，保存至 se_passwds.txt：接著用社工字典暴破哈希密碼：

7 秒出結果，得到 nana 的密碼 nanacnacnanac，第四個漏洞，業務系統存在社工屬性口令賬號 nana。用類似的手法，制作了賬號 admin 的社工密碼字典，遺憾，并未暴出 admin 的密碼。沒關系，用 nana / nanacnacnanac 登錄系統，或許有新發現。

一旦進入后臺，習慣上先找三類功能：上傳功能、查詢功能、命令功能。上傳功能，通過各種任意文件上傳攻擊手法，上傳 webshell；查詢功能，審查是否存在 SQL 注入，拿數據（如，哈希密碼）；命令功能，指那些有著名工具實現的功能，比如，輸入個 IP，業務功能探測該 IP 是否存活，服務端可能執行了 ping 命令，又如，上傳個壓縮包，頁面顯示壓縮包內容，服務端可能執行了 unzip 命令，這時，用命令注入或命令選項注入的手法，攻擊服務端。

登錄 nana 賬號，業務功能也不多，但有個上傳功能：

我得深入審查它，或許是 getshell 的唯一通道。

先上傳一個正常的 PNG 圖片，頁面報錯，提示非管理員禁止上傳：

這可不好玩了，admin 的哈希密碼之前用彩虹表、社工字典都嘗試過，無法反解，前進步伐再次受阻。

回想之前刺探過的密碼找回功能，發現泄漏用戶哈希密碼就未再深入，應該再審查下，或許能重置 admin 密碼。

用 admin 進入密碼找回流程，先順利通過服務端用戶名是否存在的校驗，然后向該賬號綁定的郵箱地址發送密碼重置 URL，請求如下：

顯然，參數 email 存在不安全的直接對象引用（IDOR）問題，將其替換為攻擊者的郵箱，90% 的概率會收到重置郵件。

于是，我找了個匿名郵箱，嘗試劫持 admin 的密碼找回郵件：

很快，匿名郵箱收到來信，訪問帶 token 的密碼重置鏈接，還真能修改密碼：

至此，已經拿到管理員的后臺權限。后續便可以很方便的上傳大馬小馬了。就不在一一列舉。

另外參數 email 存在不安全的直接對象引用（IDOR）問題這是一個很常見的漏洞類型，通過抓包修改參數等操作很容易拿到修改密碼鏈接。

在線咨詢