3 回答

TA貢獻1796條經驗 獲得超4個贊
真正合法的用途是setAccessible什么?
單元測試,JVM內部(例如,實現System.setError(...))等等。
Java是否可以被設計為一開始就沒有這種需求?
這種設計的負面后果(如果有)是什么?
很多事情將無法實現。例如,各種Java持久性,序列化和依賴項注入都依賴于反射。幾乎所有在運行時都依賴JavaBeans約定的東西。
您setAccessible只能限制合法使用嗎?
只有通過SecurityManager嗎?
是。
它是如何工作的?白名單/黑名單,粒度等?
這取決于權限,但我相信使用權限setAccessible是二進制的。如果需要粒度,則需要對要限制的類使用其他類加載器和其他安全管理器。我猜您可以實現一個實現更細粒度邏輯的自定義安全管理器。
必須在您的應用程序中對其進行配置是否常見?
沒有。
setAccessible無論SecurityManager配置如何,我都可以將自己的類寫成-proof 嗎?
還是由誰來管理配置?
不,你不能,是的。
另一種選擇是通過源代碼分析工具“強制”執行此操作。例如風俗pmd或findbugs規則?;颍ɡ纾┳R別的代碼的選擇性代碼審查grep setAccessible ...。
作為對后續行動的回應
我的課程都沒有任何類似的可執行隱私?,F在無法執行單例模式(不考慮其優缺點)。
如果那讓您擔心,那么我想您需要擔心。但是,實際上,您不應該試圖迫使其他程序員尊重您的設計決策。如果人們愚蠢到可以使用反射無意中創建多個單例實例(例如),那么他們可以承受后果。
另一方面,如果您的意思是“隱私”包含保護敏感信息不被泄露的含義,那么您就是在樹錯誤的樹。在Java應用程序中保護敏感數據的方法是不允許不信任的代碼進入處理敏感數據的安全沙箱中。Java訪問修飾符并非旨在成為一種安全機制。
<字符串示例>-我是唯一認為這是一個巨大問題的人嗎?
可能不是唯一的一個:-)。但是海事組織,這不是一個問題。公認的事實是,不應在沙箱中執行不受信任的代碼。如果您擁有受信任的代碼/受信任的程序員從事此類工作,那么您的問題就會比意外地可變的字符串更糟糕。(想想邏輯炸彈,通過秘密渠道泄露數據等)
在您的開發或運營團隊中,有許多方法可以解決(或減輕)“不良行為者”的問題。但是它們是昂貴且限制性的...對于大多數用例來說是過大的。

TA貢獻1785條經驗 獲得超8個贊
在這種情況下,反射確實與安全/保障正交。
我們如何限制反射?
Java具有安全管理器,并且ClassLoader是其安全模型的基礎。就您而言,我想您需要看看java.lang.reflect.ReflectPermission。
但這并不能完全解決反射問題??捎玫姆瓷涔δ軕裱毩6鹊氖跈喾桨?,而現在情況并非如此。例如,允許某些框架使用反射(例如Hibernate),但不使用其余代碼。或者為了調試目的而允許程序僅以只讀方式反映。
將來可能成為主流的一種方法是使用所謂的鏡子將反射功能與類分開。請參閱《鏡像:元級設施的設計原則》。但是,還有其他各種研究可以解決這個問題。但是我同意動態語言的問題比靜態語言更為嚴重。
我們應該擔心反射給我們帶來的超級大國嗎?是的,沒有。
是的,因為Java平臺應該由Classloader安全管理器保護。破壞反射的能力可以看作是一種突破。
沒有在這個意義上,大多數系統都是反正不是完全安全的。很多類經??梢员蛔宇惢?,您可能已經就這樣濫用了系統。當然類可以制成final或密封,使他們不能在其他罐子被繼承。但是據此,只有少數幾個類得到正確保護(例如String)。
有關最終課程的詳細信息,請參見此答案。另請參閱Sami Koivu的博客,以獲取有關安全性的更多Java 技巧。
Java的安全性模型在某些方面可以視為不足。諸如NewSpeak之類的某些語言甚至采用了更為激進的模塊化方法,在這種方法中,您只能訪問依賴關系反轉顯式提供給您的內容(默認情況下為無)。
同樣重要的是要注意,安全性始終是相對的。在語言級別,例如,您不能阻止模塊形式消耗100%的CPU或消耗所有內存,直到一個OutOfMemoryException。這些問題需要通過其他方式解決。將來我們可能會看到Java擴展了資源利用率配額,但是明天就不行了:)
我可以在這個問題上做更多的擴展,但是我認為我已經指出了。
添加回答
舉報