Impact
Play Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its DefaultHttpErrorHandler to do so based on the application mode. In its Scala API Play also provides a static object DefaultHttpErrorHandler that is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure the DefaultHttpErrorHandler object instance as the injected error handler. Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application.
In particular the constructor for CORSFilter and apply method for CORSActionBuilder use the static object DefaultHttpErrorHandler as a default value.
Patches
This is patched in Play Framework 2.8.16. The DefaultHttpErrorHandler object has been changed to use the prod-mode behavior, and DevHttpErrorHandler has been introduced for the dev-mode behavior.
Workarounds
When constructing a CORSFilter or CORSActionBuilder, ensure that a properly-configured error handler is passed. Generally this should be done by using the HttpErrorHandler instance provided through dependency injection or through Play's BuiltInComponents. Ensure that your application is not using the DefaultHttpErrorHandler static object in any code that may be run in production.
References
https://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler
https://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler
For more information
If you have any questions or comments about this advisory:
References
BillyAutrey Analyst
gmethvin Analyst
dontgitit Analyst
Impact
Play Framework, when run in dev mode, shows verbose errors for easy debugging, including an exception stack trace. Play does this by configuring its
DefaultHttpErrorHandlerto do so based on the application mode. In its Scala API Play also provides a static objectDefaultHttpErrorHandlerthat is configured to always show verbose errors. This is used as a default value in some Play APIs, so it is possible to inadvertently use this version in production. It is also possible to improperly configure theDefaultHttpErrorHandlerobject instance as the injected error handler. Both of these situations could result in verbose errors displaying to users in a production application, which could expose sensitive information from the application.In particular the constructor for
CORSFilterandapplymethod forCORSActionBuilderuse the static objectDefaultHttpErrorHandleras a default value.Patches
This is patched in Play Framework 2.8.16. The
DefaultHttpErrorHandlerobject has been changed to use the prod-mode behavior, andDevHttpErrorHandlerhas been introduced for the dev-mode behavior.Workarounds
When constructing a
CORSFilterorCORSActionBuilder, ensure that a properly-configured error handler is passed. Generally this should be done by using theHttpErrorHandlerinstance provided through dependency injection or through Play'sBuiltInComponents. Ensure that your application is not using theDefaultHttpErrorHandlerstatic object in any code that may be run in production.References
https://www.playframework.com/documentation/2.8.x/ScalaErrorHandling#Supplying-a-custom-error-handler
https://www.playframework.com/documentation/2.8.x/JavaErrorHandling#Supplying-a-custom-error-handler
For more information
If you have any questions or comments about this advisory:
References