Basic: fully protect your Java program Security (medium)

Basic: fully protect your Java program Security (medium)-General Linux technology-Linux programming and kernel information. The following is a detailed description. Part 2: do not let vulnerabilities endanger application security
Overview: in this section of the security discussion, Todd Sundsted discusses application security issues with us. Minor errors in program development can bring great security problems to developers and users. Todd will show you how to design and implement the most common security vulnerability type and describe how to avoid these problems. He also provides a vulnerability listing from Sun's own JDK.

Most software developers are aware of the threats posed by malicious or just curious hackers, but few are aware of the extent to which vulnerabilities they inadvertently bring to the program. These vulnerabilities brought to the program are no doubt conniving at, helping the so-called hackers.
On July 6, January this year, a German software developer confirmed that there was a design vulnerability with serious security risks in the database InterBase of Borland, a recently developed source code product. Vulnerabilities in this InterBase version can even be traced back to 1994!
This backdoor exists in the login name and password verification form. However, this problem is caused by the improper design of InterBase developers. This program uses name and password verification to control InterBase access to the database.
Although this error shows an exclusive column, the lessons it reveals are very important: as a developer, for the overall security of our applications, our design and code implementation are critical. In addition, as shown in the preceding column, vulnerabilities brought into the program by developers may affect users for several years.

· Review
Last time, we discussed three security issues that must be checked. Although these problems are different from each other, they often require comprehensive consideration across three aspects. Java program developers must understand the importance of the security issues of their solutions to their products from these three aspects.
Java and non-Java developers are familiar with such a well-known security issue, namely, Virtual Machine security. This is due to years of attention to JVM and runtime environments. Virtual Machine security includes JVM and supported runtime environments. Over the past few years, the security of virtual machines has been enhanced and paid great attention.
Recently, many programmers have switched their attention from Java Virtual Machine security to application security running on the JVM due to fewer obvious vulnerabilities. Most of these Java programmers will significantly affect Java security at this level. In this regard, we need to deal with design decisions and unexpected problems that may occur during development. Of course, not all such vulnerabilities may compromise application security. We will focus on vulnerabilities that can harm programs.
In the last aspect, network security issues, communication between network-based programs and program components is a highlight of security issues. Again, we declare that not all vulnerabilities described here will compromise security. We only pay attention to those aspects that can compromise security.
Last time, we discussed the security of virtual machines and demonstrated how to create and destroy VM Security Vulnerabilities. Now I will discuss application security. Here, I would like to cite the most common vulnerability class to help you avoid such problems. I will include the columns found in Sun's Code recently.
It is easy to list a list of various error designs and implementations. The column here is just one of them. However, I will define and describe a classification directory for most Java program security vulnerabilities. This directory is divided into two main parts: Implementation-Related and design-related vulnerabilities.

· Implementation-related vulnerabilities:
Implementation-related vulnerabilities are usually included in the program when implementing code. This is usually caused by the rough coding, insufficient understanding of requirements, and unskilled programming skills. Vulnerabilities related to implementation are often hidden due to inadequate testing and review. However, if the system is well designed, you can correct these vulnerabilities without changing the design:

· Timing problems:
The most harmful timing problem is resource competition. This problem occurs when two threads that are not properly synchronized compete for the same resource at the same time. In these two mutually influential threads, or in unremitting calls, the object is abandoned in an invalid state, or when malicious code exploits resources that are being used by another thread and are not well protected, security vulnerabilities may occur. The common solution is to simply add synchronization measures.

· Inadequate input validation:
System input must be verified before use. Although some inputs come from trust sources, for security reasons, all these inputs should be considered untrusted and dangerous sources. Input that has not been fully checked may cause a large number of serious security vulnerabilities.

· Improper Random Number:
A good encryption system requires a high-quality random number generator. A large number of security vulnerabilities in Netscape Navigator came from inappropriate random number generators. The valid keys generated by the random number generator cannot reach the recommended length, and the results are easily cracked.

· Design defects:
The security problem originated from the implementation is already terrible, but the worst case is caused by lack of long-term considerations in design and insufficient understanding of languages and function libraries. This vulnerability usually makes the program logic ambiguous and takes a lot of time and patience to get rid of it. Even so, it will be very difficult. The InterBase vulnerability mentioned above is an excellent column.

· Initialization problems:
As we all know, the "new" operation is not the only way to create a new real column. You can also create new real columns using methods like clone. You can create real columns in unconventional ways to mess up security systems of classes.

· Visibility and scalability:
Visibility (whether the class or its members are public or private), scalability (whether the subclass can inherit a class or method) provides software developers with very important tools. However, improper use may also cause some subtle vulnerabilities.
In a subclass column, a subclass can change the conventions and definitions inherited from the superclasses. The extended Code uses some of its own conventions to undermine program security. Solution: reasonably use the "final" keyword to prevent the subclass from being redefined.
Similarly, you can use the keyword "private" to prevent the internal flow and status of the class from being modified. Otherwise, you may expose the internal details of the class to the class subsequently added to the package.

· Never place "backdoors ":
The Design of InterBase provides us with such a column. You cannot create any backdoor code in the program without authorization. These codes are usually in the form of password verification and data encryption. This is not an obstacle for a stubborn hacker. Once the backdoor is cracked, Pandora's magic box is opened.

· Sun also makes mistakes:
I highly respect Sun engineers. However, although they are talented people, they still make mistakes like you and me.
On July 15, February 23, Sun announced that it had discovered a vulnerability in JDK. Their statement is as follows:
"Vulnerabilities in some Java runtime versions may allow malicious Java code to execute unauthorized commands. However, the malicious command code must have been authorized to execute the Code ."
If such code is given at least one executable command (such as echo) in an environment ), this vulnerability allows untrusted Java code to activate any executable commands (such as formatting ). Such errors may be hidden for a long time without being detected.
Let's take a look at the specific code: this vulnerability is located in the exec () method in the java. lang. Runtime class:
Public Process exec (String [] arstringCommand, String [] arstringEnvironment)
Throws IOException
{
// Ensure that the array parameters aren't null, their elements
// Aren't null, etc.
.
.
.
// Do some stuff.
.
.
.
// Get the security manager.
SecurityManager securitymanager = System. getSecurityManager ();
// Check the first element of the command array -- which shold
// Be the name of the executable to invoke. Ensure that it has
// Executable privilege.
If (securitymanager! = Null)
Securitymanager. checkExec (arstringCommand [0]);
// Now, invoke the executable.
Return execInternal (arstringCommand, arstringEnvironment );
}
Do you see the problem?
This error is located in the last three lines (excluding comments and spaces ). First, the security manager checks the executable name to see whether the authorization is performed in the configuration file. Next, run the code. Alas! In a multi-threaded environment, the content of the parameter array can be changed between the two steps. Since these two input parameter arrays are directly used, the caller still has control over their references and can modify their content.
Correct: copy the input array immediately and perform operations in the copy operation.

· Return to the best exercise:
Through old-fashioned software development exercises, you can find many vulnerabilities that cause security problems. Clear requirements, strict design verification, complete code verification, and detailed tests can be used to dig out many vulnerabilities and further improve the overall quality of the software.