Alfresco / alfresco-sdk

The Alfresco In-Process SDK is based on Apache Maven, includes support for rapid and standard development, testing, packaging, versioning and release of your Alfresco integration and extension projects
Apache License 2.0
185 stars 113 forks source link

Tomcat 7.0.82 enforces uriEncoding, the SDK does not #499

Closed tom-vandepoele closed 5 years ago

tom-vandepoele commented 6 years ago

I'm submitting a ... (check one with "x")

[ ] bug report => search github for a similar issue or PR before submitting
[x] feature request

Expected Behavior

The (embedded) tomcat version run by the SDK is configurable, so SDK tomcat can match the tomcat version of a production server.

Current Behavior

When running the SDK tomcat version 7.0.47 is used. This cannot be changed currently.

Possible Solution

See http://tomcat.apache.org/maven-plugin-2.2/tomcat7-maven-plugin/adjust-embedded-tomcat-version.html By exposing the tomcat version to the alfresco maven plugin configuration.

Context

In Alfresco 5.2.3 a breaking change is introduced with tomcat 7.0.82 which most developers will not be aware of until they deploy their application on an actual server.

Namely, HTTP request validation is changed so certain special characters are no longer allowed and instead of returning a usable error, the server will on any of these 'invalid' uris just simply return 400 bad request with no further info.

Should developers not have had the discipline to properly encode their URIs with encodeURIComponent, their applications, while working just fine running on the SDK will break in a normal server environment.

By allowing the SDK to specify the tomcat runtime, these problems can be caught earlier in the development stage.

Your Environment

Additional information

This is the message the catalina.out will show when hitting an invalid uri in tomcat 7.0.82:

INFO: Error parsing HTTP request header Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level. java.lang.IllegalArgumentException: Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC 3986 at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:238) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1028) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.doRun(AprEndpoint.java:2555) at org.apache.tomcat.util.net.AprEndpoint$SocketProcessor.run(AprEndpoint.java:2544) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Unknown Source)

tom-vandepoele commented 6 years ago

Note a workaround (which exposes the tomcat server security-wise, but is a valid alternative to downgrading tomcat) is to re-enable this line in the catalina.properties on the production server:

# Allow for changes to HTTP request validation
# WARNING: Using this option will expose the server to CVE-2016-6816
#tomcat.util.http.parser.HttpParser.requestTargetAllow=|

The only real solution is to properly encode all request URIs (REST calls), of course.

ohej commented 5 years ago

Pull request #521 addresses this so the Tomcat version can be updated. Will be included in SDK 3.1.