2017.W27 - Path Traversal
> 重新設計輪子當然可以 只要妳開的車裝上你的輪子
## 前言 ##
最近在處理公司上的事情 一直覺得重新造輪子是個不錯的概念
但是也不要在公司產品上用你設計輪子啊 QQ
## 內容 ##
Path Traversal 或者稱為 Directory Travelsal 是一系列安全性的漏洞概念
主要是處理檔案路徑時不正確 造成存取的檔案超出設計者的預期
從 CWE 列表中可以從 CWE-21 - Pathname Traversal and Equivalence Errors[0] 開始
引起各種 Path Travelsal 的問題
主要的問題都會回歸到所謂的 CWE-20 Improper Input Validateion[1]
也就是不正確的使用者輸入驗證
簡單的例子：有一個 web service 會提供 上傳檔案 與 自動轉檔 功能
轉檔功能操作時 需要指定檔案的路徑
一個基本的驗證則是快速判斷檔案路徑中是否包含 . 跟 .. (Linux-Based)
但是這樣的假設也不盡正確 原因是這樣就代表不允許使用 ..abc 這樣的名稱
因此一個聰明的概念就是利用 / 來切割檔案名稱
並且逐一檢查是否包含 . 或者 ..
然而一個優秀的 c/c++ programmer 應該會知道 glibc 會提供 realpath 這個函數
根據 man realpath 可以得到他的主要描述
returns the canonicalized absolute pathname
在下面的描述中的第一段話更明確的表示他的主要功能
The realpath() function resolves all symbolic links, extra ``/'' characters,
and references to /./ and /../ in file_name.
這代表用 realpath 處理過後的檔案已經不會包含任何 . .. 跟 symbolic link
這些有機會跳轉的符號
從 glibc 的 realpath 的 source code[2] 來看
可以看到 __realpath 主要有以下幾個判斷
1. 輸入的檔名是否為空
2. 當下路徑不存在則報錯
3. 相對路徑則自動帶入當下路徑 getcwd
4. 依序處理每一個 / 切割的元素
4.1 無視連續的 /
4.2 無視 . 的元素
4.3 .. 則跳到上一個資料夾 已經是 / 則無視
4.4 透過 stat 判斷檔案是否檔案、資料夾是否存在
4.5 如果是 symbolic link 則透過 readlink 獲得真實路徑
透過 realpath 的好處在於你可以獲得一個乾淨的絕對路徑
之後就能透過這個路徑 判斷目的地是否在允許的路徑之下
至於為什麼不需要重新造輪子 原因在於這個問題不是第一天發現
因此在這個平台下這個方式會經過各種優化
像是在這篇文章中[3] 提到的 GNU 的 yes 指令快到突破天際 (12.8 GB/s)
這就是針對平台已經特殊優化的結果了
再重新設計一個 yes 除非有特殊的需求
不然還是乖乖用經過千錘百鍊的版本吧！
[0]: https://cwe.mitre.org/data/definitions/21.html
[1]: https://cwe.mitre.org/data/definitions/20.html
[2]: https://github.com/lattera/glibc/blob/master/stdlib/canonicalize.c
[3]: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/
--
> 重新設計輪子當然可以 只要妳開的車裝上你的輪子
## 前言 ##
最近在處理公司上的事情 一直覺得重新造輪子是個不錯的概念
但是也不要在公司產品上用你設計輪子啊 QQ
## 內容 ##
Path Traversal 或者稱為 Directory Travelsal 是一系列安全性的漏洞概念
主要是處理檔案路徑時不正確 造成存取的檔案超出設計者的預期
從 CWE 列表中可以從 CWE-21 - Pathname Traversal and Equivalence Errors[0] 開始
引起各種 Path Travelsal 的問題
主要的問題都會回歸到所謂的 CWE-20 Improper Input Validateion[1]
也就是不正確的使用者輸入驗證
簡單的例子：有一個 web service 會提供 上傳檔案 與 自動轉檔 功能
轉檔功能操作時 需要指定檔案的路徑
一個基本的驗證則是快速判斷檔案路徑中是否包含 . 跟 .. (Linux-Based)
但是這樣的假設也不盡正確 原因是這樣就代表不允許使用 ..abc 這樣的名稱
因此一個聰明的概念就是利用 / 來切割檔案名稱
並且逐一檢查是否包含 . 或者 ..
然而一個優秀的 c/c++ programmer 應該會知道 glibc 會提供 realpath 這個函數
根據 man realpath 可以得到他的主要描述
returns the canonicalized absolute pathname
在下面的描述中的第一段話更明確的表示他的主要功能
The realpath() function resolves all symbolic links, extra ``/'' characters,
and references to /./ and /../ in file_name.
這代表用 realpath 處理過後的檔案已經不會包含任何 . .. 跟 symbolic link
這些有機會跳轉的符號
從 glibc 的 realpath 的 source code[2] 來看
可以看到 __realpath 主要有以下幾個判斷
1. 輸入的檔名是否為空
2. 當下路徑不存在則報錯
3. 相對路徑則自動帶入當下路徑 getcwd
4. 依序處理每一個 / 切割的元素
4.1 無視連續的 /
4.2 無視 . 的元素
4.3 .. 則跳到上一個資料夾 已經是 / 則無視
4.4 透過 stat 判斷檔案是否檔案、資料夾是否存在
4.5 如果是 symbolic link 則透過 readlink 獲得真實路徑
透過 realpath 的好處在於你可以獲得一個乾淨的絕對路徑
之後就能透過這個路徑 判斷目的地是否在允許的路徑之下
至於為什麼不需要重新造輪子 原因在於這個問題不是第一天發現
因此在這個平台下這個方式會經過各種優化
像是在這篇文章中[3] 提到的 GNU 的 yes 指令快到突破天際 (12.8 GB/s)
這就是針對平台已經特殊優化的結果了
再重新設計一個 yes 除非有特殊的需求
不然還是乖乖用經過千錘百鍊的版本吧！
[0]: https://cwe.mitre.org/data/definitions/21.html
[1]: https://cwe.mitre.org/data/definitions/20.html
[2]: https://github.com/lattera/glibc/blob/master/stdlib/canonicalize.c
[3]: https://www.reddit.com/r/unix/comments/6gxduc/how_is_gnu_yes_so_fast/
--
All Comments