I've stumbled over java code, that does an LDAP query, and
sets flag .setReturningObjFlag(true) on the searchControl object.
According to some ressources, like e.g.
https://app.deepsource.com/directory/analyzers/java/issues/JAVA-S1026
this should be avoided, unless the LDAP server and its
data is really trusted.
I'd be curious, what would be the alternatives, under the assumption,
that there are indeed serialized Objects stored in LDAP in whose value
I'm really interested, and if I then didn't want to trust the server
to always return data for the expected objects.
According to description of setReturningObjFlag(): if this flag
is false "... only the name and class of the object is returned",
which to me sounds like I won't get the serialized data.
Do I misunderstand it, or is there no third option besides:
- trust the LDAP-server and have received data immediately deserialized
- not trust the LDAP-server and just not get the data at all.
Is there, maybe, a way to restrict the classes to a whitelist
of classes that it may deserialize, and get an exception on
any attempt to pull in any other class, before that other class
is even initialized?
Is there, maybe, a way to just retrieve the serialized stream and
scrape the relevant info without full deserialization?
On 10/13/2023 10:57 AM, Andreas Leitgeb wrote:
https://app.deepsource.com/directory/analyzers/java/issues/JAVA-S1026
Do I misunderstand it, or is there no third option besides:
- trust the LDAP-server and have received data immediately deserialized >> - not trust the LDAP-server and just not get the data at all.
Is there, maybe, a way to restrict the classes to a whitelist
of classes that it may deserialize,
Is there, maybe, a way to just retrieve the serialized stream and
scrape the relevant info without full deserialization?
Java deserialization of objects is known to be potential
security problem:
- use all memory
- execute code in readObject method
But I assume your LDAP service is somewhat trusted (as it
its usually provides authentication & authorization!).
So depending on security level you can:yes, sure.
* decide that you trust LDAP and continue to automatic deserialize
* continue to automatic deserialize but find a way to plugin
a deserialization filter (assuming you are on Java 9+ where that
was introduced)
* drop the automatic deserialize and redesign the data transfer
in some way:
- instead of Java object have either JSON or XML and
do a DOM tree parse not a binding to get the data over
in a Java object
- move the info from LDAP to somewhere else like database
Arne Vajhøj <arne@vajhoej.dk> wrote:
So depending on security level you can:yes, sure.
* decide that you trust LDAP and continue to automatic deserialize
* continue to automatic deserialize but find a way to plugin
a deserialization filter (assuming you are on Java 9+ where that
was introduced)
Ah, good to know - for future.
* drop the automatic deserialize and redesign the data transfer
in some way:
- instead of Java object have either JSON or XML and
do a DOM tree parse not a binding to get the data over
in a Java object
- move the info from LDAP to somewhere else like database
Not sure if I understand this correctly... is this a way to retrieve
the same data that is already stored in LDAP but in alternative formats,
or do you mean that the data in LDAP needs to be stored in those other formats(e.g. json) for that to work?
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 376 |
Nodes: | 16 (2 / 14) |
Uptime: | 82:06:14 |
Calls: | 8,046 |
Calls today: | 2 |
Files: | 13,040 |
Messages: | 5,834,270 |