Directory traversal vulnerability through AbstractApplicationServlet.serveStaticResourcesInVAADIN()

[vaadin-bot]

Originally by @hesara

---

Using relative paths in directory URLs, it is possible to access some files loadable through the class loader.

The directory traversal is limited to files (not JAR contents etc.) loadable through the class loader but normally not accessible from the servlet. This can, however, include the class files of the application itself.

Some application servers may be immune to this vulnerability, but Jetty is known to be vulnerable at least in certain configurations.

Portlet 2.0 (JSR-286) portlets without a separate Vaadin servlet are not affected as static resources are not loaded through Vaadin. Portlet 1.0 (JSR-168) applications are vulnerable through the Vaadin servlet used in them.

This vulnerability was discovered by Wouter Coekaerts (http://wouter.coekaerts.be).

---

Imported from https://dev.vaadin.com/ issue #7670

[vaadin-bot]

Originally by @hesara

---

Fixed in [21326], reviewed by Leif and Wouter Coekaerts.

[vaadin-bot]

Originally by andrewfink

---

Vaadin 6.6.7/6.7.0 (with this workaround) stopped working with Tomcat and antiJARLocking="true" in
webapp\META-INF\context.xml

Tomcat with [Context antiJARLocking="true"] do copy of all resources in temp dir (~C:\j\t7\work\Catalina\localhost\mywebappname\loader\VAADIN). So resourceUrl.getProtocol() is "file", not jar.

Please make better patch.

[vaadin-bot]

Originally by andrewfink

---

workaround that works for me:

in my AbstractApplicationServlet descendant

@Override protected boolean isAllowedVAADINResourceUrl (HttpServletRequest request, URL resourceUrl) {

if ("file".equals(resourceUrl.getProtocol())) {
return !resourceUrl.getPath().contains("..");
} else {
return super.isAllowedVAADINResourceUrl(request, resourceUrl);
}
}

[vaadin-bot]

Originally by @Artur-

---

The additional problems were fixed in #7692