作者sirusi (印)
看板C_and_CPP
標題[問題] 關於server接受client的shell指令之安全
時間Wed Jun 14 12:56:33 2017
大家好 我在閱讀Beej's Guide中文譯本時，不太能理解下列這段文字：
(
http://beej-zhtw.netdpi.net/08-FAQ)
以下是我有疑問的一段內文 (疑問處使用
綠色標記)
----------------------------------------------------------------
Q：我該怎麼寫一個 server，可以接受來自 client 的 shell 指令並執行指令呢？
client 的處理過程是：
1. 用 connect() 連線到 server
2. send("/sbin/ls > /tmp/client.out")
3. 用 close() 關閉連線
此時，server 正在處理資料並執行指令：
1. accept() client 的連線
2. 使用 recv(str) 接收命令字串
3. 用 close() 關閉連線
4. 用 system(str) 執行指令
注意！server 會執行全部 client 所送的指令，就像是提供了遠端的 shell 存取權限，人
們可以連線到你的 server 並用你的帳號做點事情。例如：
若 client 送出 ＂rm -rf ~＂
會怎麼樣呢？這會刪掉你帳號裡的全部資料，就是這樣！
所以你學聰明了，你會避免 client 使用任何危險的工具，比如 foobar 工具：
if (!strncmp(str, "foobar", 6)) {
sprintf(sysstr, "%s > /tmp/server.out", str);
system(sysstr);
}
可是這樣還是不安全，沒錯：如果 client 輸入 "foobar; rm -rf ~" 呢？
最安全的方式是寫一個小機制，將命令參數中的非字母數字字元前面放個［'\'］字元［如
果適合的話，要包括空白］。
如你所見，當 server 開始執行 client 送來的東西時，安全性（security）是個問題。
----------------------------------------------------------------
我的疑問如下：
1. 請問加了strncmp那個判斷式後，按照程式邏輯
假如client要請server執行"ls > file1.txt"
必須要使用"foobar ls > file1.txt"才可以嗎？ 請問為什麼要這樣做呢？
2. 請問"
最安全的方式是寫一個小機制"那一個方式是什麼意思呢？
目前我的程度對於程式安全還沒有什麼概念...上面這段讀了幾次還是無法看懂QQ
謝謝大家
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 60.135.146.248
※ 文章網址: https://webptt.com/m.aspx?n=bbs/C_and_CPP/M.1497416196.A.354.html
※ 編輯: sirusi (60.135.146.248), 06/14/2017 12:57:42
1F：→ pili100: 我是不知道foobar是什麼 06/14 13:51
2F：→ pili100: 簡單說，指令不用明碼傳送 06/14 13:51
4F：→ x000032001: 查查command injection就蠻多資訊了 06/14 14:50
5F：推 hn12404988: 投wrapper一票 06/14 19:25
6F：→ jackace: 只要有一個概念就行了 : DON'T DO THIS 06/14 20:17
7F：推 longlongint: 一般做法 只開固定功能 參數只給填純數值 06/14 23:03
8F：→ longlongint: 讓人填指令的做法真的很北七 06/14 23:03
9F：推 Neisseria: 讓人填指令感覺就是自已開洞給別人進來 06/15 07:41
10F：→ sirusi: 非常謝謝各位大大提供的方向！ 06/15 10:05
11F：推 alex70266: 最簡單的想法就是client side丟過來的東西一定要驗證 06/16 22:48
12F：→ alex70266: 因為不能設想request參數都是安全的 06/16 22:50
13F：推 pttuser: 填指令當然沒問題，有問題的是安全性，加上sandbox吧 06/17 23:33
14F：→ Killercat: 其實我不太懂 安全性的東西不是server要負責的嗎？ 06/18 14:45
15F：→ Killercat: SELinux就是這種思維下的產物 怎麼會跑去要client負責 06/18 14:45
16F：→ Killercat: 一個operation「安不安全」的定義 怎樣都不是client管 06/18 14:45
17F：→ Killercat: 今天client就算定一堆定義 別人sniffer你 一樣可以繞過 06/18 14:46
18F：→ Killercat: client的規範，這完全不是一個安全的系統該有的做法 06/18 14:46