Hi Henrique,
Good catch. I wonder if the serialization code causes these vulnerability
warnings on its own though. Note that org.apache.cayenne.Persistent is declared
as Serializable, and this you can't change via a custom template (at least not
yet, see below). So maybe try removing those generated "readState" /
"writeState" methods by hand and see if it makes a difference. If it does, a
custom template approach would help you right away.
Whether it is safe to remove it? I'd say yes. Serialization support was
developed even prior to ROP (even though ROP used it in the early versions).
Instead, it was about servlet session backup and clustering. Specifically
Tomcat dumping / restoring HTTP sessions to disk. With REST APIs being the
prevalent flavor of code running on Tomcat/Jetty these days, I hope not too
many people need that now (I most certainly don't).
Going forward, I'd love to remove "implements Serializable" from Persistent,
and make it something the user can do optionally (just like you suggested). In
5.0 we should make serializability a cgen option, and remove it from the base
interface.
Let us know whether a custom template fixed it for you though.
Andrus
> On Oct 3, 2022, at 1:42 PM, Henrique Gomes <h...@farol.pt> wrote:
>
>
> 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.
