Go: Why is DotDotCheck modeled as a complete path-injection barrier?
還沒有人認領這個 Issue。
評估
研究方向
從 TaintedPathCustomizations.qll 中的 DotDotCheck(第 106-122 行)開始,接著檢查 TaintedPath.go 第 31 行的 GOOD 情況,以及 Go 路徑注入查詢測試。驗證 false 分支如何透過 SanitizerGuardAsSanitizer 變成 isBarrier,並將預期行為與 filepath.Base 指南進行比較。完成的標準是:模型和受影響測試的預期結果一致反映所支援的路徑遍歷防護。
由索引模型根據 Issue 內容生成。
描述
Description of the issue
The Go go/path-injection query treats !strings.Contains(path, "..") as a complete path-injection sanitizer. This means that when Contains returns false, taint is fully blocked - no additional sanitizer is required.
I'm wondering why this is modeled as a complete barrier, because checking for the absence of ".." does not prevent absolute-path attacks. For example, /etc/passwd does not contain "..", passes the guard, and can read files outside any intended directory.
The query help seems to agree - it says this approach is "only suitable if the input is expected to be a single file name", and also warns that user-controlled paths "may be absolute paths". But DotDotCheck doesn't distinguish between single-component inputs and multi-component paths.
The existing test case at TaintedPath.go line 31 marks this pattern as GOOD with the comment "This can only read inside the provided safe path", but tainted_path = "/etc/passwd" would still pass the check and escape any safe path.
Affected sanitizer
DotDotCheck in TaintedPathCustomizations.qll (lines 106-122) matches strings.Contains(p, "..") and declares the false branch as a complete sanitizer guard. Through SanitizerGuardAsSanitizer, this becomes a full isBarrier node.
Steps to reproduce
func handler(w http.ResponseWriter, r *http.Request) {
p := r.URL.Query().Get("file")
if !strings.Contains(p, "..") {
data, _ := ioutil.ReadFile(p) // 0 alerts with DotDotCheck enabled
w.Write(data)
}
}
Question
Given that !strings.Contains(p, "..") only blocks one specific attack vector and not absolute paths, would it be more appropriate to model it as a non-barrier (or at least not a complete one), similar to how filepath.Base is documented as "not a sanitizer for path traversal" in mime.multipart.model.yml?
Environment
- CodeQL CLI 2.25.6
- CodeQL repository commit:
f6f45d1536312f53eed079868e344a5906bf3d72 - Go 1.22.12 on Linux/amd64
- 主要語言
- CodeQL
- 星號
- 10.1k
- 分支
- 2.1k
- 平均合併
- 2 天 17 小時
- 30 天內合併 PR
- 145
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
github/codeql 的其他 Issue
-
agentic-workflows
難度 2/5 1-3 小時 新手友好度 70/100
-
false-positive javascript
難度 2/5 1-3 小時 新手友好度 84/100
-
難度 2/5 1-3 小時 新手友好度 82/100
-
難度 2/5 1-3 小時 新手友好度 78/100
-
false-positive
難度 2/5 1-3 小時 新手友好度 70/100
相似的 Issue
-
good first issue
難度 1/5 1 小時以內 新手友好度 95/100
AOSSIE-Org/DebateAI#582 · 2 則留言 ·
-
難度 2/5 1-3 小時 新手友好度 70/100
-
難度 2/5 1-3 小時 新手友好度 70/100
oasisprotocol/oasis-sdk#2523 ·
-
難度 2/5 1-3 小時 新手友好度 75/100
-
cost:cheap severity:medium
難度 2/5 1-3 小時 新手友好度 70/100
fairagro/m4.2_sql_to_arc#227 ·