Summary: There are several ways to expose JSP code, but after a lot of testing, this has an absolute relationship with the configuration of WEB SERVER. Take IBM Websphere Commerce Suite for example. There are other ways to see the source code of JSP, but I believe it is caused by the configuration of IBM HTTP SERVER.
If you want to find bugs that JSP expose source code, you need to understand how JSP works.
JSP works differently from other PHP and ASP, although it is also a web programming language. The first call to a JSP file is actually a process of compiling into a Servlet. Pay attention, we have to make an article on this, do you understand? What we want to do is to let the JSP be sent to the client as a text or other file by the browser before compilation, or to directly read the JSP content and send it to the client without executing the compiled servlet when the JSP is loaded.
Once you understand the truth and the purpose you want to achieve, you can start. If you carefully observe the call and return process, you will find that JSP is compiled for servlets to be saved in the specified directory, such as: /lovehacker/ is likely to be stored in X:\IBM\WAServer\temp\default_host\default_app\pagecompile\_lovehacker_index_xjsp.class, which has been compiled. _lovehacker_index_xjsp.class is obviously a file we don't need, and it's unlikely that we can get it. What we want to do is not to execute _lovehacker_index_xjsp.class but to read the content directly.
According to analysis, the initial exposure of the source code was also caused by the previous idea. The directory originally stored a _xxx_xjsp.class, but access was originally a legal request, and the corresponding servlet could not be found, so it was sent to the user as a text or other file.
Maybe this is caused by improper configuration of IBM HTTP SERVER, but I believe that if it succeeds, it will have a sense of accomplishment, which is very satisfying!
By the way, exposing the real path of file storage may bring harm:
1. First let the intruder understand the disk configuration
2. Ming intruders can even analyze the level of administrators
3. Provides convenience for intruders to modify your homepage (at least you don’t have to find your WEB directory on that disk)
4. Some other CGI vulnerabilities may be used to find files in the web directory, such as, etc.
What are the main aspects of JSP security issues?
This section focuses on classifying and expounding JSP security issues and making suggestions for solving them. Therefore, each type of security issues only uses one example. The specific details of other vulnerabilities such as what software version and operating system are involved, etc. will not be explained one by one. Interested readers can go to JSP enthusiasts () or foreign security sites () for viewing and reference.
According to the JSP security issues that have been discovered so far, you might as well divide them into the following categories, source code exposure classes, remote program execution classes and other categories. Let’s take a look at the specific things below.
1. Source code exposure class
The source code exposure category mainly refers to the program source code will be returned to the visitor in plain text.
We know that dynamic programs such as jsp, asp, and php are executed on the server side, and after execution, they will only return to the visitors' standard html and other code. This is a theoretical thing. In fact, due to problems with the internal mechanism of the server, it may cause vulnerabilities exposed to the source code. For simple example, just add a few simple characters to the program file name to obtain the program code, such as the common vulnerabilities of +.htr, %81, etc. of Microsoft asp.
1. Adding special suffix causes jsp source code to be exposed
There are also problems similar to those of asp vulnerabilities in jsp, such as IBM Websphere Application Server 3.0.21, BEA Systems Weblogic 4.5.1, Tomcat3.1 and other jsp file suffix capital vulnerabilities; add special characters after jsp file such as %82, ../ vulnerabilities of Resin1.2; %2E, + vulnerabilities of ServletExec, etc.
Example: Tomcat 3.1 is originally http://localhost:8080/ in the browser, which can be interpreted and executed normally, but if you try it if you change it to or wait, you will find that the browser will prompt you to download this file, and after downloading the source code, you can read it completely.
Reason: JSP is case sensitive. Tomcat will only execute lowercase jsp suffix files as normal jsp files. If uppercase, Tomcat will be treated as a downloadable file for customers to download. This problem exists in the old version of WebLogic, WebShpere, etc., and now these companies have either released new versions or released patches to solve this problem.
Solution: First, download the patch on the server software website; because the author has used asp for a period of time and has been exposed to many IIS vulnerabilities, its effective solution is to remove unnecessary mappings such as htr, htx, etc. In jsp, we can also refer to the IIS solution. The difference is whether to remove them but add mappings. The method is to add some mappings such as .JSP, .Jsp, .jsp%2E, etc. to the server settings, and map them to a servlet written by yourself. The only function of this servlet is to direct the request to a custom error page similar to 404 not found. Different server settings are also different. Please refer to the corresponding document. The second solution can be used when there is no patch.
2. Inserting special strings causes jsp source code to be exposed
There is also a vulnerability caused by inserting special strings, a vulnerability with the beginning of "/file/" in BEA WebLogic Enterprise 5.1 file path, a vulnerability with the beginning of "/servlet/file/" file in IBM WebSphere 3.0.2, etc.
Example: For example, in IBM WebSphere 3.0.2, if the URL of a request file is "":/, then accessing /servlet/file/ will see the source code of the file.
Cause: Because IBM WebSphere 3.0.2 calls different servlets to process different pages, if a requested file is not registered and managed, WebSphere will use a default servlet call. If the file path starts with "/servlet/file/", this default servlet will be called. The file that requested will be displayed without being analyzed or compiled.
Solution: Download the latest patch on the server software website.
3. File jsp source code exposure caused by path permissions
We know that most jsp applications will have a WEB-INF directory in the current directory. This directory usually stores the class file compiled by JavaBeans. If you do not set normal permissions for this directory, all classes will be exposed.
Example: If you use Apache1.3.12 plus third-party jsp software, because the default settings of Apache1.3.12 can read the directory. If the program is in /, just modify /WEB-INF/ all the class files in the subdirectories under this directory and this directory can be viewed completely and can be downloaded to this machine.
Some people may say that class is compiled, and even if it is downloaded, it doesn't matter. However, there are many softwares for class decompiling into Java code. Some people once used JAD software to decompile the downloaded class file, but it was almost exactly the same as the original Java file, and the variable names have not changed. What's even more surprising is that it can be recompiled into class file and used normally.
What's even bigger is that web page makers began to write the username and password of the database in Java code. Now, anyone can see important information about the database once they are decompiled. Through the remote connection function of the database, you can easily enter your database, and all the information is in his hands. As a side note, if the user can obtain the SQL Server username password, enter the database and execute any dos commands such as viewing c:\files, creating and deleting directories, etc., the entire Windows system will not be safe.
Solution: A previous method to effectively solve the asp vulnerability in IIS was to place the asp program separately in a directory, and the user permissions can only be executed but not read in the directory settings. In the jsp environment, you can also solve this problem by setting up the server environment. Simply put, you set the access permissions on some more important directories such as WEB-INF, classes, etc., and do not allow reading but only allow execution. Taking the solution under apache as an example, you can add a directory WEB-INF to the file and set properties such as Deny from all.
Another relatively stupid solution is to add a default starting page such as etc. to each important directory, so that the read directory will be returned to the visitor's file instead of others. One method recommended.
More importantly, the password saving issue. In jsp, you can write a property file, place it in the WINNT system directory, and then use a bean to read the database information. In this way, the source code knows that the database information exists in the .property file in WINNT, but it is also difficult to access it. In this way, even if the source code is known to be at least the database is safe.
4. The absolute path exposure problem caused by the non-existence of the file
I believe everyone is familiar with this issue, because there are also many similar issues in Microsoft IIS. For example, *.idc in Microsoft IIS5.0 exposed absolute path vulnerabilities. The same problems are now transferred to the JSSP environment. This vulnerability exposes the absolute hard disk address of the web program, and it is more harmful to combine it with other vulnerabilities.
Example: Under a specific server software, if you access a non-existent jsp file such as http://localhost:8080/, you will return an error like: : c:\web\app\ (????????????) so that you can know that the website is in the c:\web\app directory. Maybe most people don't care much, but it is very helpful for a hacker.
Reason: This situation was not filtered out when handling exceptions in the relevant Servlet responsible for jsp execution.
Solution: First, download the latest patch; if the web server software did not have this patch at that time, you can find the server software's jsp execution mapping Servlet file (of course, the class suffix) and decompile it with JAD software. Find the method to handle Exception in the decompiled source code, and then comment out all the processing parts in the method and direct the request to a custom error page. This problem is solved.
2. Remote program execution class
The characteristic of this type of vulnerability is that it can execute commands and programs on any server in the browser through the URL address, thereby causing security issues. For example, the Allaire JRUN 2.3 remote execution of any command vulnerability, the iPlanet Web Server has a buffer overflow vulnerability, etc.
Example: Enter the following URL address http://jrun:8000/servlet/jsp/../../path/ on Allaire's JRUN server 2.3 to access files outside the WEB directory. If it is an exe file, it may cause execution.
Cause: If the target file requested by the URL uses the prefix "/servlet/", the JSP interpretation execution function is activated. At this time, use "../" in the target file path requested by the user, and it is possible to access files outside the root directory on the WEB server. Using this vulnerability on the target host to request a file generated by the user input will seriously threaten the security of the target host system.
Workaround: Install the latest patch.
III. Other categories
The scope of these categories is a bit large, which can include vulnerabilities in databases such as SQL Server, Oracle, DB2, etc., as well as vulnerabilities in operating systems such as WindowsNT/2000, Linux, etc. The vulnerabilities of these things can be said to be fatal. For example, using certain Linux vulnerabilities can easily obtain administrator rights to remotely control the server and obtain full control of the system. This is much easier to obtain jsp source code or destroy the server than to trample an ant to death.
4. Full text summary
From the above content, we can see that JSP still has many security problems, just like Asp. Objectively speaking, it is impossible for the developer of server software to find all bugs in the system in internal testing. Even after the software is released, the vulnerabilities found will only be a small part of them, and new security problems will continue to appear in the future. Therefore, we must always be vigilant and pay attention to the security of our website.
A good suggestion is to read more security articles. These security articles generally have detailed information such as the software version number, the cause of the vulnerability, etc. The most important thing is to come with a solution or a patch download link. The recommended security site is a domestic security site or a foreign site. Another good suggestion is to install more patches, visit the homepage of the software company you use, and get the latest patches from it. The best done is Microsoft's site, and security announcements and patches are particularly timely.
Finally, I want to use one sentence as the end of the full text: an excellent hacker may not be a good jsp programmer, an excellent jsp programmer must be a good quasi-hacker.
What methods can implement the application security of Java Servlets and JSP?
A web application can have multiple resources, and often there is a lot of sensitive information transmitted over an open network without protection. In this environment, many web applications actually have some degree of security requirements. Most servlet containers have clear mechanisms and structures to meet this security requirement. Although the details of guarantee and execution may be somewhat different, they both have the following characteristics:
1. Authentication: Communication entities verify each other's behaviors in a clear identity.
2. Access control for resources: A mechanism that emphasizes availability, integrity, or confidentiality for a group of users.
3. Data Integrity: A mechanism to ensure that data is not modified by third parties during the transmission process.
4. Confidentiality or Data Privacy: A mechanism that ensures that data can be used only by authorized users and can be safely passed.
Java Servlet, security in JSP is implemented in the following ways:
1. Declarative Security
Declarative security refers to expressing an application's security structure, including roles, access controls, and verification required in an application's external form. Publishing a descriptor in a web application is a major tool for implementing declarative security.
The publisher maps the logical integrity required by the application to security policies in a specific operating environment. At runtime, the servlet container uses these policies to force verification.
2. Programmatic Security
Programmatic Security can be used when declarative security cannot fully express an application's security model. Programmatic Security includes the following methods of the HttpServletRequest interface:
getRemoteUser
isUserInRole
getUserPrincipal
The getRemoteUser method returns the username that has been authenticated by the client. IsUserInRole asks the container's security mechanism whether a specific user is in a given security role. The GetUserPrinciple method returns an object. These APIs allow servlets to complete some logical judgments based on the logical role of remote users. It can also allow the servlet to determine the main name of the current user. If getRemoteUser returns a null value (which means no user is verified), then isUserInRole will always return false and getUserPrinciple will always return null.
3. Roles
A Roles is an abstract logical user group defined by Application Developer and Assembler. When an application is published, Deployer maps these roles to security authentication, such as groups or rules, in the runtime environment.
A servlet container is able to perform some description or programmatic security for rules that are associated with the requirements entered in calling the security properties of these principals. For example:
1. When the deployer maps a security role to a user group in the operating environment, the user group to which the principal belongs is obtained from the security attributes. If the principal's user group matches the user group in the operating environment, then principal is a security role.
2. When deployer maps a security role to a principal name in the security policy domain, the principal name that calls principal is indeed extracted from the security attribute. If both are the same, the calling principal is safe.
4. Authentication
A web client can use one of the following mechanisms to authenticate a user to the web server.
HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication
5. HTTP Basic Authentication
HTTP Basic Authentication is a verification mechanism defined in the HTTP/1.1 specification. This mechanism is based on username and password. A web server requires a web client to verify a user. As part of the request, the web server passes a string called realm in which the user is verified. Note: The realm string of the Basic Authentication mechanism does not necessarily reflect any security policy domain. The web client gets these usernames and passwords and passes them to the web server. The web server then authenticates these users in a specific domain.
Since the password is passed using a 64-bit encoding and the purpose server is not authenticated, Basic Authentication is not a secure authentication protocol. However, some additional protections like using a secure transport mechanism (HTTPS) or using security measures at the network layer can solve some problems.
6. HTTP Digest Authentication
Like HTTP Digest Authentication, HTTP Digest Authentication authenticates a user based on a username and password. However, the transmission of passwords is carried out in an encrypted form, which is much safer than the 64-bit encoding form used by Basic Authentication. This approach is not secure with a personal key scheme like HTTPS Client Authentication. Since Digest Authentication is not currently widely used, servlet containers do not require support but encourage support.
7. HTTPS Client Authentication
End-user authentication using HTTPS (HTTP over SSL) is a strict non-authentication mechanism. This mechanism requires users to process public key certificates (Public Key Certification PKC). Currently, PKCs are useful in e-commerce applications. servlet containers that are not suitable for J2EE do not require support for HTTPS protocol.
8. Server Tracking of Authentication Information
Just like security identities mapped in a role, the runtime environment is an explanation of the environment rather than an application description.
1. Create a login mechanism and policy in the publishing environment of the web application.
2. The same verification information can be used to represent the principal of these applications for applications published in the same container.
3. Re-verification is required only when passing the security policy domain.
Therefore, a servlet container requires that this verification information be tracked at the container layer, not at the application layer. Allows a validated user to reject an application using other resources, which is managed by containers subject to the same security identification restrictions.
If you want to find bugs that JSP expose source code, you need to understand how JSP works.
JSP works differently from other PHP and ASP, although it is also a web programming language. The first call to a JSP file is actually a process of compiling into a Servlet. Pay attention, we have to make an article on this, do you understand? What we want to do is to let the JSP be sent to the client as a text or other file by the browser before compilation, or to directly read the JSP content and send it to the client without executing the compiled servlet when the JSP is loaded.
Once you understand the truth and the purpose you want to achieve, you can start. If you carefully observe the call and return process, you will find that JSP is compiled for servlets to be saved in the specified directory, such as: /lovehacker/ is likely to be stored in X:\IBM\WAServer\temp\default_host\default_app\pagecompile\_lovehacker_index_xjsp.class, which has been compiled. _lovehacker_index_xjsp.class is obviously a file we don't need, and it's unlikely that we can get it. What we want to do is not to execute _lovehacker_index_xjsp.class but to read the content directly.
According to analysis, the initial exposure of the source code was also caused by the previous idea. The directory originally stored a _xxx_xjsp.class, but access was originally a legal request, and the corresponding servlet could not be found, so it was sent to the user as a text or other file.
Maybe this is caused by improper configuration of IBM HTTP SERVER, but I believe that if it succeeds, it will have a sense of accomplishment, which is very satisfying!
By the way, exposing the real path of file storage may bring harm:
1. First let the intruder understand the disk configuration
2. Ming intruders can even analyze the level of administrators
3. Provides convenience for intruders to modify your homepage (at least you don’t have to find your WEB directory on that disk)
4. Some other CGI vulnerabilities may be used to find files in the web directory, such as, etc.
What are the main aspects of JSP security issues?
This section focuses on classifying and expounding JSP security issues and making suggestions for solving them. Therefore, each type of security issues only uses one example. The specific details of other vulnerabilities such as what software version and operating system are involved, etc. will not be explained one by one. Interested readers can go to JSP enthusiasts () or foreign security sites () for viewing and reference.
According to the JSP security issues that have been discovered so far, you might as well divide them into the following categories, source code exposure classes, remote program execution classes and other categories. Let’s take a look at the specific things below.
1. Source code exposure class
The source code exposure category mainly refers to the program source code will be returned to the visitor in plain text.
We know that dynamic programs such as jsp, asp, and php are executed on the server side, and after execution, they will only return to the visitors' standard html and other code. This is a theoretical thing. In fact, due to problems with the internal mechanism of the server, it may cause vulnerabilities exposed to the source code. For simple example, just add a few simple characters to the program file name to obtain the program code, such as the common vulnerabilities of +.htr, %81, etc. of Microsoft asp.
1. Adding special suffix causes jsp source code to be exposed
There are also problems similar to those of asp vulnerabilities in jsp, such as IBM Websphere Application Server 3.0.21, BEA Systems Weblogic 4.5.1, Tomcat3.1 and other jsp file suffix capital vulnerabilities; add special characters after jsp file such as %82, ../ vulnerabilities of Resin1.2; %2E, + vulnerabilities of ServletExec, etc.
Example: Tomcat 3.1 is originally http://localhost:8080/ in the browser, which can be interpreted and executed normally, but if you try it if you change it to or wait, you will find that the browser will prompt you to download this file, and after downloading the source code, you can read it completely.
Reason: JSP is case sensitive. Tomcat will only execute lowercase jsp suffix files as normal jsp files. If uppercase, Tomcat will be treated as a downloadable file for customers to download. This problem exists in the old version of WebLogic, WebShpere, etc., and now these companies have either released new versions or released patches to solve this problem.
Solution: First, download the patch on the server software website; because the author has used asp for a period of time and has been exposed to many IIS vulnerabilities, its effective solution is to remove unnecessary mappings such as htr, htx, etc. In jsp, we can also refer to the IIS solution. The difference is whether to remove them but add mappings. The method is to add some mappings such as .JSP, .Jsp, .jsp%2E, etc. to the server settings, and map them to a servlet written by yourself. The only function of this servlet is to direct the request to a custom error page similar to 404 not found. Different server settings are also different. Please refer to the corresponding document. The second solution can be used when there is no patch.
2. Inserting special strings causes jsp source code to be exposed
There is also a vulnerability caused by inserting special strings, a vulnerability with the beginning of "/file/" in BEA WebLogic Enterprise 5.1 file path, a vulnerability with the beginning of "/servlet/file/" file in IBM WebSphere 3.0.2, etc.
Example: For example, in IBM WebSphere 3.0.2, if the URL of a request file is "":/, then accessing /servlet/file/ will see the source code of the file.
Cause: Because IBM WebSphere 3.0.2 calls different servlets to process different pages, if a requested file is not registered and managed, WebSphere will use a default servlet call. If the file path starts with "/servlet/file/", this default servlet will be called. The file that requested will be displayed without being analyzed or compiled.
Solution: Download the latest patch on the server software website.
3. File jsp source code exposure caused by path permissions
We know that most jsp applications will have a WEB-INF directory in the current directory. This directory usually stores the class file compiled by JavaBeans. If you do not set normal permissions for this directory, all classes will be exposed.
Example: If you use Apache1.3.12 plus third-party jsp software, because the default settings of Apache1.3.12 can read the directory. If the program is in /, just modify /WEB-INF/ all the class files in the subdirectories under this directory and this directory can be viewed completely and can be downloaded to this machine.
Some people may say that class is compiled, and even if it is downloaded, it doesn't matter. However, there are many softwares for class decompiling into Java code. Some people once used JAD software to decompile the downloaded class file, but it was almost exactly the same as the original Java file, and the variable names have not changed. What's even more surprising is that it can be recompiled into class file and used normally.
What's even bigger is that web page makers began to write the username and password of the database in Java code. Now, anyone can see important information about the database once they are decompiled. Through the remote connection function of the database, you can easily enter your database, and all the information is in his hands. As a side note, if the user can obtain the SQL Server username password, enter the database and execute any dos commands such as viewing c:\files, creating and deleting directories, etc., the entire Windows system will not be safe.
Solution: A previous method to effectively solve the asp vulnerability in IIS was to place the asp program separately in a directory, and the user permissions can only be executed but not read in the directory settings. In the jsp environment, you can also solve this problem by setting up the server environment. Simply put, you set the access permissions on some more important directories such as WEB-INF, classes, etc., and do not allow reading but only allow execution. Taking the solution under apache as an example, you can add a directory WEB-INF to the file and set properties such as Deny from all.
Another relatively stupid solution is to add a default starting page such as etc. to each important directory, so that the read directory will be returned to the visitor's file instead of others. One method recommended.
More importantly, the password saving issue. In jsp, you can write a property file, place it in the WINNT system directory, and then use a bean to read the database information. In this way, the source code knows that the database information exists in the .property file in WINNT, but it is also difficult to access it. In this way, even if the source code is known to be at least the database is safe.
4. The absolute path exposure problem caused by the non-existence of the file
I believe everyone is familiar with this issue, because there are also many similar issues in Microsoft IIS. For example, *.idc in Microsoft IIS5.0 exposed absolute path vulnerabilities. The same problems are now transferred to the JSSP environment. This vulnerability exposes the absolute hard disk address of the web program, and it is more harmful to combine it with other vulnerabilities.
Example: Under a specific server software, if you access a non-existent jsp file such as http://localhost:8080/, you will return an error like: : c:\web\app\ (????????????) so that you can know that the website is in the c:\web\app directory. Maybe most people don't care much, but it is very helpful for a hacker.
Reason: This situation was not filtered out when handling exceptions in the relevant Servlet responsible for jsp execution.
Solution: First, download the latest patch; if the web server software did not have this patch at that time, you can find the server software's jsp execution mapping Servlet file (of course, the class suffix) and decompile it with JAD software. Find the method to handle Exception in the decompiled source code, and then comment out all the processing parts in the method and direct the request to a custom error page. This problem is solved.
2. Remote program execution class
The characteristic of this type of vulnerability is that it can execute commands and programs on any server in the browser through the URL address, thereby causing security issues. For example, the Allaire JRUN 2.3 remote execution of any command vulnerability, the iPlanet Web Server has a buffer overflow vulnerability, etc.
Example: Enter the following URL address http://jrun:8000/servlet/jsp/../../path/ on Allaire's JRUN server 2.3 to access files outside the WEB directory. If it is an exe file, it may cause execution.
Cause: If the target file requested by the URL uses the prefix "/servlet/", the JSP interpretation execution function is activated. At this time, use "../" in the target file path requested by the user, and it is possible to access files outside the root directory on the WEB server. Using this vulnerability on the target host to request a file generated by the user input will seriously threaten the security of the target host system.
Workaround: Install the latest patch.
III. Other categories
The scope of these categories is a bit large, which can include vulnerabilities in databases such as SQL Server, Oracle, DB2, etc., as well as vulnerabilities in operating systems such as WindowsNT/2000, Linux, etc. The vulnerabilities of these things can be said to be fatal. For example, using certain Linux vulnerabilities can easily obtain administrator rights to remotely control the server and obtain full control of the system. This is much easier to obtain jsp source code or destroy the server than to trample an ant to death.
4. Full text summary
From the above content, we can see that JSP still has many security problems, just like Asp. Objectively speaking, it is impossible for the developer of server software to find all bugs in the system in internal testing. Even after the software is released, the vulnerabilities found will only be a small part of them, and new security problems will continue to appear in the future. Therefore, we must always be vigilant and pay attention to the security of our website.
A good suggestion is to read more security articles. These security articles generally have detailed information such as the software version number, the cause of the vulnerability, etc. The most important thing is to come with a solution or a patch download link. The recommended security site is a domestic security site or a foreign site. Another good suggestion is to install more patches, visit the homepage of the software company you use, and get the latest patches from it. The best done is Microsoft's site, and security announcements and patches are particularly timely.
Finally, I want to use one sentence as the end of the full text: an excellent hacker may not be a good jsp programmer, an excellent jsp programmer must be a good quasi-hacker.
What methods can implement the application security of Java Servlets and JSP?
A web application can have multiple resources, and often there is a lot of sensitive information transmitted over an open network without protection. In this environment, many web applications actually have some degree of security requirements. Most servlet containers have clear mechanisms and structures to meet this security requirement. Although the details of guarantee and execution may be somewhat different, they both have the following characteristics:
1. Authentication: Communication entities verify each other's behaviors in a clear identity.
2. Access control for resources: A mechanism that emphasizes availability, integrity, or confidentiality for a group of users.
3. Data Integrity: A mechanism to ensure that data is not modified by third parties during the transmission process.
4. Confidentiality or Data Privacy: A mechanism that ensures that data can be used only by authorized users and can be safely passed.
Java Servlet, security in JSP is implemented in the following ways:
1. Declarative Security
Declarative security refers to expressing an application's security structure, including roles, access controls, and verification required in an application's external form. Publishing a descriptor in a web application is a major tool for implementing declarative security.
The publisher maps the logical integrity required by the application to security policies in a specific operating environment. At runtime, the servlet container uses these policies to force verification.
2. Programmatic Security
Programmatic Security can be used when declarative security cannot fully express an application's security model. Programmatic Security includes the following methods of the HttpServletRequest interface:
getRemoteUser
isUserInRole
getUserPrincipal
The getRemoteUser method returns the username that has been authenticated by the client. IsUserInRole asks the container's security mechanism whether a specific user is in a given security role. The GetUserPrinciple method returns an object. These APIs allow servlets to complete some logical judgments based on the logical role of remote users. It can also allow the servlet to determine the main name of the current user. If getRemoteUser returns a null value (which means no user is verified), then isUserInRole will always return false and getUserPrinciple will always return null.
3. Roles
A Roles is an abstract logical user group defined by Application Developer and Assembler. When an application is published, Deployer maps these roles to security authentication, such as groups or rules, in the runtime environment.
A servlet container is able to perform some description or programmatic security for rules that are associated with the requirements entered in calling the security properties of these principals. For example:
1. When the deployer maps a security role to a user group in the operating environment, the user group to which the principal belongs is obtained from the security attributes. If the principal's user group matches the user group in the operating environment, then principal is a security role.
2. When deployer maps a security role to a principal name in the security policy domain, the principal name that calls principal is indeed extracted from the security attribute. If both are the same, the calling principal is safe.
4. Authentication
A web client can use one of the following mechanisms to authenticate a user to the web server.
HTTP Digest Authentication
HTTPS Client Authentication
HTTP Basic Authentication
HTTP Based Authentication
5. HTTP Basic Authentication
HTTP Basic Authentication is a verification mechanism defined in the HTTP/1.1 specification. This mechanism is based on username and password. A web server requires a web client to verify a user. As part of the request, the web server passes a string called realm in which the user is verified. Note: The realm string of the Basic Authentication mechanism does not necessarily reflect any security policy domain. The web client gets these usernames and passwords and passes them to the web server. The web server then authenticates these users in a specific domain.
Since the password is passed using a 64-bit encoding and the purpose server is not authenticated, Basic Authentication is not a secure authentication protocol. However, some additional protections like using a secure transport mechanism (HTTPS) or using security measures at the network layer can solve some problems.
6. HTTP Digest Authentication
Like HTTP Digest Authentication, HTTP Digest Authentication authenticates a user based on a username and password. However, the transmission of passwords is carried out in an encrypted form, which is much safer than the 64-bit encoding form used by Basic Authentication. This approach is not secure with a personal key scheme like HTTPS Client Authentication. Since Digest Authentication is not currently widely used, servlet containers do not require support but encourage support.
7. HTTPS Client Authentication
End-user authentication using HTTPS (HTTP over SSL) is a strict non-authentication mechanism. This mechanism requires users to process public key certificates (Public Key Certification PKC). Currently, PKCs are useful in e-commerce applications. servlet containers that are not suitable for J2EE do not require support for HTTPS protocol.
8. Server Tracking of Authentication Information
Just like security identities mapped in a role, the runtime environment is an explanation of the environment rather than an application description.
1. Create a login mechanism and policy in the publishing environment of the web application.
2. The same verification information can be used to represent the principal of these applications for applications published in the same container.
3. Re-verification is required only when passing the security policy domain.
Therefore, a servlet container requires that this verification information be tracked at the container layer, not at the application layer. Allows a validated user to reject an application using other resources, which is managed by containers subject to the same security identification restrictions.