應(yīng)用安全網(wǎng)絡(luò)安全滲透測試逆向工程【免費下載鏈接】Mobile-Security-Framework-MobSFMobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.項目地址https://gitcode.com/gh_mirrors/mo/Mobile-Security-Framework-MobSF點擊查看免費下載Mobile Security FrameworkMobSF是一個面向 Android / iOS / Windows 移動應(yīng)用的自動化滲透測試、惡意軟件分析與安全評估框架支持靜態(tài)與動態(tài)雙重分析。正因其每一個代碼路徑都會處理來自已認證但可能懷有惡意的用戶所提交的 APK、ZIP、IPA、Manifest 等攻擊者可控輸入MobSF 將安全默認優(yōu)先Security must be the default, not an afterthought確立為底層工程準則并以倉庫根目錄的 AGENTS.md 固化成一套可執(zhí)行的開發(fā)規(guī)范。本文以 AGENTS.md 為骨架結(jié)合mobsf/MobSF/security.py、mobsf/StaticAnalyzer/forms.py、tox.ini、.github/SECURITY.md 等倉庫源碼系統(tǒng)拆解 MobSF 的安全架構(gòu)、輸入信任模型、Django 安全特性、歸檔解壓防護與提交前檢查清單。讀者讀完可掌握一套可直接復用的處理不可信輸入的防御性編碼方法也能理解 MobSF 各類安全告警背后的設(shè)計意圖。一、前置門檻提交前必須通過tox -e lintAGENTS.md 的第一條硬性要求是任何任務(wù)收尾前必須運行 lint 并修復全部錯誤且不能留下非零退出碼。具體命令為tox -e lint從 tox.ini 的[testenv:lint]配置可以看到這一命令并非單一檢查器而是組合了autopep8自動格式化、flake8及flake8-bugbear、flake8-import-order、flake8-docstrings、pep8-naming、radon等系列插件外加codespell拼寫檢查。關(guān)鍵約束包括flake8-import-order要求每組 import 保持字母序分組順序為 stdlib → 第三方 → Django → 本地 MobSF行寬上限max-line-length 88圈復雜度上限max-complexity 42對mobsf/uploads、mobsf/downloads、mobsf/static、mobsf/templates等目錄排除檢查。同時 tox 環(huán)境列表為py312, py313與 pyproject.toml 中python ^3.12的要求一致——這直接決定了下文 TAR 解壓可依賴 Python 3.12 的內(nèi)置安全過濾機制。二、集中式安全架構(gòu)mobsf/MobSF/security.pyAGENTS.md 明確規(guī)定新增安全檢查時優(yōu)先放入集中式安全助手模塊mobsf/MobSF/security.py。部分歷史遺留校驗器仍存在于mobsf/MobSF/utils.py對于已經(jīng)確立的助手應(yīng)優(yōu)先復用。這種單點收口的架構(gòu)使全框架的安全邏輯可審計、可復用而不是散落在各個 view 中各自實現(xiàn)。實際源碼證實了這一點security.py內(nèi)的函數(shù)可分為四類。2.1 路徑安全from mobsf.MobSF.security import ( is_path_traversal, # 檢查原始字符串中的 .. 序列、絕對路徑、URL 編碼技巧 is_safe_path, # 路徑構(gòu)造后通過 realpath() 做包含關(guān)系檢查 )is_path_traversal(user_input)security.py同時按 POSIX 與 Windows 語義檢查對輸入做雙層 URL 解碼防%252e→%2e→.的雙重編碼繞過并拒絕\x00空字節(jié)、/、\開頭的絕對路徑、盤符drive以及任何包含..的路徑is_safe_path(safe_root, check_path, raw_file)security.py對安全根目錄與目標路徑都做normpath→realpath→normcase歸一化后用os.path.commonpath判斷目標是否被包含在安全根內(nèi)。值得注意的歷史教訓.github/SECURITY.md 中記錄的 Windows-only path traversal via root-relative paths bypasses is_path_traversal()影響4.5.3正是僅靠單一平臺語義判斷導致的漏洞因此現(xiàn)實現(xiàn)同時覆蓋posixpath與ntpath。2.2 輸入驗證is_attack_pattern, # 檢測 shell 注入;、$()、||、 cmd_injection_check, # 檢測 OS 命令注入字符 is_pipe_or_link, # 讀取文件前檢測符號鏈接與命名管道FIFOis_attack_pattern使用正則;|\$\(|\|\||匹配典型 RCE 載荷命中即記錄Possible RCE attack detected日志并返回結(jié)果供調(diào)用方攔截cmd_injection_check來自 Commix 思路的斷字符清單覆蓋;、、|、||及其 URL 編碼變體%3B、%26、%7C等與%0a、%0d%0a換行注入is_pipe_or_link(path)通過os.path.islink(path) or stat.S_ISFIFO(...)在讀取文件前拒絕符號鏈接與命名管道防止通過特殊文件類型讀取任意內(nèi)容。2.3 輸出凈化sanitize_filename, # 用于 Content-Disposition 頭部的安全文件名 sanitize_for_logging,# 記錄用戶輸入前剔除換行與控制字符 sanitize_redirect, # 重定向只允許相對路徑 sanitize_svg, # 基于 bleach 剔除 SVG 中的 XSS 載荷 clean_filename, # Windows 安全文件名Unicode 歸一化sanitize_filename將非[a-zA-Z0-9._-]字符替換為_并合并連續(xù)下劃線sanitize_for_logging(filename, max_length255)將\n、\r、\t替換為_再按白名單清洗并截斷到 255 字符——這是防日志注入的關(guān)鍵手段配合后端日志系統(tǒng)防止偽造日志行sanitize_redirect僅放行以/開頭的站內(nèi)相對路徑//開頭的協(xié)議相對 URL 與任意外部地址一律回落為根路徑/對應(yīng)歷史 Open Redirect 漏洞GHSA-8m9j-2f32-2vx44.0.4sanitize_svg基于bleach.clean白名單機制只保留svg/g/path/rect/circle/text/image/use/filter/linearGradient/radialGradient等安全標簽及其有限屬性集stripTrue剝離腳本與事件處理器對應(yīng)歷史惡意 SVG 圖標存儲型 XSSGHSA-mwfg-948f-2cc54.3.2clean_filename僅對 Windows 生效先做 NFKD Unicode 歸一化并轉(zhuǎn) ASCII再按-_.() 字母數(shù)字白名單過濾規(guī)避 Windows 保留字符與文件系統(tǒng)差異。2.4 網(wǎng)絡(luò) / SSRF 防護valid_host, # DNS 解析主機拒絕私網(wǎng)/環(huán)回/組播 IPvalid_host是 SSRF 防護的第一道門其底層實現(xiàn)遠比名字復雜security.py拒絕清單覆蓋127.0.0.0/8、169.254.0.0/16、172.16.0.0/12、192.168.0.0/16、10.0.0.0/8及 RFC 6598 共享地址段100.64.0.0/10對 IPv6 做去映射與隧道解包::ffff:127.0.0.1先還原為 IPv4 再判定sixtofour、teredo、64:ff9b::/96等翻譯/隧道地址也會提取內(nèi)嵌 IPv4 遞歸檢查主機名校驗拒絕localhost、無點號單標簽名以及.home.arpa、.internal、.lan、.local、.localdomain等內(nèi)網(wǎng)后綴safe_stream_request/safe_requestsecurity.py更進一步先解析全部 DNS 答案、確認均為公網(wǎng)地址再連接字面 IP 并保留原 Host/SNI通過_PinnedTLSAdapter從根本上切斷 DNS Rebinding 窗口且上游代理會 fail-closed代理做 DNS 即拒絕響應(yīng)大小默認限制 1 MiB。這些實現(xiàn)正是對 SECURITY.md 中一系列 SSRF 歷史漏洞DNS Rebinding、Host 頭注入、assetlinks_check 端口繞過等的體系化回應(yīng)。三、以史為鑒.github/SECURITY.md與修復不完整反模式AGENTS.md 要求開發(fā)者閱讀 .github/SECURITY.md 了解本代碼庫的安全問題完整歷史作為哪些 Bug 類別值得警惕、哪些模式曾被利用過的對照表。該文件按影響版本列出近 30 條已披露漏洞高頻出現(xiàn)的類別恰好對應(yīng)前文四類助手漏洞類別典型記錄對應(yīng)防護函數(shù)路徑遍歷 / Zip Slip / AR-SlipGHSA-c8g7-42qj-frj3、GHSA-8j49-mmcx-4mp5、GHSA-9gh8-9r95-3fc3is_path_traversalis_safe_pathSSRF / DNS RebindingGHSA-fcfq-m8p6-gw56、GHSA-wpff-wm84-x5cxvalid_host/safe_stream_requestCSRFGET 觸發(fā)狀態(tài)變更GHSA-hh7q-v28p-p55m、GHSA-3p54-567p-2wprrequire_http_methods CSRF 中間件存儲型 XSSSVG、Manifest 字段GHSA-mwfg-948f-2cc5、GHSA-8hf7-h89p-3pqjsanitize_svg 模板自動轉(zhuǎn)義命令注入CVE-2024-21633apktool 任意文件覆寫is_attack_pattern/cmd_injection_check壓縮炸彈 DoSGHSA-cvhc-xjjc-c4p3、GHSA-c5vg-26p8-q8cr解壓前尺寸預算校驗開放重定向GHSA-8m9j-2f32-2vx4sanitize_redirectAGENTS.md 特別強調(diào)Incomplete Fix Anti-Pattern修復不完整反模式本代碼庫安全回歸最常見的根源是修復了某一條代碼路徑卻漏掉了它的兄弟路徑。關(guān)閉任何安全修復前必須搜索所有執(zhí)行相同操作的函數(shù)/模式例如每一處解析圖標路徑、每一處解壓歸檔條目確認修復在全部等價路徑上一致生效同時檢查APK 二進制流程與源碼 ZIP 流程——它們是獨立代碼路徑、獨立調(diào)用點歷史上曾發(fā)生過分化。四、輸入信任模型默認一切不可信AGENTS.md 給出了一份明確的信任分級表這是所有校驗邏輯的設(shè)計前提request.GET/request.POST不可信用表單或顯式檢查校驗輸出時轉(zhuǎn)義文件上傳不可信校驗 magic bytes、大小限制與擴展名白名單歸檔條目zip/tar/ar不可信解壓前逐條目檢查AndroidManifest.xml中的值不可信在用于文件系統(tǒng)操作或渲染前一律視為攻擊者可控Info.plist中的值不可信與 Manifest 值同等對待對應(yīng) SECURITY.md 中未校驗 CFBundleExecutable 導致 iOS IPA 圖標路徑穿越的 GHSA-m83p-3cgp-6p8cmd5/hashURL 參數(shù)僅在校驗后半可信必須先經(jīng)is_md5()utils.py正則匹配 32 位十六進制再用于路徑設(shè)備標識符不可信需命令注入檢查加格式校驗。五、Django 層安全特性表單、裝飾器、轉(zhuǎn)義、ORM 與 CSRF5.1 表單校驗——首要輸入凈化層AGENTS.md 規(guī)定新請求校驗優(yōu)先使用 Django Form若某視圖不用表單則每個request.GET[...]/request.POST[...]都必須在使用前顯式校驗。項目采用mixin 組合模式而非在視圖里寫臨時校驗StaticAnalyzer/forms.py# StaticAnalyzer/forms.py — 可組合的 mixin AttackDetect # file 參數(shù)is_path_traversal 擴展名白名單 APIChecks # hash 參數(shù)MD5 格式校驗API 模式 WebChecks # md5 參數(shù)MD5 格式校驗HTML 模式 AndroidChecks # Android 掃描類型 ChoiceField 白名單 IOSChecks # iOS 掃描類型 ChoiceField 白名單AttackDetect.clean_file()先調(diào)is_path_traversal(file)再以正則^\.(kt|java|smali|xml|plist|m|swift|db|sqlitedb|sqlite|txt|json)$校驗擴展名任一失敗即raise forms.ValidationErrorAPIChecks/WebChecks用min_length32, max_length32的CharField配合clean_hash()/clean_md5()調(diào)用is_md5()組合示例class ViewSourceAndroidApiForm(AttackDetect, AndroidChecks, APIChecks)一條類聲明即完成路徑穿越 掃描類型 哈希格式三層校驗。關(guān)鍵原則兩條自定義字段校驗器必須寫在clean_field()中并在拒絕時拋出forms.ValidationError絕不能返回部分結(jié)果再在視圖里二次檢查失敗時用FormUtil.errors_message(form)生成標準錯誤響應(yīng)。尤其重要的一條凡取值集合有限的參數(shù)一律使用ChoiceField如AndroidChecks的 eclipse/studio/java/smali/xml/apk/jar/aar/so/a 十個取值IOSChecks的 ipa/dylib/ios在表單層就消滅整類注入風險嚴禁用CharField再在視圖里手工比對白名單。5.2 視圖裝飾器——三層齊備處理敏感操作的視圖應(yīng)同時應(yīng)用三個裝飾器login_required permission_required(Permissions.SCAN) # 或 DELETE、SUPPRESS 等 require_http_methods([POST]) # 或 [GET]——絕不能省略 def my_view(request, apiFalse): ...login_required攔截未認證訪問permission_required在認證之上再實施基于角色的訪問控制角色權(quán)限定義見 mobsf/MobSF/management/commands/create_roles.pyrequire_http_methods在任何業(yè)務(wù)邏輯執(zhí)行前拒絕錯誤 HTTP 動詞從機制上杜絕GET 觸發(fā) CSRF與 HTTP 方法混淆method confusion問題。5.3 模板自動轉(zhuǎn)義與 DOM 安全Django 模板引擎默認轉(zhuǎn)義變量。AGENTS.md 明令對任何源自掃描數(shù)據(jù)、Manifest 或用戶輸入的值禁用{% autoescape off %}與|safe過濾器在模板之外手工拼接 JSON 等用戶可控字符串時必須顯式調(diào)用django.utils.html.escape()。同時強調(diào)模板自動轉(zhuǎn)義保護不了 JavaScript DOM 落點絕不把掃描、任務(wù)或用戶派生字符串賦給innerHTML應(yīng)使用textContent示例見 templates/general/tasks.html。5.4 ORM——禁止原生 SQL所有數(shù)據(jù)庫訪問必須走 Django ORM禁止.raw()或字符串拼接 SQL。用戶輸入?yún)⑴c過濾時以關(guān)鍵字參數(shù)傳入讓 ORM 自動參數(shù)化# 正確——參數(shù)化 RecentScansDB.objects.filter(MD5checksum) # 錯誤——拼接導致 SQL 注入 RecentScansDB.objects.raw(fSELECT * FROM ... WHERE MD5 {checksum})這條規(guī)則直接對應(yīng) SECURITY.md 中 GHSA-hqjr-43r5-9q58SQLite 數(shù)據(jù)庫查看器 SQL 注入4.4.5。5.5 CSRFDjango 的CsrfViewMiddleware全局開啟。任何修改狀態(tài)的視圖禁用csrf_exempt唯一合法例外是已確立模式的 API 端點攜帶X-Csrftoken頭或基于 Token 認證。所有變更操作——包括動態(tài)分析的啟動/停止/流式輸出——必須使用攜帶 CSRF Token 的 POST不能用 GET當一個頁面既要渲染又要流式輸出如 logcat時應(yīng)將 GET 渲染與 POST 流式拆分為兩個入口。六、歸檔解壓安全TAR 與 ZIP 的差異化防護6.1 TAR必須用 Python 3.12 的filterdataAGENTS.md 用一個具體攻擊鏈說明為何手寫 name-only 檢查不可靠符號鏈接 嵌套條目組合可以繞過os.path.abspath名字檢查——名為escape的符號鏈接成員先通過檢查并落盤隨后名為escape/pwned.txt的文件成員經(jīng)由該符號鏈接被寫入任意位置。技術(shù)要點os.path.abspath會歸一化..但不解析符號鏈接os.path.realpath兩者都解析但提取前執(zhí)行的 realpath 檢查仍存在TOCTOU 時間窗口正確做法是利用 Python 3.12 內(nèi)置過濾器MobSF 要求python ^3.12# 正確——逐成員、類型感知、符號鏈接感知 tar.extractall(dest, memberssafe_members_generator, filterdata) # 錯誤——基于 abspath 的名字檢查對符號鏈接不可見 for member in tar.getmembers(): if not os.path.abspath(join(dest, member.name)).startswith(dest): raise ... tar.extractall(dest, members...)filterdata會在提取前、逐成員地拒絕指向目標外的符號鏈接、目標外的硬鏈接、絕對路徑、路徑穿越以及設(shè)備文件。對于必須兼容 Python 3.12 的代碼回退方案為先跳過全部符號鏈接與硬鏈接成員member.issym()/member.islnk()再用realpath做邊界檢查并且逐成員校驗后立即提取而非批量校驗后再 extractall。6.2 ZIP逐成員路徑驗證 解壓預算Pythonzipfile不會把 Unix 符號鏈接條目落成真實文件系統(tǒng)符號鏈接而是將鏈接目標當作普通文件字節(jié)寫入因此 TAR 符號鏈接攻擊對 ZIP 不適用。ZIP 場景的規(guī)范是用is_path_traversalis_safe_path校驗成員名并在調(diào)用zip_ref.extract(member, dest)之前逐成員驗證。倉庫實現(xiàn)可作范例mobsf/StaticAnalyzer/views/common/shared_func.py的解壓循環(huán)約 shared_func.py完整落地了這一模型先對成員文件名做解碼與保留文件名沖突is_reserved_file_conflict處理if (is_path_traversal(file_path) or not is_safe_path(ext_path, destination, file_path))命中即記錄Zip slip detected并跳過該成員解壓前統(tǒng)計file_size與累計總量超出settings.ZIP_MAX_UNCOMPRESSED_FILE_SIZE單文件上限或ZIP_MAX_UNCOMPRESSED_TOTAL_SIZE總量上限即跳過或中止——這是對壓縮炸彈 DoSGHSA-c5vg-26p8-q8cr、GHSA-x768-8642-mmq9的工程化防御落盤文件強制external_attr為rw-r--r--644避免解壓出可執(zhí)行權(quán)限位。七、任何涉及文件 I/O 或用戶輸入改動的提交前清單AGENTS.md 以一份可直接打勾的 checklist 收尾覆蓋了上文全部主題。它同時可作為其他安全敏感項目的通用驗收模板原始輸入在構(gòu)造路徑前先經(jīng)is_path_traversal校驗存在安全根時構(gòu)造出的文件系統(tǒng)路徑用is_safe_path復核文件讀取前用is_pipe_or_link拒絕符號鏈接與 FIFOShell 參數(shù)以列表形式傳遞而非格式化字符串用戶可控字符串渲染前用django.utils.html.escape轉(zhuǎn)義SVG 內(nèi)容經(jīng)過sanitize_svg清洗出站 URL 經(jīng)valid_host檢查重定向包裹sanitize_redirect日志語句對任何用戶派生值使用sanitize_for_loggingTAR 解壓使用filterdata而非手寫abspath檢查ZIP 解壓在extract()前用realpath逐成員校驗路徑每個安全守衛(wèi)都必須有continue/return/raise——僅記日志不算攔截修復對稱地應(yīng)用到所有等價代碼路徑tox -e lint以退出碼 0 通過結(jié)語把安全做成默認值從 AGENTS.md 可以看出MobSF 的安全工程并非依賴某個單一防護點而是一條完整防線表單層用ChoiceField與 mixin 消滅注入類別視圖層用三層裝飾器收斂認證/授權(quán)/方法混淆輸出層用模板自動轉(zhuǎn)義與sanitize_*系列封堵 XSS/重定向/日志注入歸檔層用filterdata與逐成員校驗對抗 Zip Slip 與解壓炸彈網(wǎng)絡(luò)層用 DNS 全量解析 IP 固定連接對抗 SSRF 與 DNS Rebinding而.github/SECURITY.md的歷史漏洞清單則持續(xù)為這條防線提供哪些模式曾經(jīng)被攻破的實證輸入。任何為 MobSF 貢獻代碼、或借鑒其架構(gòu)構(gòu)建同類安全分析平臺的開發(fā)者都可以把這條默認不可信、單點收口、對稱修復、守衛(wèi)必須中斷執(zhí)行的規(guī)范直接落地為團隊的編碼紀律。贊分享應(yīng)用安全網(wǎng)絡(luò)安全滲透測試逆向工程【免費下載鏈接】Mobile-Security-Framework-MobSFMobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis and security assessment framework capable of performing static and dynamic analysis.項目地址https://gitcode.com/gh_mirrors/mo/Mobile-Security-Framework-MobSF點擊查看免費下載相關(guān)推薦PhotoPrism 安全編碼實踐指南歸檔解壓與 HTTP 下載的安全防護規(guī)范pkg/AGENTS.md 解讀PhotoPrism 安全編碼實踐指南歸檔解壓與 HTTP 下載的安全防護規(guī)范pkg/AGENTS.md 解讀 本篇技術(shù)指南以 PhotoPrism 倉庫后端前端圖像處理人工智能AI 應(yīng)用YOLOv5 倉庫協(xié)作與 AI 編碼 Agent 實踐指南基于 AGENTS.md 的工程規(guī)范解讀YOLOv5 倉庫協(xié)作與 AI 編碼 Agent 實踐指南基于 AGENTS.md 的工程規(guī)范解讀 導讀 本文圍繞 YOLOv5 倉庫根目錄下的 AGENTS人工智能深度學習計算機視覺預訓練微調(diào)MobSF 安全開發(fā)指南面向 AI 編碼助手與安全工程師的攻擊面防護規(guī)范MobSF 安全開發(fā)指南面向 AI 編碼助手與安全工程師的攻擊面防護規(guī)范 MobSFMobile Security Framework是一款自動化的移動應(yīng)應(yīng)用安全網(wǎng)絡(luò)安全滲透測試逆向工程上一篇解決esbuild運行時解析錯誤從報錯到修復的完整指南下一篇Unity輸入系統(tǒng)完全攻略4大頂級輸入管理工具讓你的游戲操控更專業(yè)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考