7 Wrong security configurations in the Web. xml file

7 Wrong security configurations in the Web. xml file

There are a large number of articles on configuring authentication and authorization in the Java Web. xml file. Instead of re-explaining how to configure roles, secure Web resources, and set different types of certifications, let's look at some common security error configurations in the Web. xml file.

(1) The custom error page is not configured

By default, Java Web Apps display detailed error information when an error occurs, exposing the server version and detailed stack information, and in some cases, even code snippets of Java code. This information is a boon for hackers who need to find more information about their virus. Fortunately, it is very easy to configure the Web. xml file to show the custom error page. With the following configuration, a very good error page will be displayed whenever the server HTTP500 error occurs at any time. You can add an additional error page to the HTTP status code.

1234	<error-page>         <error-softwaresecurity>500</error-softwaresecurity>         <location>/path/to/error.jsp</location> </error-page>

In addition, the Web. xml file should be configured to prevent detailed error stack information from being displayed, which we can implement by configuring <exception-type>. Because Throwable is the base class for all exception and error in Java, the following code fragment will ensure that stack information is not displayed by the server.

1234	<error-page>         <exception-type>java.lang.Throwable</exception-type>         <location>/path/to/error.jsp</location> </error-page>

However, if you take the following approach, you will still be displaying the stack information:

<%try {        String s = null;        S.length ();} catch (Exception e) {        //don ' t do this!        E.printstacktrace (new PrintWriter (out));} %>

Remember that after you have properly configured your Web. xml file, you need to use reasonable logging techniques .

(2) bypassing authentication and authorization

The following code snippet shows how to set up Web-based access control so that everything in the security directory can only be accessed by users with the "admin" role.

1234567891011

<security-constraint>         <web-resource-collection>                 <web-resource-name>secure</web-resource-name>                 <url-pattern>/secure/*</url-pattern>                 <http-method>GET</http-method>                 <http-method>POST</http-method>         </web-resource-collection>         <auth-constraint>                 <role-name>admin</role-name>         </auth-constraint> </security-constraint>

From a common sense point of view, the paper . Summarizes the problem and shows you how to bypass the authentication and authorization protections configured in Web. XML by using any of the HTTP verbs (like head) and completely fake verbs (like test or junk) that are not listed in the above configuration.

Fortunately, the solution is very simple. You just need to remove the

(3) SSL is not configured

In all applications that use sensitive data, SSL should be configured to secure data transfer. Of course you can configure SSL on the Web server, but once your application server has the appropriate SSL key set , it is very easy to enable SSL in the application.

123456

<security-constraint> ...         <user-data-constraint>                 <transport-guarantee>CONFIDENTIAL</transport-guarantee>         </user-data-constraint> </security-constraint>

(4) Non-use of safety signs

Many Web sites use SSL for authentication, but later either block non-SSL subsequent interactions or allow a portion of the site's content to be accessed through non-SSL. This makes the session's cookie (that is, jsessionid) susceptible to sessions hijacking attacks. To block it, a cookie can be created by adding a security flag, which ensures that the browser will not pass the cookie in a non-SSL environment.

In older versions of the servlet specification, there is no standard way to define jsessionid as safe. Now the,<cookie-config> element in Servlet3.0 can be used to ensure this.

12345

<session-config>         <cookie-config>                 <secure>true</secure>         </cookie-config> </session-config>

(5) HttpOnly mark not used

Cookies can be created using the HTTPONLY flag, which ensures that cookies cannot be accessed by client script. This helps alleviate some of the common XSS attacks. Just like the security flag, the previous version of the servlet specification did not provide the appropriate support. In Servlet3.0, you can configure it as follows:

12345

<session-config>         <cookie-config>                 <http-only>true</http-only>         </cookie-config> </session-config>

In addition to this new standard way of Servlet3.0, older versions of Tomcat allow the use of vendor-specific usehttponly attributes in Server.xml to enable it. This property is disabled by default in Tomcat5.5 and 6. In Tomcat7, this property is enabled by default. So even if you set it to False in Web. XML and then deploy it in TOMCAT7, your jsessionid will still be httponly unless you modify the Server.xml file.

(6) Use URL parameter to track session

The <tracking-mode> in the SERVLET3.0 specification allows you to define whether Jsessionid is stored in a cookie or in a URL parameter. If the session ID is stored in a URL, it may be inadvertently stored in multiple places, including browser history, proxy server logs, reference logs, and Web logs. Exposing the session ID makes the site more likely to be hijacked by a session. However, it is very easy to ensure that Jsessionid is stored in cookies:

123	<session-config>         <tracking-mode>COOKIE</tracking-mode> </session-config>

(7) Session time-out is not set

Users prefer long sessions because they are convenient. Hackers like long sessions because they have enough time to implement attacks like session hijacking. Security and availability are always conflicting. Once you know how to make your session live, you can configure the active time as follows:

123	<session-config>         <session-timeout>15</session-timeout> </session-config>

Summarize

Building and deploying secure applications requires the acquisition of requirements from different beneficiaries. The environment is as important as the configuration and coding itself. By thinking about these common security error configurations, I hope you can create more secure apps.

7 Wrong security configurations in the Web. xml file