Cross-site request forgery (CSRF), also sometimes referred to as one-click attacks or session riding, is another type of malicious exploit of websites that the Apache Tomcat community has addressed in the Apache Tomcat 7 release process. Different from cross-site scripting, where the attacker exploits the trust users have for a particular site, CSRF targets the trust that sites have in a user’s browser. The new CSRF Protection prevents attacks directly on Apache Tomcat Manager and Apache Tomcat Host Manager as well as provides a CSRF Prevention Filter for the applications that run on Tomcat to use.
A system administrator connects to a Tomcat instance and logs into the Tomcat Manager application. The admin performs routine tasks such as deploying a web application, checking the status of another application and upgrading a third application. Then the administrator leaves Tomcat Manager, and goes to browse the web. One of the sites the administrator browses has malicious code in either a link or a flash file that tricks the browser into making a request into Tomcat Manager. The admin’s session for Tomcat Manager has not yet expired, and Tomcat grants the malicious code access to the request. This essentially introduces a large back door for control into the system administrator’s Tomcat instances.
In addition to targeting administrators to take down websites, applications that run on Tomcat-such as banking applications-are also vulnerable to the same attacks. Check out the article on CSRF on the Open Web Application Security Project (OWASP) for more detail.
2010 has been an exciting year for the Tomcat Expert community site. Created by the Apache Tomcat Experts at SpringSource, Tomcat Expert was launched in March to improve the adoption, performance and value of Apache Tomcat for enterprise users. After almost ten months of operation, we’ve been able to provide you with content from Tomcat Expert Contributors weighing in on top Apache Tomcat news and topics, including several relating to June's release of Tomcat 7.0.0 Beta, the first Tomcat 7 release. As the year winds down, we've put together a list of the most popular blog posts of the year. Additionally, we're asking you to tell us what topics you'd like to see covered more in 2011 with a content request form below.
Announced this afternoon by the Apache Tomcat team.
CVE-2010-4172: Apache Tomcat Manager application XSS vulnerability
Severity: Tomcat 7.0.x - Low, Tomcat 6.0.x - Moderate
Vendor: The Apache Software Foundation
The session list screen (provided by sessionList.jsp) in affected
versions uses the orderBy and sort request parameters without applying
filtering and therefore is vulnerable to a cross-site scripting attack.
Users should be aware that Tomcat 6 does not use httpOnly for session
cookies by default so this vulnerability could expose session cookies
from the manager application to an attacker.
A review of the Manager application by the Apache Tomcat security team
identified additional XSS vulnerabilities if the web applications
deployed were not trusted.
How do you gracefully restart Tomcat? It will be good to have a standard way doing this. We created a health check url for the load balancer (e.g. /health). This url returns 200 status to indicate this service is up. There is a prob.txt under tomcat dir. If we delete this file, the health check will start returning 404. Thus, remove this box from load balancer. Wait for 2 to 3 mins before shutting it down the process to ensure all request have been processed.
Tomcat, unlike Apache HTTPD, does not have a graceful restart function, largely because of the consequences of it being an application server rather than a web server.
The restart time for server itself largely depends on how long it takes your application to start up, you should be able to start a fresh Tomcat instance in a few seconds - it's worth noting how long it takes to start up on your system, before you customise the configuration.
Instead of restarting the server, you can restart individual applications, which is nearer to the concept of a graceful restart and wouldn't incur the overhead of restarting all of the applications.
An appropriately secured* Manager application instance in each Host, will enable you to selectively restart an application. Automated requests can be sent to the
/manager/text component using the same request structure as the
/manager/html component, but with smaller output.
* The Manager application should be secured by adding the RemoteIpValve to it's Context definition, with only the specific IP addresses you'll administer the server from enabled.
In my first article on taking advantage of RabbitMQ's asynchronous messaging to implement a cloud-friendly session manager, I covered the method behind the madness and introduced you to some of the functions a session manager has to perform in the course of doing its job. In this, the second of two articles covering this topic, I'll describe how loading and updating session objects is handled and, in the interest of fairness, give some disclaimers and acknowledge the trade-offs made to get here.
Whenever code wants to interact with a user session, whether that be to load it into its own memory or to replicate attributes on that session, it sends these messages to a queue whose name contains the session ID. The pattern used to create the queue name is configurable so you can partition user sessions by application, or even by something more fine-grained (without resorting to using multiple, non-clustered RabbitMQ servers).
The session store first checks its internal Map to see if the requested session happens to be local to this store. If it is, the store simply hands that session back to the manager. If it's not, then the store sends a "load" message to the session's queue. It doesn't just fire off a message, though. It turns out that a user's session can be requested from the store many times during the course of a request. If one were to send a load message every time this happens, then we would see a serious performance degradation. To get around this, before a load message is sent, the store checks to see if it's already trying to load this session. If it is, it simply waits until that process is finished and uses the session being loaded in that other thread.
The existing solutions for Tomcat session clustering are viable for moderate clusters and straightforward failover in traditional deployments. Several are well developed with a mature code-base, such as Apache's own multicast clustering. But there's no getting around the fact that today's cloud architectures place new and different expectations on Tomcat that didn't exist several years ago when those solutions were being written. In cloud architectures, where horizontal scalability is king, a dozen or more Tomcat instances is not unusual.
In my hybrid, private cloud, first described in my earlier post on keeping track of the availability and states of services across the cloud, I wanted to fully leverage all my running Tomcat instances on every user request. I didn't want to use sticky sessions as I wanted each request (including AJAX requests on a page) to be routed to a different application server. This is how virtual machines work at a fundamental level. Increased throughput is obtained by parallelizing as much of the work as possible and utilizing more of the available resources. I wanted the same thing for my dynamic pages. Not finding a solution in the wild, I resolved to roll my own session manager. The result is the "vcloud" (or virtual cloud) session manager. I've Apache-licensed the source code and put it on GitHub--mostly to try and elicit free help to make it better. You can find the source code here: http://github.com/jbrisbin/vcloud/tree/master/session-manager/
Often times a developer or operations professional needs access to monitor a Tomcat instance for purposes of capacity planning, troubleshooting, and performance tuning. There are many tools available already for Tomcat, some of them open source, and others paid for. Some tools are simple and others are complex management suites.
There are comprehensive monitoring suites available that monitor and manage Tomcat, and do it well; however, there is always a benefit to being able to create your own custom Tomcat/application management tools. The first advantage is that you get exactly what you want out of your utility. In my example, I wanted to have a way to browse a Tomcat server’s Java Management Extensions’ MBeans with a hierarchical, bash-like navigation. This allows me to quickly find and diagnose problems with my Tomcat server or custom applications running within Tomcat, and is more precise than trending those MBeans over time using a more comprehensive monitoring suite. I liken it to purchasing a ready-made suit, or having one custom tailored to your exact specification. It just feels better sometimes, and other times it is not practical.
Many utilities will not provide the specific feature that you need. There are usually a host of open source or commercial utilities for anything that one goal any developer or operations professional may want to achieve; however, often times that utility will not integrate well into their existing infrastructure, or not play well with automated processes that are pre-existing in the enterprise. In such cases, a custom utility can come in handy. Writing your own tools from scratch is a quick solution to a specific problem, and cuts out a lot of the fat. For simple tools, the complexity risk argument just isn't there, and in the time it takes to write a simple custom application.
For development and operations teams, a presentation that covers how to manage applications properly from cycling updates to determining failures.
Your business applications provide all the components that do the real work for your enterprise and use Tomcat as the engine to power that work. How can you ensure that your applications on Tomcat are managed properly? How do you cycle application updates over a group of more than twenty server instances? How do you determine the failure of application whether it is during start-up, execution or application shutdown?
For development and operations teams, a presentation that covers how large scale Tomcat deployments can be managed.
In the past, deploying Apache Tomcat in medium and large enterprise environments presented significant challenges due to the rudimentary management tools in Apache Tomcat. But no longer. SpringSource provides an enterprise version of Apache Tomcat, complete with all the enterprise features necessary for managing large scale Apache Tomcat deployments.
For development and operations teams, a presentation to improve software development with Spring and Tomcat.
Spring is commonly found within enterprises and helps companies better manage complexities in the software development processTomcat has also become ubiquitous within the enterprise.