假設我接受用戶提供的字符串userstring和call(關鍵字userstring)。從用戶數據創建Clojure關鍵字的安全含義?
這樣做是否存在任何安全隱患?如果是這樣,減輕它們的最好方法是什麼?
假設我接受用戶提供的字符串userstring和call(關鍵字userstring)。從用戶數據創建Clojure關鍵字的安全含義?
這樣做是否存在任何安全隱患?如果是這樣,減輕它們的最好方法是什麼?
根據http://clojure.org/reader,有符號和關鍵字中的字符有效的規則。 (現在,字母數字字符和*
,+
,!
,-
,_
和?
)。不應該創建包含任何其他字符的符號。但是,現在,這些規則完全沒有被編譯器強制執行。
充其量你最終可能會得到無效的關鍵字。在最糟糕的情況下,你可能會遇到邪惡/危險的人,因爲 MichałMarczyk說。請記住,#=()
可用於在讀取時運行任意代碼,因此您甚至不必評估字符串是否有不好的事情發生,您只需要閱讀它。
(keyword "foo #=(steal-passwords-and-delete-hard-drive)")
(見(doc *read-eval*)
如何禁用此行爲,但默認情況下啓用EVAL讀。)
我覺得一般規則消毒用戶輸入適用於此。準確定義你想要允許的內容,並在默認情況下禁止其他所有內容。也許允許像正則表達式#"[a-zA-Z0-9*+!-_?]+"
之類的東西,可能還有其他字母數字,這取決於你說的語言。
關閉我的頭頂:
(keyword s)
將創建名s
不管是否有這樣的關鍵字可以通過關鍵字文字表示的非名稱空間的關鍵字。這可能是一個安全問題,如果你要打印這些關鍵字進行一些配置文件,說的部分,然後嘗試用它作爲可信代碼:
(with-out-str (println (keyword "foo (println :bar)")))
; => :foo (println :bar)
而且,這裏有兩個感興趣的線程的谷歌羣組(第一個是從Clojure的-DEV):
總結:實習垃圾關鍵字可能是內存泄漏,因此您應該考慮對字符串進行一些預處理,如果這些字符串來自不受信任的來源,則可能會進行實施。
非常有幫助,謝謝。 – 2010-05-22 02:24:36
「#=()可以用來在讀取時運行任意代碼,所以你甚至不必評估字符串的壞事發生,你只需要閱讀它。」我不知道,謝謝。 – 2010-05-22 02:23:17