resteasy XXE vulnerability
by Wang Veronica
Hi experts,
We use resteasy 3.0.6final, and XXE vulnerability was reported during penetration test.
Seems that 3.0.6final contains partial fix for XXE vulnerability, but need to set resteasy.document.expand.entity.references parameter to false explicitly. A more complete fix seems to have been done after 3.0.10.
We can upgrade to a more recent version, e.g. 3.1.2. Another option I am thinking is not to support XML Media type (we actually need to support json only). Is this a feasible approach to ultimately avoid XXE attack and any pointers to achieve this? (In our REST API code, we currently declare consume and produce annotations to support application/xml and application/json).
Is there a simple resteasy configuration to disable support of application/xml?
Thanks, Veronica
1 week, 4 days
Resteasy client defines servlet
by Leonid Rozenblyum
Hello.
Recently due to update of resteasy-client from 3.0.1.Final to 3.6.3.Final
we faced failures to process our spring mvc controller at '/' path.
After some debugging I found out the reason:
1) resteasy-client transitively depends on resteasy-jaxrs
2) resteasy-jaxrs (at least since 3.0.20.final)
(see commit
https://github.com/resteasy/Resteasy/commit/840cb666c8e89767e9c9821eb173b...
)
registers org.jboss.resteasy.plugins.server.servlet.HttpServlet30Dispatcher
as a servlet with value = '')
Is it an expected behaviour that *client *dependency register a servlet?
Are there any ways to disable it?
Thanks for advice!
1 week, 4 days
Selecting MessageBodyWriter seems to ignore priority given a specific type match
by Steven Schlansker
Hi Resteasy users, [ apologies for the re-post, sent from wrong email the first time ]
I'm a happy user of Resteasy + Jackson for Json processing.
Recently, I had the misfortune of attempting to serialize a basic String:
client.post(Entity.json("Test"));
if you call Jackson directly, it does the right thing:
mapper.writeValueAsString("Test") => "\"Test\""
However, much to my surprise, when sending it via JAX-RS client, it is written as a bare word without quotes -- and is rejected server-side.
After some debugging, I realized that both StringTextStar and JacksonJsonProvider were ending up with Priorities.USER and being seen as equivalent.
No good! So I changed my registration:
context.register(new JacksonJsonProvider(myMapper), Integer.MAX_VALUE);
I then proceeded to triumphantly ... observe the same test failure as before!
Dug quite a bit further in, and it seems that the selection process in MediaTypeMap$TypedEntryComparator
has the unfortunate property that it will select (via compareTypes) a *less priority* MessageBodyWriter if the type is a tighter bound on the Entity.
So in my case, I get
StringTextStar -> String.class@5000
JacksonJsonProvider -> Object.class(a)Integer.MAX_VALUE
and the TypedEntryComparator selects StringTextStar since String is-assignable to Object, despite my attempt at an ultimate priority registration.
How do I fix this? Preferably without removing StringTextStar entirely, as I'm sure that will break something else (reading error messages perhaps).
Thanks for any advice,
Steven
1 week, 4 days
Microprofile config
by Alvaro Arenas
Hi,
I am adding my project to a stream down wildfly v23 (withou microservices modules) and I use smallrye-config in my project. When adding my deployment with the microprofile configuration package incleded (for example "org.apache.geronimo.config:geronimo-config-impl:1.2.2") the souces in the file org.eclipse.microprofile.config.spi.ConfigSource get automatically added by wildfly but the implementation class is not found.
I get the following error
Caused by: java.lang.NoClassDefFoundError: Failed to link org/jboss/resteasy/microprofile/config/ServletConfigSource (Module "org.jboss.resteasy.resteasy-jaxrs" version 3.15.1.Final from local module loader @fc1522fa (finder: local module finder @4332406a (roots: /Users/alvarena/hki/keycloak/standalone/keycloak-13.0.0/modules,/Users/alvarena/hki/keycloak/standalone/keycloak-13.0.0/modules/system/layers/keycloak,/Users/alvarena/hki/keycloak/standalone/keycloak-13.0.0/modules/system/layers/base))): org.eclipse.microprofile.config.spi.ConfigSource
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClassInternal(ClassLoader.java:398)
at java.lang.ClassLoader.defineClass(ClassLoader.java:359)
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:423)
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:555)
at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:339)
at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:126)
at org.jboss.modules.Module.loadModuleClass(Module.java:753)
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:247)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
at java.lang.Class.forNameImpl(Native Method)
at java.lang.Class.forName(Class.java:408)
at java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404)
at java.util.ServiceLoader$1.next(ServiceLoader.java:480)
at java.lang.Iterable.forEach(Iterable.java:74)
at org.apache.geronimo.config.DefaultConfigBuilder.build(DefaultConfigBuilder.java:130)
at org.apache.geronimo.config.DefaultConfigProvider.getConfig(DefaultConfigProvider.java:62)
at org.apache.geronimo.config.DefaultConfigProvider.getConfig(DefaultConfigProvider.java:46)
at org.eclipse.microprofile.config.ConfigProvider.getConfig(ConfigProvider.java:93)
at org.apache.geronimo.config.cdi.ConfigExtension.validate(ConfigExtension.java:123)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:95)
... 26 more
I don't understand how the system is able to find the file org.eclipse.microprofile.config.spi.ConfigSource but not the implementation classes that are in the same package.
Any idea what could be wrong
Best regards,
Alvaro
1 week, 4 days
RestEasy 4.7.9 - java.lang.IllegalStateException: Connection pool shutdown
by Zsolt Melich
Hi all!
I'm facing with the error message in the subject since I had to switch from RestEasy v3.0.18 (I know, quite old) to v4.7.9.
We have a great, complex IVR application (written in Java 8), what is using RestEasy for the WS client we have for the API calls throughout a calls. The application is deployed to a Tomcat 9 application server.
The current version of the client creates a RestEasy client instance for each API invocation, then close the response and the client (with the close() method). This is quite expensive, so I planned to change this when I switch to v4.7.9.
In the new version I create the client at the beginning, closing the response (to let the resource back to the pool) after each invocation, and shut down the client with close() at the very end (only once).
We create the PoolingHttpClientConnectionManager instance, the engine instance (ApacheHttpClient43Engine) and the httpClient instance manually, then we pass the engine to the ClientBuilder to create the client instance.
The problem is that I can make only one IVR test call without any issue. At the very end of the first call, the connection is being closed. In the second call I got the exception from the subject for the very first API call.
I checked the logs, traced my test calls and everything is looking fine (the app does not close the connection before the invocation). After a Tomcat restart I'm able to do a successful test call again, but only for one time! After a successful call, I'm getting the same exception in the next call...
Does the close() method of the client instance destroy the whole connection pool for later calls as well when I close the connection at the end of the first call? Is this normal?
We didn't have this issue with v.3.0.18.
P.S. : I know I haven't provided any exact code yet, but I try to clarify and understand the mechanics first.
Thanks for the helping replies in advance!
1 month, 1 week
