講師:堇姬 @ Izcc-ctf

2023.12.1

CTF-request & Path traversal

 

堇姬Naup(網管/美宣)

成電二年級/幽夜工作室繪師/台灣好厲駭學員

CKCSC36

DC : naup_sumire_hime

IG : ckcsc36th_naup

涉獵C++、C、python、遊戲(tkinter、pygame)、資安(Web、Crypto)、AI、flask、html/css/js、 PHP、DC bot。

喜歡看輕小說、動畫、Vtuber、打音遊，也喜歡看百合，就是一個長年混跡ACG的宅女。

https://linktr.ee/naupjjin

夢想是可以成為很電的駭客跟繪師，也想自己寫出一個AI老婆。

本日重點

  • request & response

  • burpsuite

  • Path

  • path traversal

request & response

Request格式

start line

header

CRLF

Body

Response格式

start line

header

CRLF

Body

request

response

start-line

因應請求、回應，分別稱為

請求行 request-line
狀態行 status-line

request-line

方法 (method)、
請求目標 (request-target)、
HTTP 版本 (HTTP-version)

HTTP Method

  • GET：向指定的資源發出「顯示」請求。
  • POST：向指定資源提交資料，並且Body中可帶傳輸的資料。
  • PUT：上傳或取代指定的資源。
  • PATCH : 覆蓋資料
  • DELETE：刪除指定的資源。
  • HEAD：與GET相似，但只會取得標頭與HTTP狀態。
  • OPTIONS：回傳這個伺服器支援的所有HTTP Method。
  • TRACE：回傳收到的請求內容。

 

HTTP-version

HTTP 版本

Ex : HTTP/1.1、HTTP/1.0

status-line

HTTP 版本 (HTTP-version)、
狀態碼 (status-code)、
原因短語 (reason-phrase)

status-code

  • 1xx – 連接正在進行中

  • 2xx – 請求成功完成，伺服器給了瀏覽器預期的響應

  • 3xx –這個請求被收到了，但是需要重新定向

  • 4xx –客戶端看起來可能發生了錯誤，妨礙了伺服器的處理

  • 5xx – 客戶端的請求是有效的，但伺服器未能完成請求

  • 200 -> 一切都正常

  • 301 -> 永久性轉址

  • 302 -> 暫時性轉址

  • 404 -> 該網頁找不到

  • 500 -> 內部服務器錯誤

header

紀錄各種資料/設定，等基本信息

可以想像是包裹外貼的那張紙

Host: echo.paw.cloud
Content-Type: application/json; charset=utf-8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:53.0) Gecko/20100101 Firefox/53.0
Connection: close
Content-Length: 136

Host

要訪問的目標主機的域名或IP

Content-Type

指示請求中攜帶的數據類型(上方的是JSON格式、UTF-8編碼)

User-Agent

發送請求的客戶端應用或瀏覽器信息("Mozilla Firefox"瀏覽器發送，版本是53.0，在Macintosh操作系统上)

Connection

暗示連結類型(close表示請求完後連結會關閉)

Content-Length

後續要讀取消息的長度

 

Macintosh 128K

CRLF

(carriage return followed by line feed)

網際網路嚴謹的換行標準

\r\n

CR = 回車 (Carriage Return)

LF = 換行 (Line Feed)

  • 許多語言表示為: \n
  • Unicode 中為 0x0A (十進制的 10)
  • 許多語言表示為: \r
  •  Unicode 中為 0x0D (十進制的 13)

雖然多數語言 \n 就能做到換行，規範上，仍以 \r\n 為主。

CR跟LF差異

  • 在不同作業系統中，CR 和 LF 的組合方式不同

Windows -> CRLF

Unix/Linux -> LF

  • CR通常表示將游標移動到當前行的起始位置，但不會移動到下一行
  • LF符號通常表示移動游標到下一行的起始位置，實現文本的換行

body

訊息主體，像包裹的箱子，是訊息中乘載資料的地方。

Burpsuite

比較常用的是proxy跟repeater

intercept is off or on :

不會擷取request
擷取下一次的request

open browser :

打開一個瀏覽器，burpsuite會擷取這個瀏覽器的request

擷取到的request

所有收到的request的歷史

我可以把該request送到repeater這樣我就可以修改封包後重新request

  • 左邊是request，你可以修改內容
  • 右邊是收到的response
  • 按下send可以發送請求

題目

https://lotuxctf.com/challenges#Useful%20Tools-9

打開來看到這個，我想可以使用burpsuite

收到了三個，有個叫做/burp5u17e_ch4ll3nge看起來很奇怪

嘗試把他送到repeater，會看到讓我們開始挑戰的字句

把challenge改成1就可以開始，同時也可以收到第一段flag

後面兩段就跟burpsuite沒關係了，提示:

一個是curl，一個是python request

有興趣可以自己解

路徑(Path)

可以想像成一個目錄可以想像成一個櫥櫃，假如我要找到一個檔案可以透過記錄需要依序打開哪個櫥櫃來找到

/Home/Document/naup/

指在目錄 Home 底下有 Document目錄，在Document目錄底下有 naup目錄

可以使用 ../ 來表示「到上一層目錄」

Path traversal

架設網站的時候，會將網頁放在伺服器的某個目錄之下(假設有下列這個)

  • /server/templates/haha.html
  • /server/app.py

網址為 https://naup.com

  • https://naup.com/templates/haha.html

對應到/server/templates/haha.html

若請求

然而如果我嘗試請求

https://naup.com/templates/haha.html/../../app.py

  • 如果沒有過濾就會抓到app.py

  • 有時使用../會被瀏覽器解析，故要將 ../ 進行 Url Encode 變成 ..%2F

  • 產生原因

  1. 伺服器端的檔案權限沒有設定正確
  2. 服務 (Serving) 的目錄，不是白名單的方式，而是由伺服器端的程式碼使用「使用者傳入的字串」組成 目錄字串所造成的
app.get('/templates/:filename', function(req, res){
      var filename = req.params.filename,
          path = `templates/${filename}`;
      return res.sendFile(path, {root: '/server'});
});

如何防禦?

可以直接設定好客戶端訪問的權限

app.get('/templates/:filename', function(req, res){
      var filename = req.params.filename,
      
      path = `${filename}`;
      return res.sendFile(path, {root: '/server/templates/'});
});

https://lotuxctf.com/challenges#Blank%20Site%201-47

題目

https://play.picoctf.org/practice/challenge/270?page=1&search=Forbidden

Bento

By naup96321

Made with Slides.com

Bento

  • 28

More from naup96321