Hello,
No, I’m not using ROP either :-) but and also find it neat, and used something
similar with
WebObjects, many moons ago.
I have been using Cayenne for an internal project, a web service, with quite
high traffic,
Cayenne usage on that, is, for now, on some less frequent called endpoints,
trying to
slowly extend its use, curious to see how it will handle > 10000 requests /s.
What I wanted to add here, is that our internal installation of SonarQube has
flagged the
(de)serialisation as a security vulnerability :-(
The findings are bellow, in case you want to have a look.
So, besides adding another data point to the discussion on deprecating ROP, I
also need to
fix this on my project.
First idea is to just use a custom template and remove everything below the
"Create serialization support” block. Am I correct in assuming that those
methods
are only used for ROP?
Many thanks!
Cheers,
HG
———— SonarQube findings ———
Security - Object deserialization is used in {1}
Vulnerability
Critical
cwe
Available Since
Mar 27, 2020
Find Security Bugs (Java)
Object deserialization of untrusted data can lead to remote code execution, if
there is a class in classpath that allows the trigger of malicious operation.
Libraries developers tend to fix class that provided potential malicious
trigger. There are still classes that are known to trigger Denial of Service[1].
Deserialization is a sensible operation that has a great history of
vulnerabilities. The web application might become vulnerable as soon as a new
vulnerability is found in the Java Virtual Machine[2] [3].
Code at risk:
public UserData deserializeObject(InputStream receivedFile) throws IOException,
ClassNotFoundException {
try (ObjectInputStream in = new ObjectInputStream(receivedFile)) {
return (UserData) in.readObject();
}
}
Solutions:
Avoid deserializing object provided by remote users.
References
CWE-502: Deserialization of Untrusted Data
Deserialization of untrusted data
Serialization and Deserialization
A tool for generating payloads that exploit unsafe Java object deserialization
[1] Example of Denial of Service using the class java.util.HashSet
[2] OpenJDK: Deserialization issue in ObjectInputStream.readSerialData()
(CVE-2015-2590)
[3] Rapid7: Sun Java Calendar Deserialization Privilege Escalation
(CVE-2008-5353)
———— SonarQube findings ———
On 2022/02/11 22:03:03 Aristedes Maniatis wrote:
> On the heels of the security announcement, there has been discussion on
> removing ROP from the next major Cayenne release after 4.2.
>
> ROP was modelled on a similar Java Client feature in Webobjects/EOF and
> there is nothing else quite like it in other ORMs. The ability to just
> use normal Cayenne operations from the client machine without worrying
> about how those operations get to the server and data objects are returned.
>
> It has some limitations:
>
> * limited security. There is no simple way to add an authorisation layer
> to restrict access to certain objects or fields. Authentication and
> encryption are really simple, but per object authorisation is hard.
>
> * Java client. Although it is possible to write Cayenne in other
> languages, no one has done so. There was some work ages ago on
> Cocoa/Objective C bindings. Java client UI (swing/javaFX) is not popular
> these days.
>
> * upgrading. You need to upgrade the client and server at the same time
>
>
> But it is really quite neat. Maybe I'm a bit sentimental since I used to
> use it extensively for many years. But I've moved onto react/js/browser
> clients which means that server-client serialisation is now over
> json/swagger/jackson/CXF. Authorisation is now easy and the client UI
> more lovely.
>
>
> Is anyone using ROP? Should we remove it from the next Cayenne and
> reduce the burden of maintenance?
>
>
> Ari
>
>
> On 12/2/2022 8:50am, Aristedes Maniatis wrote:
> > A patched version of Cayenne 4.1 (or earlier) will not be released
> > since we believe there are sufficient ways to avoid the issue and the
> > number of people using ROP is likely quite low. Given the security
> > model of ROP, it is also most likely used in a scenario where the
> > client is trusted.
>
