)
簡介這是一份面向Web安全初學者與滲透測試人員的Shell工具腳本聚焦于403訪問限制的繞過測試場景。資源以zip壓縮包形式提供共包含3個文件整體約50KB主要文件類型為sh腳本、md說明文檔與png效果截圖sh腳本承載核心繞過邏輯md文檔交代用法與安裝步驟png則直觀展示不同條件下的響應(yīng)對比結(jié)果。腳本在curl支持下集成了13種已知的403繞過方式可通過傳入目標站點與路徑參數(shù)快速發(fā)起測試也能用于橫向比較各類繞過條件下的響應(yīng)差異幫助使用者理解訪問控制策略的薄弱點。目前已有984人學習下載適合剛接觸Web安全、希望動手驗證403繞過原理的讀者參考也可作為日常安全測試中的輕量輔助工具便于快速定位與復現(xiàn)問題。1. 403 繞不過去時我靠一個 Shell 腳本省下整晚排查時間做授權(quán)測試的人大概都遇到過這種場景目標路徑明明存在返回的卻是 403。你翻遍請求頭、換過 UA、試過路徑變形瀏覽器里能打開腳本里就是不行。那天晚上我對著一個后臺入口折騰到凌晨兩點最后發(fā)現(xiàn)只是少了一個X-Forwarded-For頭。第二天我把常見繞過手法整理成一個 Shell 腳本取名 bypass-403專門用來批量試探 403 路徑。它不復雜甚至有點土但勝在能跑、能改、能看懂。這篇不講玄學只講這個腳本怎么用、每個參數(shù)什么意思、失敗時該看哪里以及我在真實授權(quán)場景里踩過的坑。如果你也在為 403 頭疼或者想找一個能直接抄作業(yè)的旁路測試起點往下看。2. 旁路 403 的常見思路從請求頭到路徑變形的六種打法2.1 為什么 403 不等于沒戲403 只說明服務(wù)器理解了請求但拒絕執(zhí)行不代表路徑不存在。很多中間件、反向代理、WAF 在規(guī)則命中時統(tǒng)一返回 403真正的業(yè)務(wù)邏輯可能藏在后面。我一般會先確認三件事響應(yīng)體長度是否和 404 一致、響應(yīng)頭里有沒有Server或X-Powered-By泄露、換一個 HTTP 方法是否返回不同狀態(tài)碼。這三步能快速判斷是「真拒絕」還是「假拒絕」。如果是假拒絕旁路就有空間。腳本里我默認會先發(fā)一個基線請求記錄狀態(tài)碼、長度和關(guān)鍵頭后續(xù)所有變體都跟基線對比避免把 404 誤判成繞過成功。2.2 請求頭類旁路最容易被忽略的入口請求頭旁路的核心是讓后端認為請求來自內(nèi)網(wǎng)或可信來源。常見的有X-Forwarded-For、X-Real-IP、X-Originating-IP、X-Remote-IP、X-Client-IP、X-Host、X-Forwarded-Host。腳本里我把這些頭做成一個數(shù)組逐個替換127.0.0.1、localhost、10.0.0.1等值。注意不是所有頭都有效有些中間件只認特定頭有些會校驗格式。我一般會先跑一輪全量看哪個頭能讓狀態(tài)碼從 403 變成 200 或 302。如果全量都沒反應(yīng)再考慮組合頭比如同時帶X-Forwarded-For和X-Forwarded-Host。# 請求頭旁路核心邏輯遍歷頭名和值逐個試探 HEADERS(X-Forwarded-For X-Real-IP X-Originating-IP X-Remote-IP X-Client-IP X-Host X-Forwarded-Host) VALUES(127.0.0.1 localhost 10.0.0.1 192.168.1.1 0.0.0.0) for h in ${HEADERS[]}; do for v in ${VALUES[]}; do code$(curl -s -o /dev/null -w %{http_code} -H $h: $v $TARGET) # 只記錄與基線不同的狀態(tài)碼避免噪音 if [ $code ! $BASELINE_CODE ]; then echo [] $h: $v - $code fi done done這段邏輯很直白外層遍歷頭名內(nèi)層遍歷值每次發(fā)一個請求只輸出狀態(tài)碼變化的組合。-o /dev/null丟棄響應(yīng)體-w %{http_code}只取狀態(tài)碼速度夠快。實際用時可以把TARGET換成你的目標 URLBASELINE_CODE換成基線狀態(tài)碼。如果目標有速率限制把內(nèi)層循環(huán)加個sleep 0.2別把人家打掛了。2.3 路徑變形類旁路斜杠、點號和編碼的排列組合路徑變形是另一大類。常見手法包括在路徑末尾加/、加/.、加//、加%2e、加%2f、大小寫混寫、在中間插..;/。不同框架對路徑解析的嚴格程度不一樣有的會先規(guī)范化再匹配規(guī)則有的直接拿原始路徑去比對。腳本里我用一個路徑變體數(shù)組對每個變體發(fā)請求同樣只記錄狀態(tài)碼變化。這里有個細節(jié)curl默認會對 URL 做一次編碼如果你要發(fā)原始%2e得用--path-as-is參數(shù)否則會被二次編碼成%252e結(jié)果全錯。# 路徑變形旁路注意 --path-as-is 防止 curl 二次編碼 VARIANTS(/ /. // /%2e/ /%2f/ /..;/ /%252e/) for v in ${VARIANTS[]}; do url${TARGET}${v} code$(curl -s -o /dev/null -w %{http_code} --path-as-is $url) if [ $code ! $BASELINE_CODE ]; then echo [] $url - $code fi done--path-as-is是關(guān)鍵不加的話%2e會變成%252e測試就白做了。另外路徑變形經(jīng)常和請求頭組合使用比如X-Forwarded-For: 127.0.0.1加上/%2e/效果比單用更好。腳本里我留了組合開關(guān)默認關(guān)閉需要時手動打開。2.4 HTTP 方法切換PUT、DELETE、PATCH 的意外收獲有些應(yīng)用只對 GET 和 POST 做了權(quán)限校驗PUT、DELETE、PATCH、OPTIONS 反而漏了。腳本里我會把常見方法都跑一遍看哪個方法返回 200 或 405 以外的狀態(tài)碼。405 說明方法不被允許但路徑存在如果返回 200那基本就是權(quán)限配置遺漏。注意PUT 和 DELETE 有破壞性授權(quán)測試里我只在明確允許的范圍內(nèi)用且只發(fā)空請求體不實際修改數(shù)據(jù)。2.5 協(xié)議與端口變體HTTP/1.0、HTTP/2 和大小寫 Host協(xié)議版本和 Host 頭大小寫偶爾也能觸發(fā)差異。比如某些老中間件對 HTTP/1.0 請求不做嚴格校驗或者對Host: target.com和Host: TARGET.COM處理不同。腳本里我加了--http1.0和--http2開關(guān)以及 Host 頭大小寫變體。這部分命中率不高但成本極低順手跑一遍不虧。2.6 組合拳為什么單發(fā)一個頭往往不夠真實環(huán)境里單發(fā)一個X-Forwarded-For就能繞過的場景越來越少。更多時候需要組合一個頭加一個路徑變形或者兩個頭同時帶。腳本里我設(shè)計了一個簡單的笛卡爾積模式把頭名、頭值、路徑變體、HTTP 方法四個維度做有限組合但默認只跑單維度組合模式需要手動開啟并限制并發(fā)。原因很簡單組合爆炸會讓請求量指數(shù)上升容易觸發(fā)風控也容易把目標打慢。我一般會先跑單維度找到有反應(yīng)的維度再針對性地做二維組合。3. 腳本參數(shù)與實戰(zhàn)配置從單目標到批量清單3.1 核心參數(shù)表每個開關(guān)對應(yīng)什么場景腳本本身不復雜但參數(shù)設(shè)計決定了它能不能適應(yīng)不同場景。下面這張表是我在實際使用中反復調(diào)整后定下來的每個參數(shù)都有明確的適用場景。參數(shù)含義默認值適用場景-u單個目標 URL無快速驗證一個路徑-f目標清單文件無批量測試多個路徑-mHTTP 方法GET切換方法測試-H自定義請求頭無補充腳本未覆蓋的頭-t超時秒數(shù)10目標響應(yīng)慢時調(diào)大-d請求間隔秒數(shù)0有速率限制時調(diào)大-c開啟組合模式關(guān)閉單維度無反應(yīng)時嘗試-v輸出詳細過程關(guān)閉排查為什么沒命中-f和-u互斥優(yōu)先讀文件。-d是我最常用的參數(shù)默認 0 是為了快速跑完但真實授權(quán)測試里我一般會設(shè)成 0.3 到 0.5避免給目標造成壓力。-v在調(diào)試腳本本身時有用能看到每個請求的完整命令和響應(yīng)頭。3.2 單目標快速驗證三分鐘跑完一輪拿到一個 403 路徑我一般先跑單目標模式命令大概長這樣# 單目標快速驗證先跑請求頭和路徑變形間隔 0.3 秒 ./bypass-403.sh -u https://target.example.com/admin -d 0.3 -v跑完后看輸出如果有狀態(tài)碼變化腳本會打印[]開頭的行。沒有變化也不代表沒戲可能是目標對速率敏感或者需要組合。這時候我會看-v輸出里基線請求的響應(yīng)頭確認Server和X-Powered-By再決定下一步試什么。比如看到Server: nginx我會重點試路徑變形看到X-Powered-By: PHP我會重點試請求頭。3.3 批量清單模式一次跑完幾十個路徑批量模式適合已經(jīng)收集到一批 403 路徑的情況。清單文件每行一個 URL腳本會逐行讀取對每個 URL 跑一輪單維度測試。輸出會按 URL 分組方便對比。這里有個坑如果清單里有重復路徑或相似路徑請求量會翻倍。我一般會先用sort -u去重再喂給腳本。# 批量模式先去重再跑間隔 0.5 秒 sort -u targets.txt targets_uniq.txt ./bypass-403.sh -f targets_uniq.txt -d 0.5sort -u去重是血淚經(jīng)驗有一次我沒去重同一個路徑跑了三遍結(jié)果觸發(fā)了目標的風控IP 被臨時封了半小時。從那以后我每次批量跑之前都強制去重。3.4 結(jié)果解讀200、302、401 分別意味著什么狀態(tài)碼變化只是線索不是結(jié)論。200 說明請求成功但響應(yīng)體可能是登錄頁或錯誤頁得看內(nèi)容長度和關(guān)鍵詞。302 說明跳轉(zhuǎn)跳轉(zhuǎn)目標可能是登錄頁也可能是后臺首頁得跟一下Location頭。401 說明需要認證路徑存在但沒權(quán)限這本身也是信息。我一般會把狀態(tài)碼變化的請求單獨存下來用curl -i重放一次看完整響應(yīng)頭和響應(yīng)體前幾百字節(jié)再判斷是不是真的繞過了。4. 避坑與排查那些讓我白忙半天的細節(jié)4.1 現(xiàn)象腳本跑完全是 403一個變化都沒有原因最常見的是基線請求本身就不對。比如目標需要特定 Cookie 或 Token腳本沒帶所有請求都被統(tǒng)一拒絕。另一個原因是目標有 WAF對高頻請求直接返回 403跟路徑和頭都沒關(guān)系。解決先用瀏覽器或curl -i手動發(fā)一次基線請求確認不帶任何變體時返回什么。如果手動也 403先把認證信息補上。如果手動 200 但腳本 403檢查腳本的 UA 和默認頭是否被 WAF 識別。我一般會在腳本里加一個-H User-Agent: Mozilla/5.0的默認頭減少被簡單規(guī)則攔截的概率。4.2 現(xiàn)象狀態(tài)碼變了但響應(yīng)體是登錄頁原因302 跳轉(zhuǎn)到登錄頁或者 200 返回的是前端路由的 index.html。這種情況說明路徑存在但權(quán)限校驗在應(yīng)用層旁路沒真正生效。解決不要只看狀態(tài)碼要看響應(yīng)體長度和關(guān)鍵詞。腳本里我加了一個簡單的長度對比如果變化后的長度和基線差距在 10% 以內(nèi)標記為「疑似無效」。更穩(wěn)妥的做法是重放請求抓取響應(yīng)體前 500 字節(jié)搜login、signin、unauthorized等關(guān)鍵詞。4.3 現(xiàn)象--path-as-is加了但%2e還是被編碼原因curl版本差異。某些老版本curl對--path-as-is支持不完整或者 shell 本身對%做了處理。解決用單引號包裹 URL避免 shell 解釋。如果還不行改用python的requests庫發(fā)原始路徑或者用nc手寫 HTTP 請求。我一般會在腳本里檢測curl --version低于 7.40 的版本提示用戶升級或換工具。4.4 現(xiàn)象組合模式跑了一半目標沒響應(yīng)了原因請求量太大觸發(fā)了目標限流或防火墻。組合模式默認是四維笛卡爾積頭名 7 個、頭值 5 個、路徑變體 7 個、方法 4 個乘起來接近 1000 個請求間隔 0 的話幾秒內(nèi)打完很容易被封。解決組合模式必須配合-d使用間隔至少 0.5 秒。另外組合模式應(yīng)該分階段跑先跑二維看有沒有反應(yīng)再決定要不要上三維。我一般會把組合模式的最大請求數(shù)限制在 200 以內(nèi)超過就分批。4.5 現(xiàn)象腳本在本地跑正常放到服務(wù)器上全超時原因服務(wù)器 DNS 解析或出網(wǎng)策略不同或者目標對來源 IP 有地域限制。解決先在服務(wù)器上用curl -I手動測一個目標確認網(wǎng)絡(luò)通。如果 DNS 慢加--resolve參數(shù)直接指定 IP。如果目標有地域限制這個腳本幫不了你得換出口節(jié)點。注意這里說的換節(jié)點是指授權(quán)測試中合法的網(wǎng)絡(luò)環(huán)境調(diào)整不是其他用途。5. 從腳本到習慣我后來怎么把 403 測試流程化這個腳本我用了大半年最大的收獲不是它幫我繞過了多少 403而是它逼我把測試流程標準化了。以前我遇到 403 就憑感覺試試到哪算哪現(xiàn)在我會先跑基線、再跑單維度、再看響應(yīng)體、最后決定要不要組合。這套流程寫進了我的授權(quán)測試檢查清單每次遇到 403 都強制走一遍。腳本本身也在迭代最早只有請求頭后來加了路徑變形、方法切換、批量模式現(xiàn)在大概 200 行出頭純 Shell沒有依賴扔到任何 Linux 環(huán)境都能跑。如果你要拿這個腳本去用我的建議是先讀懂每一段在干什么再按自己的場景改。比如你的目標對X-Forwarded-For特別敏感就把值列表加長如果你的目標路徑規(guī)則復雜就把路徑變體數(shù)組擴充。不要直接跑組合模式先從單維度開始找到有反應(yīng)的維度再深入。另外授權(quán)測試里一定要控制請求頻率別把人家業(yè)務(wù)打掛了這是底線。腳本我放在了資源包里里面還有一份我整理的 403 旁路檢查清單按請求頭、路徑、方法、協(xié)議四個維度列了常見變體可以直接對照著用。拿過去之后先跑一遍單目標確認環(huán)境沒問題再上批量。希望幫到你。本文還有配套的精品資源點擊獲取 403旁路測試Shell腳本：請求頭與路徑變形實戰(zhàn)
簡介這是一份面向Web安全初學者與滲透測試人員的Shell工具腳本聚焦于403訪問限制的繞過測試場景。資源以zip壓縮包形式提供共包含3個文件整體約50KB主要文件類型為sh腳本、md說明文檔與png效果截圖sh腳本承載核心繞過邏輯md文檔交代用法與安裝步驟png則直觀展示不同條件下的響應(yīng)對比結(jié)果。腳本在curl支持下集成了13種已知的403繞過方式可通過傳入目標站點與路徑參數(shù)快速發(fā)起測試也能用于橫向比較各類繞過條件下的響應(yīng)差異幫助使用者理解訪問控制策略的薄弱點。目前已有984人學習下載適合剛接觸Web安全、希望動手驗證403繞過原理的讀者參考也可作為日常安全測試中的輕量輔助工具便于快速定位與復現(xiàn)問題。1. 403 繞不過去時我靠一個 Shell 腳本省下整晚排查時間做授權(quán)測試的人大概都遇到過這種場景目標路徑明明存在返回的卻是 403。你翻遍請求頭、換過 UA、試過路徑變形瀏覽器里能打開腳本里就是不行。那天晚上我對著一個后臺入口折騰到凌晨兩點最后發(fā)現(xiàn)只是少了一個X-Forwarded-For頭。第二天我把常見繞過手法整理成一個 Shell 腳本取名 bypass-403專門用來批量試探 403 路徑。它不復雜甚至有點土但勝在能跑、能改、能看懂。這篇不講玄學只講這個腳本怎么用、每個參數(shù)什么意思、失敗時該看哪里以及我在真實授權(quán)場景里踩過的坑。如果你也在為 403 頭疼或者想找一個能直接抄作業(yè)的旁路測試起點往下看。2. 旁路 403 的常見思路從請求頭到路徑變形的六種打法2.1 為什么 403 不等于沒戲403 只說明服務(wù)器理解了請求但拒絕執(zhí)行不代表路徑不存在。很多中間件、反向代理、WAF 在規(guī)則命中時統(tǒng)一返回 403真正的業(yè)務(wù)邏輯可能藏在后面。我一般會先確認三件事響應(yīng)體長度是否和 404 一致、響應(yīng)頭里有沒有Server或X-Powered-By泄露、換一個 HTTP 方法是否返回不同狀態(tài)碼。這三步能快速判斷是「真拒絕」還是「假拒絕」。如果是假拒絕旁路就有空間。腳本里我默認會先發(fā)一個基線請求記錄狀態(tài)碼、長度和關(guān)鍵頭后續(xù)所有變體都跟基線對比避免把 404 誤判成繞過成功。2.2 請求頭類旁路最容易被忽略的入口請求頭旁路的核心是讓后端認為請求來自內(nèi)網(wǎng)或可信來源。常見的有X-Forwarded-For、X-Real-IP、X-Originating-IP、X-Remote-IP、X-Client-IP、X-Host、X-Forwarded-Host。腳本里我把這些頭做成一個數(shù)組逐個替換127.0.0.1、localhost、10.0.0.1等值。注意不是所有頭都有效有些中間件只認特定頭有些會校驗格式。我一般會先跑一輪全量看哪個頭能讓狀態(tài)碼從 403 變成 200 或 302。如果全量都沒反應(yīng)再考慮組合頭比如同時帶X-Forwarded-For和X-Forwarded-Host。# 請求頭旁路核心邏輯遍歷頭名和值逐個試探 HEADERS(X-Forwarded-For X-Real-IP X-Originating-IP X-Remote-IP X-Client-IP X-Host X-Forwarded-Host) VALUES(127.0.0.1 localhost 10.0.0.1 192.168.1.1 0.0.0.0) for h in ${HEADERS[]}; do for v in ${VALUES[]}; do code$(curl -s -o /dev/null -w %{http_code} -H $h: $v $TARGET) # 只記錄與基線不同的狀態(tài)碼避免噪音 if [ $code ! $BASELINE_CODE ]; then echo [] $h: $v - $code fi done done這段邏輯很直白外層遍歷頭名內(nèi)層遍歷值每次發(fā)一個請求只輸出狀態(tài)碼變化的組合。-o /dev/null丟棄響應(yīng)體-w %{http_code}只取狀態(tài)碼速度夠快。實際用時可以把TARGET換成你的目標 URLBASELINE_CODE換成基線狀態(tài)碼。如果目標有速率限制把內(nèi)層循環(huán)加個sleep 0.2別把人家打掛了。2.3 路徑變形類旁路斜杠、點號和編碼的排列組合路徑變形是另一大類。常見手法包括在路徑末尾加/、加/.、加//、加%2e、加%2f、大小寫混寫、在中間插..;/。不同框架對路徑解析的嚴格程度不一樣有的會先規(guī)范化再匹配規(guī)則有的直接拿原始路徑去比對。腳本里我用一個路徑變體數(shù)組對每個變體發(fā)請求同樣只記錄狀態(tài)碼變化。這里有個細節(jié)curl默認會對 URL 做一次編碼如果你要發(fā)原始%2e得用--path-as-is參數(shù)否則會被二次編碼成%252e結(jié)果全錯。# 路徑變形旁路注意 --path-as-is 防止 curl 二次編碼 VARIANTS(/ /. // /%2e/ /%2f/ /..;/ /%252e/) for v in ${VARIANTS[]}; do url${TARGET}${v} code$(curl -s -o /dev/null -w %{http_code} --path-as-is $url) if [ $code ! $BASELINE_CODE ]; then echo [] $url - $code fi done--path-as-is是關(guān)鍵不加的話%2e會變成%252e測試就白做了。另外路徑變形經(jīng)常和請求頭組合使用比如X-Forwarded-For: 127.0.0.1加上/%2e/效果比單用更好。腳本里我留了組合開關(guān)默認關(guān)閉需要時手動打開。2.4 HTTP 方法切換PUT、DELETE、PATCH 的意外收獲有些應(yīng)用只對 GET 和 POST 做了權(quán)限校驗PUT、DELETE、PATCH、OPTIONS 反而漏了。腳本里我會把常見方法都跑一遍看哪個方法返回 200 或 405 以外的狀態(tài)碼。405 說明方法不被允許但路徑存在如果返回 200那基本就是權(quán)限配置遺漏。注意PUT 和 DELETE 有破壞性授權(quán)測試里我只在明確允許的范圍內(nèi)用且只發(fā)空請求體不實際修改數(shù)據(jù)。2.5 協(xié)議與端口變體HTTP/1.0、HTTP/2 和大小寫 Host協(xié)議版本和 Host 頭大小寫偶爾也能觸發(fā)差異。比如某些老中間件對 HTTP/1.0 請求不做嚴格校驗或者對Host: target.com和Host: TARGET.COM處理不同。腳本里我加了--http1.0和--http2開關(guān)以及 Host 頭大小寫變體。這部分命中率不高但成本極低順手跑一遍不虧。2.6 組合拳為什么單發(fā)一個頭往往不夠真實環(huán)境里單發(fā)一個X-Forwarded-For就能繞過的場景越來越少。更多時候需要組合一個頭加一個路徑變形或者兩個頭同時帶。腳本里我設(shè)計了一個簡單的笛卡爾積模式把頭名、頭值、路徑變體、HTTP 方法四個維度做有限組合但默認只跑單維度組合模式需要手動開啟并限制并發(fā)。原因很簡單組合爆炸會讓請求量指數(shù)上升容易觸發(fā)風控也容易把目標打慢。我一般會先跑單維度找到有反應(yīng)的維度再針對性地做二維組合。3. 腳本參數(shù)與實戰(zhàn)配置從單目標到批量清單3.1 核心參數(shù)表每個開關(guān)對應(yīng)什么場景腳本本身不復雜但參數(shù)設(shè)計決定了它能不能適應(yīng)不同場景。下面這張表是我在實際使用中反復調(diào)整后定下來的每個參數(shù)都有明確的適用場景。參數(shù)含義默認值適用場景-u單個目標 URL無快速驗證一個路徑-f目標清單文件無批量測試多個路徑-mHTTP 方法GET切換方法測試-H自定義請求頭無補充腳本未覆蓋的頭-t超時秒數(shù)10目標響應(yīng)慢時調(diào)大-d請求間隔秒數(shù)0有速率限制時調(diào)大-c開啟組合模式關(guān)閉單維度無反應(yīng)時嘗試-v輸出詳細過程關(guān)閉排查為什么沒命中-f和-u互斥優(yōu)先讀文件。-d是我最常用的參數(shù)默認 0 是為了快速跑完但真實授權(quán)測試里我一般會設(shè)成 0.3 到 0.5避免給目標造成壓力。-v在調(diào)試腳本本身時有用能看到每個請求的完整命令和響應(yīng)頭。3.2 單目標快速驗證三分鐘跑完一輪拿到一個 403 路徑我一般先跑單目標模式命令大概長這樣# 單目標快速驗證先跑請求頭和路徑變形間隔 0.3 秒 ./bypass-403.sh -u https://target.example.com/admin -d 0.3 -v跑完后看輸出如果有狀態(tài)碼變化腳本會打印[]開頭的行。沒有變化也不代表沒戲可能是目標對速率敏感或者需要組合。這時候我會看-v輸出里基線請求的響應(yīng)頭確認Server和X-Powered-By再決定下一步試什么。比如看到Server: nginx我會重點試路徑變形看到X-Powered-By: PHP我會重點試請求頭。3.3 批量清單模式一次跑完幾十個路徑批量模式適合已經(jīng)收集到一批 403 路徑的情況。清單文件每行一個 URL腳本會逐行讀取對每個 URL 跑一輪單維度測試。輸出會按 URL 分組方便對比。這里有個坑如果清單里有重復路徑或相似路徑請求量會翻倍。我一般會先用sort -u去重再喂給腳本。# 批量模式先去重再跑間隔 0.5 秒 sort -u targets.txt targets_uniq.txt ./bypass-403.sh -f targets_uniq.txt -d 0.5sort -u去重是血淚經(jīng)驗有一次我沒去重同一個路徑跑了三遍結(jié)果觸發(fā)了目標的風控IP 被臨時封了半小時。從那以后我每次批量跑之前都強制去重。3.4 結(jié)果解讀200、302、401 分別意味著什么狀態(tài)碼變化只是線索不是結(jié)論。200 說明請求成功但響應(yīng)體可能是登錄頁或錯誤頁得看內(nèi)容長度和關(guān)鍵詞。302 說明跳轉(zhuǎn)跳轉(zhuǎn)目標可能是登錄頁也可能是后臺首頁得跟一下Location頭。401 說明需要認證路徑存在但沒權(quán)限這本身也是信息。我一般會把狀態(tài)碼變化的請求單獨存下來用curl -i重放一次看完整響應(yīng)頭和響應(yīng)體前幾百字節(jié)再判斷是不是真的繞過了。4. 避坑與排查那些讓我白忙半天的細節(jié)4.1 現(xiàn)象腳本跑完全是 403一個變化都沒有原因最常見的是基線請求本身就不對。比如目標需要特定 Cookie 或 Token腳本沒帶所有請求都被統(tǒng)一拒絕。另一個原因是目標有 WAF對高頻請求直接返回 403跟路徑和頭都沒關(guān)系。解決先用瀏覽器或curl -i手動發(fā)一次基線請求確認不帶任何變體時返回什么。如果手動也 403先把認證信息補上。如果手動 200 但腳本 403檢查腳本的 UA 和默認頭是否被 WAF 識別。我一般會在腳本里加一個-H User-Agent: Mozilla/5.0的默認頭減少被簡單規(guī)則攔截的概率。4.2 現(xiàn)象狀態(tài)碼變了但響應(yīng)體是登錄頁原因302 跳轉(zhuǎn)到登錄頁或者 200 返回的是前端路由的 index.html。這種情況說明路徑存在但權(quán)限校驗在應(yīng)用層旁路沒真正生效。解決不要只看狀態(tài)碼要看響應(yīng)體長度和關(guān)鍵詞。腳本里我加了一個簡單的長度對比如果變化后的長度和基線差距在 10% 以內(nèi)標記為「疑似無效」。更穩(wěn)妥的做法是重放請求抓取響應(yīng)體前 500 字節(jié)搜login、signin、unauthorized等關(guān)鍵詞。4.3 現(xiàn)象--path-as-is加了但%2e還是被編碼原因curl版本差異。某些老版本curl對--path-as-is支持不完整或者 shell 本身對%做了處理。解決用單引號包裹 URL避免 shell 解釋。如果還不行改用python的requests庫發(fā)原始路徑或者用nc手寫 HTTP 請求。我一般會在腳本里檢測curl --version低于 7.40 的版本提示用戶升級或換工具。4.4 現(xiàn)象組合模式跑了一半目標沒響應(yīng)了原因請求量太大觸發(fā)了目標限流或防火墻。組合模式默認是四維笛卡爾積頭名 7 個、頭值 5 個、路徑變體 7 個、方法 4 個乘起來接近 1000 個請求間隔 0 的話幾秒內(nèi)打完很容易被封。解決組合模式必須配合-d使用間隔至少 0.5 秒。另外組合模式應(yīng)該分階段跑先跑二維看有沒有反應(yīng)再決定要不要上三維。我一般會把組合模式的最大請求數(shù)限制在 200 以內(nèi)超過就分批。4.5 現(xiàn)象腳本在本地跑正常放到服務(wù)器上全超時原因服務(wù)器 DNS 解析或出網(wǎng)策略不同或者目標對來源 IP 有地域限制。解決先在服務(wù)器上用curl -I手動測一個目標確認網(wǎng)絡(luò)通。如果 DNS 慢加--resolve參數(shù)直接指定 IP。如果目標有地域限制這個腳本幫不了你得換出口節(jié)點。注意這里說的換節(jié)點是指授權(quán)測試中合法的網(wǎng)絡(luò)環(huán)境調(diào)整不是其他用途。5. 從腳本到習慣我后來怎么把 403 測試流程化這個腳本我用了大半年最大的收獲不是它幫我繞過了多少 403而是它逼我把測試流程標準化了。以前我遇到 403 就憑感覺試試到哪算哪現(xiàn)在我會先跑基線、再跑單維度、再看響應(yīng)體、最后決定要不要組合。這套流程寫進了我的授權(quán)測試檢查清單每次遇到 403 都強制走一遍。腳本本身也在迭代最早只有請求頭后來加了路徑變形、方法切換、批量模式現(xiàn)在大概 200 行出頭純 Shell沒有依賴扔到任何 Linux 環(huán)境都能跑。如果你要拿這個腳本去用我的建議是先讀懂每一段在干什么再按自己的場景改。比如你的目標對X-Forwarded-For特別敏感就把值列表加長如果你的目標路徑規(guī)則復雜就把路徑變體數(shù)組擴充。不要直接跑組合模式先從單維度開始找到有反應(yīng)的維度再深入。另外授權(quán)測試里一定要控制請求頻率別把人家業(yè)務(wù)打掛了這是底線。腳本我放在了資源包里里面還有一份我整理的 403 旁路檢查清單按請求頭、路徑、方法、協(xié)議四個維度列了常見變體可以直接對照著用。拿過去之后先跑一遍單目標確認環(huán)境沒問題再上批量。希望幫到你。本文還有配套的精品資源點擊獲取