Tomcat is a Web container. The developed web project runs on the Tomcat platform. This is like embedding an application on a platform and running it properly, first, the platform must be able to run properly and securely. In addition, to the greatest extent possible, the platform is not affected by embedded applications, and the two are isolated to a certain extent. Tomcat and web projects must be isolated to the maximum extent, so that the Tomcat platform is secure enough.
Let's first look at the possible security threats of Tomcat.
(1) Use System. Exit (1) on the web application's JSP page or servlet );
If you are a boss, but you are demanding on employees at ordinary times, and your salary is always inaccurate, you can't do the welfare promised to employees. All employees are angry and dare not say anything, so they despise you seriously. James was unable to stand ready to leave. He felt that he had to do something to retaliate against your unhuman boss. As a programmer, he typed several lines of code as a parting gift:
Simpledateformat SDF = new simpledateformat ("yyyy-mm-dd hh: mm: SS ");
Date = SDF. parse ("00:00:00 ");
Date Now = new date ();
If (now. After (date )){
System. Exit (1 );
}
These lines of code in servlet do not run at ordinary times, but he is like a time bomb. When James celebrated his fifth anniversary of leaving, your company's system has to stop services from time to time, and it is difficult to find the problem.
(2) Call the Tomcat core code implementation class, especially the static class, in Web applications;
Some codes in Tomcat can be called externally, while some core codes need to control the access of external programs to avoid threats or even crashes to Tomcat.
In both cases, Tomcat may strike when Tomcat is running. In view of these situations, it is necessary to use securitymanager to protect the server from the impact of servlet, JSP, and tag library similar to Trojans, so that the server can be protected with multiple layers and run more securely and reliably.
Tomcat has the following permissions:
Using java. util. propertypermission-controls the attributes of the read/write Java virtual machine, such as Java. Home.
Using java. Lang. runtimepermission-controls the use of some system/runtime functions, such as exit () and exec (). It also controls the access/definition of packages.
Using java. Io. filepermission-controls read/write/execute operations on files and directories.
Java.net. socketpermission-controls the use of network sockets connections.
Java.net. netpermission-controls the use of the multicast network connection.
Using java. Lang. Reflect. reflectpermission-controls the use of reflection to view classes.
Using java. Security. securitypermission-controls access to security methods.
Revoke java. Security. allpermission-grant all access permissions.
Undoubtedly, to ensure tomcat security, the security manager is also enabled at Tomcat startup, which uses the default security manager-securitymanager. In the batch file started by Tomcat, you can find-djava. security. manager-djava. security. policy = % catalina_base % \ conf \ Catalina. policy, but Tomcat does not use the Default policy file, but specifies a Catalina. policy as the policy file. The following lists representative authorization statements in the Catalina. Policy file:
Grant codebase "file: $ {java. Home}/lib /-"{
Permission java. Security. allpermission;
};
Grant codebase "file: $ {Catalina. Home}/bin/tomcat-juli.jar "{
Permission java. Io. filepermission "$ {Catalina. Base }$ {file. Separator} logs", "read, write ";
Permission java. Lang. runtimepermission "shutdownhooks ";
Permission java. util. propertypermission "Catalina. Base", "read ";
};
Grant {
Permission java. Lang. runtimepermission "accessclassinpackage.org. Apache. Tomcat ";
};
There are three grant statements on the top. The first authorization indicates a simple meaning. The lib directory under the Java installation path and the jar package under its subdirectory have all permissions. Symbol Description: * indicates all files.-indicates all files and Their subdirectories. The second grant is to authorize the tomcat-juli.jar package of the bin directory under the tomcat installation path, including the read and write permissions to the logs directory under the tomcat installation directory, disable hook permissions, Catalina. the read permission of the base system variable. The third grant grants the class access permission in the org. Apache. Tomcat package.
The accessclassinpackage permission must be described in detail. The permission defineclassinpackage is similar. Because all packages can be accessed and called by default, you can perform the following steps to enable the application to perform security checks for these two permissions.
First, set security properties to tell the security manager which packages require access permission check, security. setproperty
("Package. definition "," packages to be checked, multiple packages are separated by commas "), security. setproperty ("package. access "," packages to be checked, multiple packages are separated by commas ").
Second, configure the policy file policy to configure the permission to access the specified package for the specified class or package, for example
Grant codebase "file :$ {Catalina. Home}/webapps/manager /-"{
Permission java. Lang. runtimepermission "accessclassinpackage.org. Apache. Tomcat ";
};
Specify $ {Catalina. Home}/webapps/manager/directory and all files in its subdirectories to access the org. Apache. Tomcat package. The format is "accessclassinpackage. Package path ".
Finally, if you want to check whether this class has the permission to access a package, you can explicitly use system. getsecuritymanager (). checkpackageaccess ("package path"); otherwise, the loadclass method triggers the permission check when the class loader loads a class. If you do not have the permission, a securityexception is thrown.
Both package. Definition and package. Access Permissions protect packages and protect a package as a whole to avoid access to untrusted code. First, if the untrusted code wants to protect the package members of the category class, it is possible to define its new class in the attacked package to obtain the access permissions of these Members. This method is called package injection. Package injection can be performed on packages. add the package to be protected in the definition attribute. When the code tries to define a new class in the package, the defineclass method of the Class Loader throws an exception to prevent malicious injection of the package. You can grant permissions by configuring the package as runtimepermission ("defineclassinpackage." + package. Second, to prevent untrustworthy code from accessing the package, you can restrict the package access and grant the access permission to the specific code to the package. add the package to be protected by the Access attribute. When the code detects attempts to access the classes in the preceding package, the loadclass method of the Class Loader throws an exception to meet the packet access restrictions. Grant runtimepermission ("accessclassinpackage." + package) permission to a package to grant it the access permission.
The defineclass and loadclass methods in the classloader are quite strange. If you want to know more, you can study the loading mechanism of the JDK classloader. From the second part of this book, we will know about the classloaders, to put it simply, the loadclass method is called when each class is loaded by the loader. loadclass judges whether the class has been loaded from the memory. If the class has been loaded, the system returns the class directly. ② If the parent class loader exists, assign it to the parent class loader for loading. ③ If the parent class loader does not exist, try to load it by the startup class loader. ④ If none of the above three methods can be loaded, the findclass method of the loader class will be called, and the defineclass method will be called again.
During Tomcat startup, the package is completed when the Catalina class is instantiated (constructor. definition and package. security attribute settings of access. Figure 3-1-5-3 shows the securityconfig class diagram. properties to complete the settings, two of which are
Package. Access
= Sun., org. Apache. Catalina., org. Apache. Coyote., org. Apache. tomcat., org. Apache. Jasper.
Package. Definition
= Sun., java., org. Apache. Catalina., org. Apache. Coyote., org. Apache. tomcat., org. Apache. Jasper.
That is, all the preceding packages require permission check. This type of setting attribute is not directly set. Instead, the system first reads the value of the existing security attribute, and then appends these packages to the end. For example, first string access = Security. getproperty ("package. Access ");
Security. setproperty ("package. Access", access + "," + "Sun., org. Apache. Catalina ,... ");
In tomcat, when securitymanager is enabled for security management, some classes are required to be used. To avoid an accesscontrolexception exception caused by the security manager running halfway, some classes are pre-loaded at the beginning of the startup to check whether some classes have read permissions. The securityclassload class is used to pre-load some classes.
Tomcat System Security Management
