私人會員真的在Java中更「安全」嗎？

學習Java，我有時會教使用private訪問修飾符以免暴露「敏感信息」其他類，好像這可以打開一個合法的安全漏洞。但是我從來沒有遇到過這樣一種情況：限制成員可見性不僅僅是爲了以面向對象的方式對程序進行建模。私人會員真的在Java中更「安全」嗎？

是private領域和功能在Java類實際上是更「安全」比其他？

編輯 - 最佳答案的編制。

爲什麼private並不意味着「安全」：

反編譯允許以字節碼
折射靜看庫允許運行時訪問私有成員

什麼private好用於：

可維護性的代碼由於隱藏實現細節

來源

2012-02-08 paislee

我同意答案。你的老師不理解訪問修飾符的要點。它與安全無關。 – 2012-02-08 21:28:33

只要一點：通過爲Java安全管理器配置策略，可以防止危險代碼（如用於更改訪問級別的反映，調用不安全等）。 http://docs.oracle.com/javase/7/docs/api/java/security/Policy.html – kaqqao 2015-08-03 19:09:34

我從來沒有聽說過它迫使方法級別的訪問權限的代碼

模塊化 - 任何嚴重的意義 - 作爲一個安全問題。我的意思是，反編譯器的工作。你可以使用它們來弄清楚字節碼裏面發生了什麼。

有private成員是維護問題。如果我只給你方法級別的內部訪問權限，那麼我唯一的責任就是確保我的API方法繼續工作。我並沒有鎖定在內部使用Double而不是BigDecimal，只要我的方法繼續返回Double（例如）。

來源

2012-02-08 21:23:12

private是不是真的安全，因爲反射可以繞過它（模類加載器/安全類加載器的東西）。它充當意圖的指示，並作爲一種編程錯誤的障礙。

但考慮一個第三方API - API用戶甚至不需要參見private屬性或方法。這不僅僅是關於你的自己的代碼，而是關於什麼代碼暴露給其他人。（再次從「我不試圖破解代碼」的角度來看它）

來源

2012-02-08 21:25:59

不，它們在這個意義上不是更「安全」，儘管一些（非常差）的Java書籍嘗試以這種方式解釋private。如果攻擊者有能力導致任意Java代碼在您的進程中運行，那麼所有「安全性」已經消失。作爲另一個已經提到的答案，反射可以繞過private訪問修飾符。

來源

2012-02-08 21:28:39

顯然，儘可能私有的原則只適用於堅持open-closed principle，否則如果人們習慣於編輯現有類的內部而不是擴展它們，他們可能會改變私有成員變量的封裝通過使它們可以通過增變器和訪問器或更改訪問修飾符來訪問它。

來源

2012-02-08 21:31:16

就安全性而言，答案是「不是真的」：確定的黑客可以進入你的私人領域並用一點反思來稱呼你的私人功能;他們所需要的只是一個帶有代碼的JAR。

雖然隱藏「敏感」信息不會使你的類更安全，這使得它（以及從它內置系統）多很多維護。所以這個答案不是讓所有班級成員公開的藉口。

來源

2012-02-08 21:31:26 dasblinkenlight

我認爲你的老師給出的「安全」的含義並不是讓黑客出門，而是保持錯誤。儘可能使所有事物儘可能私人化，這就限制了一個班級在不知情的情況下可能與另一班級混淆的方式。這是Modular Programming的一個例子。

來源

2012-02-08 21:31:36 Brian

順便說一句：Java中的反射實際上允許您覆蓋對象字段的訪問修飾符。見javadoc和example。

來源

2012-02-08 21:40:54

我完全同意迄今爲止的答案（即private真的代碼衛生不是真正的安全性）。各種答案指出，你可以繞過private使用反射。請注意，如果啓用Java SecurityManager，則可以反過來禁用反射。特別參見ReflectPermission。然而，很少使用安全管理器（在普通瀏覽器沙盒之外）。

來源

2012-02-08 22:33:27 DNA

私人會員真的在Java中更「安全」嗎？

回答

相關問題