clone, copy, changeable object on getter for security

Asked

Viewed 76 times

4

In many articles and books it is cited that for security the correct is always deliver via getter a copy of mutable attributes.

It can be a clone or a new instance containing the same values as your attribute.

I’ve done a lot of research, and I still can’t figure out where the danger of handing over one’s own attribute is.

In my case, my application uses a mvc framework for web, exposing a Rest api, accessing database using a ORM, models and domain objects have mutable attributes.

Where there is security risk?

When we expose a library, api, dll, jar, ejb, I see that yes, there are security problems, for example, if I design a condition in which the client applies an investment on a certain date and then withdraws it on another, I do all the calculation based on the dates, the date being changeable, there may be a loophole, and the customer (another system, a partner, a third party) can purposely change the date before imputing, but can’t see in other scenarios.

Unfortunately even formidable applications like Sonar Qube have rules to bar codes that expose mutable objects.

oop security-guard

  • I found another possible reason, depending on the nature of your system and the complexity involved, it could happen that a code of yours can change a date for example that there should not be, since the date is fully exposed, you have no control and can generate some inconsistency, that in practice I could not imagine, but structurally it is possible.

  • I found some explanations on Sonarqube’s website: https://rules.sonarsource.com/java/RSPEC-2384 and on the website Common Weakness Enumeration: http://cwe.mitre.org/data/definitions/374 but it was not convincing to me, the explanation is limited to the application itself, that is, a code within the application itself can change the value before executing another method, can not see real danger.

2 answers

2

In OO there is the concern not to violate the encapsulation of classes, or rather, the concealment of information. We can say that it is a design principle.

This violation occurs for example when the class has a field in the form of a collection (for example, a list) of items and you expose that collection through a getter.

There is a danger of manipulating the collection obtained in this way and altering the internal state of the object improperly. The ideal would be to have passed a copy of the collection, which if it is made of immutable items so much the better (if they are not, let them be at least copies of the original items).

This way you preserve the original collection and can handle the copied version at will (or not, if you have passed a read-only collection).

It is a form of security, from the point of view of the clients of this class (thinking of the clients of a class library for example), who cannot naively or maliciously change the internal state of the objects of this library.

If you need an example.

  • would be of great value examples, because currently I can not see many risks, 99% of applications do not expose another api via dll, ejb, jar, or whatever to a third party, but only web services or end-points rests. Even more with the adoption of Microservices, there is no longer this interaction on the same host. But even for other scenarios it would be very valuable to me.

  • The danger is in interactions on the same host, such as in the case of a desktop application or backend using a library or other form of server code. But I don’t know if I can think of a practical example of that. When I proposed to illustrate with an example, I was thinking about the mechanics of the thing, return a Collections.unmodifiableList() from Java instead of the list itself, use immutable objects in the returned list, that kind of thing. It wouldn’t be a very applicable example.

  • 1

    Yes @Anilo you are correct, and my answer and that of Piovezan confirm this, the problem is not of security, it is only of code organization and it has everything to do with getters. Note that it speaks of breach of principle and does not breach security. What I do not like much, though eeu* understand the phrase, is to talk about danger, because people may think it is dangerous to suffer an attack or something and in fact it is only dangerous for the programmer to make a mistake. Attacks can occur for other reasons, not for this one. It’s only about the risk of making a mistake and not being attacked.

1

This has nothing to do with security, one way or another, security is something else. What you might be talking about is that you avoid any problems doing so, so it would be safe because of this, but it’s not about the concept of security that we usually talk about. So if you’ve seen somewhere about malicious code exploring something because of the way you organize the code throw this thing away now. So to answer what you want to know, it makes no sense, found nothing because it doesn’t exist.

There is a lot of confusion of what is said about object orientation because there are different schools on the subject and each one preaches something different, which can already be seen that it should not have as much value as people give for it.

An example of misconception is that attribute is even used in conceptual object orientation, but it makes no sense to call it an attribute in languages, because almost all of them call it field.

The use of getter is questionable, has numerous questions on the subject here, can start by Getters and Setters Methods.

What is said is that you hiding the field behind a method getter gives you more flexibility and hides the detail of implementation, so if one day you need to change something there is easier because it has a indirect, only that. And it is not limited to changing fields.

The question of cloning also seems strange, you have to see the context, in general you should not clone complex objects. Asked like that what you’re talking about doesn’t make sense, it can do in some specific scenario.

As you spoke of frameworks it may be that some require this for an internal motivation, but would have to see the context.

So the question starts from many wrong premises, the path of your learning is all wrong and it mixes things that have no relation whatsoever. My suggestion is to find another source of consultation or change the learning method.

Doing something wrong may have to do with safety, but not because something is changeable or immutable or because it has getter, or because it clones something. Maybe it’s because some component of these lets something external mess with something internal in the code, well then the technology used is insecure and should be discarded, it’s not an object or language orientation problem.

  • 2

    Thank you for the return, but it is not about getters themselves that I ask but about delivering mutable objects. I studied some more and I came to the conclusion that in a library, api, or even an ejb I take risks in exposing a mutable object, security risk, see that a consumer, maliciously can change a crucial date in an investment for example, when I designed that date to be read-only. I will improve my question.

Browser other questions tagged oop security-guard

You are not signed in. Login or sign up in order to post.