Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious web site, email, blog, instant message, or program causes a user’s web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.
1. Introduction
The remote Apache Tomcat web server is affected by an information disclosure vulnerability in the index page of the Manager and Host Manager applications. An unauthenticated, remote attacker can exploit this vulnerability to obtain a valid cross-site request forgery (XSRF) token during the redirect issued when requesting /manager/ or /host-manager/. This token can be utilized by an attacker to construct an XSRF attack.
2. XSRF Explained
A remote user can bypass security controls on the target system. A remote user can obtain potentially sensitive information on the target system. A remote user can hijack the target user’s session.
The index page of the Manager and Host Manager applications included a valid CSRF token when issuing a redirect as a result of an unauthenticated request to the root of the web application. If an attacker had access to the Manager or Host Manager applications (typically these applications are only accessible to internal users, not exposed to the Internet), this token could then be used by the attacker to construct a CSRF attack.
2.1 Vulnerable Systems
- Apache Tomcat 7.x before 7.0.67.
- Apache Tomcat 8.x before 8.0.31.
- Apache Tomcat 9.x before 9.0.0.M2
2.2 Immune Systems
- Apache Tomcat 7.x after 7.0.67
- Apache Tomcat 8.x after 8.0.31
- Apache Tomcat 9.x after 9.0.0.M2
3. An Example
1. System administrator connects to a Tomcat manager application.
2. The administrator leaves Tomcat Manager in an opened tab, and in the same browser that has the Tomcat Manager session opened, browse the web.
3. When browsing the web, one of the sites have malicious code that tricks the browser into making a request into Tomcat Manager.
4. The administrator session for Tomcat Manager has not yet expired,
5. Tomcat grants the malicious code access to the request.
For this to work, the attacker must know the full URL for the Tomcat Manager application.
4. Impact of CSRF
Impact of successful CSRF exploits vary greatly based on the privileges of each victim. When targeting a normal user, a successful CSRF attack can compromise end-user data and their associated functions.
If the targeted end user is an administrator account, a CSRF attack can compromise the entire web application. In Tomcat particular case, a successful CSRF attack compromises the entire Tomcat instance because the manager could manage all applications running in these Tomcat instances.
5. General Recommendations For Automated CSRF Defense
5.1 Verifying Same Origin with Standard Headers
There are two steps to this check:
Determining the origin the request is coming from (source origin).
Determining the origin the request is going to (target origin).
Both of these steps rely on examining an HTTP request header value. Although it is usually trivial to spoof any header from a browser using JavaScript, it is generally impossible to do so in the victim’s browser during a CSRF attack.
More importantly for this recommended Same Origin check, a number of HTTP request headers cant be set by JavaScript because they are on the ‘forbidden’ headers list. Only the browsers themselves can set values for these headers, making them more trustworthy because not even an XSS vulnerability can be used to modify them.
The Source Origin check recommended here relies on three of these protected headers: Origin, Referer, and Host, making it a pretty strong CSRF defense all on its own.
Identifying Source Origin
5.1.1 Checking the Origin Header
If the Origin header is present, verify its value matches the target origin. The Origin HTTP Header standard was introduced as a method of defending against CSRF and other Cross-Domain attacks. Unlike the Referer, the Origin header will be present in HTTP requests that originate from an HTTPS URL. If the Origin header is present, then it should be checked to make sure it matches the target origin.
There are some situations where the Origin header is not present, one of which is when following a 302 redirect cross-origin. In this situation, the Origin is not included in the redirected request because that may be considered sensitive information you don’t want to send to the other origin. But since we recommend rejecting requests that don’t have both Origin and Referer headers, this is OK, because the reason the Origin header isn’t there is because it is a cross-origin redirect.
5.1.2 Checking the Referer Header
If the Origin header is not present, verify the hostname in the Referer header matches the target origin. Checking the Referer is a commonly used method of preventing CSRF on embedded network devices because it does not require any per-user state. This makes Referer a useful method of CSRF prevention when memory is scarce or server-side state doesn’t exist. This method of CSRF mitigation is also commonly used with unauthenticated requests, such as requests made prior to establishing a session state which is required to keep track of a synchronization token.
In both cases, just make sure the target origin check is strong. For example, if your site is “site.com” make sure “site.com.attacker.com” doesn’t pass your origin check (i.e., match through the trailing / after the origin to make sure you are matching against the entire origin).
What to do when Both Origin and Referer Headers Aren’t Present?
If neither of these headers are present, which should be VERY rare, you can either accept or block the request. We recommend blocking, particularly if you aren’t using a random CSRF token as your second check. You might want to log when this happens for a while and if you basically never see it, start blocking such requests.
5.2 Identifying the Target Origin
You might think it’s easy to determine the target origin, but it’s frequently not. The first thought is to simply grab the target origin (i.e., its hostname and port #) from the URL in the request. However, the application server is frequently sitting behind one or more proxies and the original URL is different from the URL the app server actually receives. If your application server is directly accessed by its users, then using the origin in the URL is fine and you’re all set.
Determining the Target Origin When Behind a Proxy
If you are behind a proxy, there are a number of options to consider:
- Configure your application to simply know its target origin
- Use the Host header value
- Use the X-Forwarded-Host header value
Its your application, so clearly you can figure out its target origin and set that value in some server configuration entry. This would be the most secure approach as its defined server side so is a trusted value. However, this can be problematic to maintain if your application is deployed in many different places, e.g., dev, test, QA, production, and possibly multiple production instances. Setting the correct value for each of these situations can be difficult, but if you can do it, that’s great.
If you prefer the application figure it out on its own, so it doesn’t have to be configured differently for each deployed instance, we recommend using the Host family of headers. The Host header’s purpose is to contain the target origin of the request. But, if your app server is sitting behind a proxy, the Host header value is most likely changed by the proxy to the target origin of the URL behind the proxy, which is different than the original URL. This modified Host header origin won’t match the source origin in the original Origin or Referer headers.
However, there is another header called X-Forwarded-Host, whose purpose is to contain the original Host header value the proxy received. Most proxies will pass along the original Host header value in the X-Forwarded-Host header. So that header value is likely to be the target origin value you need to compare to the source origin in the Origin or Referer header.
Verifying the Two Origins Match
Once you’ve identified the source origin (from either the Origin or Referer header), and you’ve determined the target origin, however you choose to do so, then you can simply compare the two values and if they don’t match you know you have a cross-origin request.
6. Solution
The best solution is to migrate to a secured Tomcat Version. Where the Tomcat Manager, can protect themselve against these types of attacks by using tokens. Starting with the authentication request, the browser is sent a special token that must be provided with the next request. Each subsequent response provides a new token for the following request. In this case, when the attacker sends the request, while it will reach the server, it will not include the correct token, so the server will reject the request and prevent the attack.
Also you as an administrator when you are done working on an authenticated session, simply close out the browser or log out of the application so no authenticated session exists to be exploited.
