Developing a safe, secure and stable Web Applications can be a painful task if you are not aware of all the capabilities your development environment provides. At the same point of time it will also make it very easy and manageable if you are aware of them.
In this article we are going to look into some common but essential configurations for Java Web Applications deployment descriptor file WEB.XML.
Authentication & Authorization Bypass
Web Applications can have many kind of informations and data hosted to it which can include public, shared and private data for different group of users. It the job of developer to take care that, confidential or private data can only be accessed by owner of the data or by specific group of users.
<security-constraint> element can make things easier as it can control web based access of secured directories or information. Following code shows a basic example of security constraints:
Above example indicates that anything under url pattern or directory /admin/* can be accessed by user with role admin using HTTP methods GET and POST.
Above example indicates that no user without having /admin/* role can access anything under url pattern or directory /admin/* using HTTP methods GET and POST. Now question here is what about other HTTP methods like PUT, DELETE, TRACK, TRACE etc. The Configuration will allow any HTTP method which are not listed. Attackers can access your secured data using these methods. Attackers can also try sending some arbitrary string like "HEEF" as HTTP method verb. This is called verb-based authentication and access control (VBAAC) bypass vulnerabilities.
A solution to this vulnerabilities is to remove all <http-method> restrictions from access control and authorization rules, this will apply rules to all requests with any HTTP method.
Improvement to above sample can be as follows:
Configuring SSL
SSL must be used to access sensitive or confidential data in all applications. You can define SSL configurations in <security-constraint> element as below:
Using URL Parameters for Session Tracking
The <tracking-mode> element in the Servlet 3.0 specification define that the JSESSIONID(current session id) should be stored in a cookie or in a URL parameter so that client can use it with next request to the server.
If session id is passed as URL parameter it can be saved at various locations including the history of browser, logs at proxy server, referrer logs, web logs, etc. An accidental disclosure of the session id makes the application more vulnerable to session hijacking attacks. Instead, you should make sure the session id is stored in a cookie using the following configuration:
Using the Secure Flag
All of us normally use SSL for authentication of the user like login action but revert back to non-SSL for rest of the operations in our application as they can be accessed via non-SSL. This makes session id vulnerable to attacks like session hijacking. As a solution to this problem we can configure session such a way that client(browser) should not transmit cookie with session id over non-SSL.
You can configure this as follows:
Using the HttpOnly Flag
Along with secure flag for cookie storing session id we should also HttpOnly flag with it. HttpOnly flag ensures that cookie with session id can be accessed by HTTP actions only.
Thus session cookie is secured from client side access using java scripts and this will minimize risk of attacks like XSS.
You can configure this as follows:
Setting a Session Timeout
All of us like long lived sessions because its very convenient, No one from us will really like to enter user name and password to login again and again after some period of inactivity for any web application. But there are other group of users who also like long lived sessions so that they get more time for carrying out attacks like Session Hijacking and Cross Site Request Forgery. Now this is really a crucial choice security vs. comfort of use.
You have to identify a period of time when sessions gets expired because of inactivity of the user. Session timeout period may vary based on the operations the application carry out but as a best practice it has to be configured in Web.XML.
In addition to session time out configuration we should also consider hard time out for highly secured web sites like banking web sites etc. Hard time out will expire session after some period of time even user is actively using application. This leads user to login again after some period of time and assigns a new session. Java don't provide this behavior through configuration in WEB.XML but this can be achieved by ServletFilter.
Configuring Custom Error Pages
Last but the most important configuration for any web application is defining your own custom error pages for handling errors. By default all java web application displays detailed error page with brief information of server, details about your server resources where error has occurred, snippet of the error stack trace and in some cases brief snippet of your server side code also. The purpose of this error page is to give a brief idea to the developer to track the error but for live and hosted applications scenario is totally different. For any attacker such information is like a treat which can be used to prepare attacks on your application.
You can configure your own custom error pages for specific errors as follows:
Below is the list of some 404 error pages from popular sites:Google, Yahoo, GitHub
You can find a detailed list of all HTTP error here
Reference: Seven Security (Mis)Configurations in Java web.xml Files
In this article we are going to look into some common but essential configurations for Java Web Applications deployment descriptor file WEB.XML.
Authentication & Authorization Bypass
Web Applications can have many kind of informations and data hosted to it which can include public, shared and private data for different group of users. It the job of developer to take care that, confidential or private data can only be accessed by owner of the data or by specific group of users.
<security-constraint> element can make things easier as it can control web based access of secured directories or information. Following code shows a basic example of security constraints:
<security-constraint> <web-resource-collection> <web-resource-name>secure</web-resource-name> <url-pattern>/admin/*</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>
Above example indicates that anything under url pattern or directory /admin/* can be accessed by user with role admin using HTTP methods GET and POST.
Above example indicates that no user without having /admin/* role can access anything under url pattern or directory /admin/* using HTTP methods GET and POST. Now question here is what about other HTTP methods like PUT, DELETE, TRACK, TRACE etc. The Configuration will allow any HTTP method which are not listed. Attackers can access your secured data using these methods. Attackers can also try sending some arbitrary string like "HEEF" as HTTP method verb. This is called verb-based authentication and access control (VBAAC) bypass vulnerabilities.
A solution to this vulnerabilities is to remove all <http-method> restrictions from access control and authorization rules, this will apply rules to all requests with any HTTP method.
Improvement to above sample can be as follows:
<security-constraint> <web-resource-collection> <web-resource-name>secure</web-resource-name> <url-pattern>/admin/*</url-pattern> <!-- No HTTP Methods should be listed here --> </web-resource-collection> <auth-constraint> <role-name>admin</role-name> </auth-constraint> </security-constraint>
Configuring SSL
SSL must be used to access sensitive or confidential data in all applications. You can define SSL configurations in <security-constraint> element as below:
<security-constraint> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint>Prior to enabling SSL at web application level you should configure your server for that. you can follow this document to configure SSL at tomcat.
Using URL Parameters for Session Tracking
The <tracking-mode> element in the Servlet 3.0 specification define that the JSESSIONID(current session id) should be stored in a cookie or in a URL parameter so that client can use it with next request to the server.
If session id is passed as URL parameter it can be saved at various locations including the history of browser, logs at proxy server, referrer logs, web logs, etc. An accidental disclosure of the session id makes the application more vulnerable to session hijacking attacks. Instead, you should make sure the session id is stored in a cookie using the following configuration:
<session-config> <tracking-mode>COOKIE</tracking-mode> </session-config>
Using the Secure Flag
All of us normally use SSL for authentication of the user like login action but revert back to non-SSL for rest of the operations in our application as they can be accessed via non-SSL. This makes session id vulnerable to attacks like session hijacking. As a solution to this problem we can configure session such a way that client(browser) should not transmit cookie with session id over non-SSL.
You can configure this as follows:
<session-config> <cookie-config> <secure>true</secure> </cookie-config> </session-config>This will ensure that browser will keep session id cookie secure and never expose it over non-SSL requests.
Using the HttpOnly Flag
Along with secure flag for cookie storing session id we should also HttpOnly flag with it. HttpOnly flag ensures that cookie with session id can be accessed by HTTP actions only.
Thus session cookie is secured from client side access using java scripts and this will minimize risk of attacks like XSS.
You can configure this as follows:
<session-config> <cookie-config> <http-only>true</http-only> </cookie-config> </session-config>Your server also takes care for this, in Tomcat 7 server.xml useHttpOnly attribute inside <Context> element is enabled by default. So, even if you configure web.xml to be <http-only>false</http-only> in Tomcat 7, your JSESSIONID will still be HttpOnly unless you change the default behaviour in server.xml as well.
Setting a Session Timeout
All of us like long lived sessions because its very convenient, No one from us will really like to enter user name and password to login again and again after some period of inactivity for any web application. But there are other group of users who also like long lived sessions so that they get more time for carrying out attacks like Session Hijacking and Cross Site Request Forgery. Now this is really a crucial choice security vs. comfort of use.
You have to identify a period of time when sessions gets expired because of inactivity of the user. Session timeout period may vary based on the operations the application carry out but as a best practice it has to be configured in Web.XML.
<session-config> <session-timeout>30</session-timeout> // Timeout in minutes </session-config>Above example shows session time out after 30 minutes of inactivity but you can configure this as per your requirement. If session time out is not configured in Web.XML then controller's default time out settings will be used(e.g. Tomcat has 30 minutes as default). Number less than or equal to 0 will set infinite time for session time out thus the session will never expire(So many websites use this option now a days).
In addition to session time out configuration we should also consider hard time out for highly secured web sites like banking web sites etc. Hard time out will expire session after some period of time even user is actively using application. This leads user to login again after some period of time and assigns a new session. Java don't provide this behavior through configuration in WEB.XML but this can be achieved by ServletFilter.
Configuring Custom Error Pages
Last but the most important configuration for any web application is defining your own custom error pages for handling errors. By default all java web application displays detailed error page with brief information of server, details about your server resources where error has occurred, snippet of the error stack trace and in some cases brief snippet of your server side code also. The purpose of this error page is to give a brief idea to the developer to track the error but for live and hosted applications scenario is totally different. For any attacker such information is like a treat which can be used to prepare attacks on your application.
You can configure your own custom error pages for specific errors as follows:
<error-page> <error-code>500</error-code> <location>/errors/505.jsp</location> </error-page>Above configuration will redirect to 505.jsp when ever server encounter 505 HTTP error.
<error-page> <exception-type>java.lang.Throwable</exception-type> <location>/errors/error.jsp</location> </error-page>Above configuration will redirect to error.jsp when ever server encounter java.lang.Throwable error.
Below is the list of some 404 error pages from popular sites:Google, Yahoo, GitHub
You can find a detailed list of all HTTP error here
Reference: Seven Security (Mis)Configurations in Java web.xml Files
Comments
Post a Comment
Is this content helpful? Leave appreciation, feedback, suggestions, issues anything.