Servlet & JSP (23)

Let's discuss how to develop secure Web applications. Most resources on the network are open and free of charge. However, some resources can only be accessed by specific users. For example, a forum can only be spoken by registered users, and administrators can manage background programs. To allow different users to access different resources, security mechanisms must be used to protect web application resources and prevent unauthorized users from accessing key information.

Verification Mechanism

In the servlet specification, four user authentication mechanisms are defined.

HTTP Basic Authentication

HTTP basic authentication is defined in HTTP 1.0 based on the user name and password authentication mechanism. When a web browser requests a protected resource, the web server will pop up a dialog box asking the user to enter the user name and password. The Web Client obtains the user name and password from the user, and then sends it to the server. The server is responsible for verification. If the password is correct, the server will send the resource requested by the user.

HTTP digest Authentication

Similar to HTTP basic verification, HTTP digest verification also verifies users based on the user name and password. The difference is that digest verification is used, the user password is transmitted in encrypted form (the password is transmitted using the MD5 Digest algorithm), which is much safer than base64 encoding.

HTTP client authentication

HTTPS (secure HTTP) is an HTTP Protocol over SSL (Secure Socket Layer, secure socket. SSL is a security protocol proposed by Netscape in 1995. It is used to establish a secure connection between browser sockets and server sockets. SSL is composed of two sub-protocols, one for establishing secure connections and the other for using secure connections. After a secure connection is established, both parties use the same session key to encrypt the transmitted information. HTTPS client verification is mainly used in e-commerce applications.

Form baesd Authentication

Form-based verification is similar to basic verification. The difference is that customized HTML forms are used for form-based authentication to allow users to enter the user name and password, rather than the pop-up dialog box in the browser.

Declarative Security

Declarative security is to specify the Security Processing Mechanism of Web applications in the web. xml file, so that a Web application can obtain security without modifying any source code. By default, all resources of web applications are open to everyone. Configure the <security-constraint> and <login-config> elements in Web. XML to restrict access to resources.

<?xml version="1.0" encoding="ISO-8859-1"?><web-app xmlns="http://java.sun.com/xml/ns/javaee"  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  xsi:schemaLocation="http://java.sun.com/xml/ns/javaee                      http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"  version="3.0"  metadata-complete="true">  <!-- Define a Security Constraint on this Application -->  <!-- NOTE:  None of these roles are present in the default users file -->  <security-constraint>    <web-resource-collection>      <web-resource-name>Protected Area</web-resource-name>      <url-pattern>*.html</url-pattern>  <url-pattern>*.jsp</url-pattern>    

If the <URL-pattern> element is not used under the <web-resource-collection> element, security restrictions must be applied to all HTTP methods. If this element is used, only security restrictions are imposed on the specified HTTP method.
The <auth-constraint> element specifies the role that can access protected resources. <Role-Name> specifies the role name. The two names must be the role name specified in <security-role>, or use the reserved role name "*". all roles in the Web application. If the <role-Name> sub-element is not specified in the <auth-constraint> element, it indicates that no user can access protected resources under any circumstances, if the <role-Name> sub-element is defined, the specified user can access the protected resource. If the <auth-constraint> element is not used, the container allows users to access protected resources without authentication.
The <login-config> element specifies the authentication mechanism used by web applications. <Auth-method> the element configures the web application verification mechanism. The value of this element must be either basic, digest, form, or client-cert, or the verification mode specified by the product supplier. Except form, you only need to configure the other three types of verification in <auth-method>.
Procedural security
In daily applications, we may need multiple users or roles to have the permission to access a resource. In this way, more fine-grained security control cannot be achieved through declarative security. At this point, we can further implement fine-grained security control in the program code. Programmatic security consists of three methods defined in the httpservletrequest interface, as shown below:

Public String getremoteuser () // if the user has been verified, this method returns the user's login name. Otherwise, null is returned. Public java. Security. Principal getuserprincipal () // a principal object is returned. This object contains the currently authenticated user name. If the user name is not verified, null is returned. Public Boolean isuserinrole (string role) // checks whether the verified user role belongs to the specified role. if the user has not been verified, null is returned.

Prevention of SQL injection attacks
Web Application Security involves multiple aspects. The previous section describes how to prevent unauthorized users from accessing protected resources through authentication and authorization. However, sometimes security problems are caused by system vulnerabilities or programmer negligence. For example, the following code:

String name = request.getParameter("username");String passwd = request.getParameter("password");...Statement stmt = conn.createStatement();String sql = "select username from admins where username ="+"'"+name+"' and password = '"+passwd+"'";ResultSet rs = stmt.executeQuery(sql);while(rs.next()) {...}...
If you enter "Shan" and "1234" as the password, the following SQL statement is constructed:
Select username from admins where username = 'shand' and Password = '000000'
If a malicious user enters the user name's text domain and password domain name in the form by viewing the web page source code, enter "http://www.test.com/login.jsp?" directly in the browser URL bar? Username = ABCD & Password = 1111 or '1' = '1' ", the management page is successfully accessed. Why can I access any user name and password? Let's take a look at the constructed SQL statement. As follows:
Select username from admins where username = 'shand' and Password = '000000' or '1' = '1'
The final '1' = '1' is a constant condition. Therefore, this malicious user uses the features of SQL statements to construct a special query, so that the statements that were originally not established become valid. This is an example of SQL injection attacks.
In Java, to prevent the above situation, you only need to replace statement with preparedstatement. Therefore, preparedstatement should be used whenever possible in practical applications.
Reprinted please indicate the source:Http://blog.csdn.net/iAm333