我无法理解为什么 java 安全编码很重要。 例如，为什么将变量声明为私有很重要？ 我的意思是，我知道这将使得无法从类外部访问这些变量，但我可以简单地反编译该类来获取值。
类似地，将一个类定义为 Final 将导致无法对该类进行子类化。 什么时候对一个类进行子类化会对安全造成危险？ 如果有必要的话，我可以再次反编译原始类并使用我想要的任何恶意代码重新实现它。
当应用程序被用户“信任”时，问题会出现吗？ 那么人们会以某种方式滥用这种信任吗？
基本上我正在寻找的是一个很好的例子来说明为什么应该遵循安全编码指南。
I'm having trouble understanding why java secure coding is important. For example, why is it important to declare variables private? I mean I get that it will make it impossible to access those variables from outside the class, but I could simply decompile the class to get the value.
Similarly, defining a class as final will make it impossible to subclass this class. When would subclassing a class be dangerous for security? Again if necessary, I could decompile the original class and reimplement it with whatever malicious code I could want.
Does the problem come when applications are "trusted" by the user? And people could then abuse this trust somehow?
Basically what I'm looking for is a good example as to why secure coding guidelines should be followed.
发布评论
评论（7）
编程很难。
如果您定义严格的 API，则不会公开不应公开的变量（我们喜欢将此称为 封装），可以帮助 API 的用户，从而使编程变得更容易。 这被认为是一件好事。
原因主要不是“安全”（如保密），而是清晰度、简单性和可理解性。
当然，如果您知道 API 的用户没有在您背后更改“您的”变量，那么让事情正常工作就会容易得多。
Programming is hard.
If you define strict APIs, that don't expose variables that are not supposed to be exposed (we like to call this encapsulation), you help users of your APIs, and thus make programming easier. This is considered a good thing.
The reasons are not primarily "security", as in keeping secret things secret, as much as clarity, simplicity, and understandability.
As a bonus, it's far easier to make things work correctly if you can know that the user of the API is not changing "your" variables behind your back, of course.
它是“安全的”，意味着类的内部工作对任何使用它的人都是隐藏的。
安全一词并不像“保护服务器”那样使用，它是指一个类的用户不必担心该类将如何执行他想要的任务。
举个例子：
暴露一个类的变量会让你的类的用户知道它们的存在，这是你不想要的，例如：你只需按一个按钮来开灯，你不需要现在里面有铜或执行任务所需的任何东西。
It is "secure" meaning that a class internal working are hidden to whoever uses it.
The term secure is not used as in "securing a server" is used to intend the fact that a user of one class does not have to worry about how the class will perform the task he wants it to.
Taking your example:
Exposing variables of a class would let the user of your class know of their existance, which is something you don't want, for example: you just press a button to turn on the light, you don't need to now that inside there is copper or whater it needs to perform the task.
Java 是一种面向对象编程语言，并且是对象中的关键概念之一面向编程是封装。
封装背后的思想是“隐藏”实现细节，例如保存对象状态的内部变量和算法等内部工作原理，只提供其他对象可以使用的接口，以便与该对象执行功能。
使用这一概念，人们希望通过使用私有变量来隐藏内部状态，以防止其他对象直接影响内部状态。 在 Java 中，为了处理对象，经常会看到 getter 和 setter（例如
getColor和setColor）。此外，封装还可以提高代码的稳健性。
例如，通过限制对内部状态的访问，可以在更改对象之前执行一些健全性检查。
作为一个可靠的示例，假设有一个
Score对象，其percent值介于0和100之间。 通过提供一个setPercent(int)方法来验证指定的值是否在允许的范围内，可以防止Score对象被设置为不可接受的状态。因此，如果
setPercent方法导致错误或抛出，则可以阻止尝试通过编写类似。score.percent = 150的语句来直接操作内部状态。如果指定的值不可接受，则出现异常Java is an object-oriented programming langauge, and one of the key concepts in object-oriented programming is encapsulation.
The idea behind encapsulation is to "hide away" the implementation details such as internal variables which hold the state of the object and the internal workings such as algorithms, and only provide an interface that other objects can use in order to perform functions with the object.
Using that concept, one would like to hide internal states by using
privatevariables to prevent other objects from directly affecting the internal states. In Java, it is common to see getters and setters (e.g.getColorandsetColor) in order to work with objects.Also, encapsulation can increase the robustness of code as well.
For example, by restricting access to the internal states, it would be possible to perform some sanity checks before an object is altered.
As a solid example, say there was a
Scoreobject that was to have apercentvalue between0and100. By providing asetPercent(int)method which validates that the specified value was within the permissible range, it would prevent theScoreobject from being set into an unacceptable state.So, trying to directly manipulate the internal state by writing a statement like
score.percent = 150could be prevented, if thesetPercentmethod causes an error or throws anExceptionif the specified value is unacceptable.这里有两个问题。
首先，当将变量声明为受保护或私有时，它们不会成为公共 API 的一部分。 其他类将来可能取决于您的类，如果您想包含新功能、提高性能等，那么重要的是您可以自由地尽可能多地进行更改。如果您的所有值都是公开的，那么您的所有内部值都将是公开的。价值观和机制是公开的。 更改它们可能会破坏依赖于您的其他类。
第二，当公开变量时，它允许其他类更改您的值。 如果他们改变你的内部价值观，可能会破坏你的程序，并产生奇怪的意外行为。 如果您创建了一个依赖于您班级的准确表现的系统，并且内部值发生了变化，那么您就不能再依赖该系统了。 子类化使事情变得更加复杂。 您的系统可能依赖某种类型的类来执行预期的操作。 通过子类化，可以创建一个看似相同类型但不执行预期操作的新类。
例如，如果您有一个带有受保护函数 getArea() 的类 square，则您希望返回正方形的面积。 但是，可以创建一个扩展 square 的新类，例如类矩形扩展 square。 现在 rectange 可以重写 getArea()，但它仍然是 square 类型，这可能会破坏依赖于 square 功能的东西。 通过将你的类设置为最终类，你就断言这种情况永远不会在你的系统中发生。
这种类型的“安全编码”不会阻止某人看到您的源代码，但它有助于使您的代码在将来更加可靠和可用。
There are two issues here.
The first when declaring variables as protected or private, they won't become part of your public API. Other classes may depend on your class in the future, and it is important that you are free to change as much as possible if you want to include new features, improve performance, etc. If all of your values are public than all of your internal values and mechanisms are public. Changing them may break other classes which depend on yours.
The second, is that when exposing variables it allows other classes to change your values. If they change your internal values if may break your program, and create strange unexpected behavior. If you create a system which relies on the accurate performance of one your classes, and the internal values are changed, than you can no longer rely on that system. Subclassing makes this more complicated. Your system may rely on a class of a certain type to perform expected actions. By subclassing it is possible to create a new class that appears to be the same type but does not perform the expected actions.
For example, if you have a class square with a protected function getArea(), you expect to to return the area of a square. However, a new class can be made which extends square, say class rectangle extends square. Now rectange can override getArea(), but it is still of type square, which may break something which depends on that functionality of square. By making your class final you are asserting that this can never occur in your system.
This type of "secure coding" will not prevent someone from seeing your source code, but it helps to make your code more reliable and usable in the future.
只是补充一下其他人已经说过的内容：其中一些功能也可以简单地视为陈述意图的一种方式。 如果我将成员设置为私有，则其他人“不可能”访问它（这是可能的，但这不是这里的重点），但更重要的是我告诉用户这是一个实现细节，他们不应该依赖。
Just to add to what others have already said: Some of these features can also simply be viewed as a way to state intend. If I make a member
privateI make it "impossible" for others to access it (it is possible, but that's besides the point here), but more importantly I tell the users that this is an implementation detail, that they should not rely upon.想象一下，如果您的对象具有非私有（隐藏）的内部属性，并且访问该属性的代码恰好在多线程环境中运行，那么 N 个线程将开始同时访问它，5 个线程想要更改此属性，4 个线程要更改该属性读。 您无法确保事情顺利运行，两个线程都不会知道它当前保存哪些数据以及它是否成功更改了该对象的属性。
您必须编写一段特殊的代码来负责处理同步访问，但这仍然不能保证您的代码能够正常工作，因为您仍然需要检查程序中访问该属性的其余 680 个类，而不是直接访问它。
简而言之，您遇到了一个巨大的问题，调试是一场噩梦，因为您不知道数据何时被更改、哪个线程执行了该操作、发生的位置等等。
如果不封装，这只是发生情况的一个场景。 ..
好消息是，您的代码运行速度提高了 1%，堆栈上的负载减少了，您获得的性能提升可能可以忽略不计，但您将付出系统定期崩溃和成功调试的机会很小的代价。
just imagine if your object has internal property which is not private (hidden) and your code accessing this property happen to be run in multithreading environment, so N threads would start to access it simultaneously, 5 threads would like to change this property, 4 to read. There is no way you make sure things will run neatly, neither thread will know which data it holds in the moment and did it successfully changed property of that object.
You will have to program special piece of code which will be responsible to handle synchronous access and still that will no be guarrantee your code will work right since you still have to check rest of 680 classes in your program accessing that property not to access it directly.
In short, you are in a huge problem, and debugging is a nightmare since you do not know when the data was chagned, which thread did that, from where it happend etc.
Just one scenario of what is happening if you do not encapsulate...
Good thing, your code runs 1% faster, there is less load on stack, you've achieved probably negligible performance gains which you will pay with periodic crashes of system and minor chances for successfull debugging.
术语“安全编码”是指明显试图避免安全漏洞的软件构造，无论是 C、Java、Ruby、汇编语言还是其他语言。 在选择安全的语言系统之后，也许最核心的部分是保持良好的编程实践。 如果一个程序不清楚，那么你就不太可能相信它值得信任。
对于 Java，有两个值得注意的指南：
在 Java 中，有两种不同的安全编码模式。
在其中一种情况下，您正在处理的代码可能不具有您的代码所具有的所有权限。 例如，如果您正在编写库或签署代码，您需要这样做。 恶意代码不可能以意想不到的方式利用您的权限。 这是困难的！
更常见的是，您处理的程序仅处理不受信任的数据。 例如，Web 服务器（想想 XSS 和 SQL 注入）和处理不受信任文件的桌面应用程序（通常问题是 C 代码存在缓冲区溢出 - 真正的 C++ 更好）。 在某些情况下，拒绝服务 (DoS) 可能是一个严重的问题。
有一些重叠。 例如，解释器以解释器代码的权限运行，并且可能非常“强大”。
The term "secure coding" refers to construction of software that clearly attempts to avoid security vulnerabilities, whether in C, Java, Ruby, assembly language, or anything else. Perhaps the most central part of that, after selecting a secure language system, is to keep to good programming practices. If a program is unclear, then you have little chance of it being worthy of any confidence.
For Java there are two notable guides:
In Java there are two distinct modes of secure coding.
In one you are dealing with code that may not have all the privileges that your code does. For instance if you are writing a library or signing code you need to be doing this. It should be impossible for malicious code to take advantage of your permissions in unintended ways. This is difficult!
More commonly you are dealing with programs that are dealing with only untrusted data. For instance, web servers (think XSS and SQL injection) and desktop application programs dealing with untrusted files (usually the problem is with C code having buffer overflows - genuine C++ is better). In some situations denial of service (DoS) can be a severe issue.
There is some overlap. For instance interpreters run with the permissions of the interpreter code and may be quite "powerful".