eclipse-ee4j / eclipse-ee4j/jersey
Jersey deserializes arbitrary class from jaxb
- Dominant language
- Java
- Stars
- 730
- Forks
- 382
- PR merge metrics
- No merged PRs in 30d
Description
Using jersey client 2.22.1, I have a method call reading xml data, like this:
```
final Client client = ClientBuilder.newClient();
final WebTarget target = client.target(targetURI);
final Respone response = target.request(MediaType.APPLICATION_XML);
final Object entity = response.readEntity(Weather.class);
return (Weather) entity;
```
The expected xml format is this
```
```
represented by this jaxb generated class
```
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"loc",
"map"
})
@XmlRootElement(name = "weather")
@Generated(value = "com.sun.tools.xjc.Driver", date = "2016-04-18T09:57:17+02:00", comments = "JAXB RI v2.2.11")
public class Weather {
// ... }
```
However when the remote returns this xml:
```
```
I get an instance of this class:
```
@XmlAccessorType(XmlAccessType.FIELD)
@XmlType(name = "", propOrder = {
"content"
})
@XmlRootElement(name = "error")
@Generated(value = "com.sun.tools.xjc.Driver", date = "2016-04-18T09:57:17+02:00", comments = "JAXB RI v2.2.11")
public class Error {
// ... }
```
So response.readEntity(Weather.class) returns an instance of a different class than weather despite the javadoc contract from javax.ws.rs.core.Response.readEntity:
```
@throws ProcessingException if the content of the message cannot be mapped to an entity of the requested type.
```
Apart from being highly confusing and a cause for unwanted ClassCastExceptions, this poses a certain security risk as the endpoint may trigger instantiation of an undesired class by returning unexpected XML.
Note that I am not sure whether this is a bug in Jersey or JAXB or something else...
Contributor guide
Research direction
Start by reproducing the Jersey 2.22.1 example through Response.readEntity(Weather.class) with the weather and error XML shown. Trace the JAXB message-body reader and response entity conversion, then verify that an unexpected root element is rejected with ProcessingException rather than producing an Error instance.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100