Java中不受信任的Groovy腳本安全

我們正試圖在「企業」產品中提供可編寫腳本的元素。我們想使用groovy，但我們很難確保非常基本的東西。Java中不受信任的Groovy腳本安全

例如，我們想防止客戶端只需要去

Class.forName("my.company.internal.SecruityTools").runAsAwesome(...)

我們已經安裝了一個策略，只允許accesDeclaredMembers並已覆蓋checkPackageAccess方法，只允許白名單包安全管理器。不幸的是，默認的classLoader鏈似乎只是繞過了這一點，並加載類的任何方式。

看起來這是一個相當常見的/討論的問題，但我不能在我的生活中找到一個圖書館，甚至是一個很好的博客文章，瞭解如何在更大的應用程序環境中鎖定不受信任的腳本。

有沒有人做到這一點成功？我是否缺少一些相當明顯的帖子/概念？這是否已經有一個堅實的庫？也許Groovy.tinFoilHatMode(true)？

來源

2012-04-19 Steve Skrla

也許[對類似問題的答案]（http://stackoverflow.com/a/6490674/274466）有一些幫助？答案指向[此博客文章]（http://www.jroller.com/melix/entry/customizing_groovy_compilation_process），它提供了一種可能的機制，以防止這種事情... – ig0774 2012-04-19 01:31:05

如果我沒有錯，有相當多的動態語言功能可以防止任何形式的AST保護。（「ge」+ t「+」ClassLoader「），」fo「+ $ rname或者其他類似的東西 – 2012-04-19 01:50:23

@Ambience您是否嘗試過使用ig0774建議的程序？我不相信您可以逃避它們像你這樣的技巧建議，如果可以的話，這是應該儘快報告給Groovy團隊的東西 – 2012-04-19 08:07:50

看看Groovy Sandbox。您可以使用它來阻止諸如System.exit(0)或new File(「/etc/passwd」)之類的內容。

來源

2013-07-12 20:22:23 Tristan

有你看着使用GroovyCodeSource

來源

2012-04-29 02:08:04

糾正我，如果我錯了，但這似乎隱含在編譯源周圍，並簡單地幫助縮小腳本的策略。我們的代碼在評估線程中爲所有來源定義了非常嚴格的策略。所以這將幫助我們「範圍」我們的權限，但是沒有做任何不可思議的事情導致Class.forName權限開始被驗證（不是我可以看到只看內部groovy引用）。 – 2012-05-03 18:04:47

看一看的java-sandbox。還有一個關於如何在groovy中使用它的教程：http://blog.datenwerke.net/2013/06/sandboxing-groovy-with-java-sandbox.html

來源

2013-06-14 13:45:18

我有機會回頭看看這個，謝謝！ – 2013-07-12 20:28:00

我們最終什麼事做了上面的東西組合，但真正的魔力醬正在實施this AST transformer，在訪問檢查包裹的任何表達（包括this，或隱式this）。

來源

2015-06-18 19:46:44

Java中不受信任的Groovy腳本安全

回答

相關問題