Java Server Programming security (1)

I. Overview
Writing Secure Internet applications is not a breeze: you only need to look at the various professional bulletin boards to find continuous security vulnerability reports. How do you ensure that your Internet applications are not as vulnerable as those of others? How do you ensure that your name will not appear in embarrassing reports of major security incidents?
If you use Java Servlet, JavaServer Pages (JSP), or EJB, many difficult problems have been solved in advance. Of course, vulnerabilities may still occur. Next, let's take a look at what these vulnerabilities are and why Java programmers don't have to worry about problems that some C and Perl programmers must face.
C programmers should be familiar with security vulnerabilities, but projects such as OpenBSD provide security systems to deal with such problems. Java has 20 years less experience in solving such problems than C. On the other hand, Java was born as a client programming language, and the client has more stringent security requirements than the server. It means that the development of Java has a solid security foundation.
Java originally targets browsers. However, although the Java virtual machine carried by the browser is good, it is not perfect. Sun's Chronology of security-related bugs and issues summarizes the vulnerability discovery history in the runtime environment. We know that when Java is used as a server-side programming language, these vulnerabilities cannot be used as attacks. However, even if Java is used as the client programming language, the number of major security problems has been reduced from 6 in 1996 (3 of which are quite serious) to 1 in 2000. However, this relative increase in security does not mean that Java is absolutely secure as a server-side programming language. It only means that attackers can use more and more attack methods. So what are the locations that are vulnerable to attacks and how are other programming languages facing similar problems?
II. Cache overflow
In C programs, cache overflow is the most common security risk. Cache overflow occurs when the user input exceeds the allocated memory space (for user input. Cache overflow may be a key cause of application overwriting. C programs are prone to cache overflow, but Java programs are almost impossible to have cache overflow.
The C code for reading input data from the input stream is usually as follows:
Char buffer [1000];
Int len = read (buffer );
Because the cache size is determined before reading the data, it is very difficult for the system to check whether the cache reserved for the input is sufficient. Cache overflow allows users to overwrite the key part of the program data structure, which brings security risks. Experienced Attackers can exploit this to directly insert code and data into running programs.
In Java, we generally use strings instead of character arrays to save user input. The Java code equivalent to the preceding C code is as follows:
String buffer = in. readLine ();
Here, the cache size is always exactly the same as the size of the input content. Because the Java string cannot be changed after it is created, cache overflow cannot occur. In other words, the character array is used to replace the string as the cache, and Java is not as easy as C to generate a security vulnerability that can be exploited by attackers. For example, the following Java code will overflow: