Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Welcome To Ask or Share your Answers For Others

Categories

0 votes
1.2k views
in Technique[技术] by (71.8m points)

java - FindBugs : real threat behind EI_EXPOSE_REP

FindBugs raises a bug called EI_EXPOSE_REP with the following description :

EI: May expose internal representation by returning reference to mutable object

Returning a reference to a mutable object value stored in one of the object's fields exposes the internal representation of the object. If instances are accessed by untrusted code, and unchecked changes to the mutable object would compromise security or other important properties, you will need to do something different. Returning a new copy of the object is better approach in many situations.

Several questions on SO (1, 2 and 3) have already addressed how to avoid such bug and I understand that it is a development best practice to prevent modifications of immutable objects however it is not clear to me why such bug belongs to the MALICIOUS_CODE category.

What is the real threat behind this ?

If it's a malicious code problem, the attacker can do almost anything he wants and mutability wouldn't be the biggest problem. If it is a vulnerability, it can be exploited only if untrusted code is executed also and I can't see any usecase where this is true.

Any perspective on this ?

Thanks !

See Question&Answers more detail:os

与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome To Ask or Share your Answers For Others

1 Answer

0 votes
by (71.8m points)

The point is that any time you open up an implementation you run the risk of code doing damage, intentionally or otherwise. Obviously a malicious library user, for example, could just disassemble your jar and learn details that way–the point is to minimize the risk of exposure: it cannot be eliminated.

A trivial example of external code accessing your library:

Consider something simple like an object that holds an access level. If it was mutable, it's conceivable a library user could set their own access level. Something this trivial would rarely be exposed by any reasonable library, but it's a clear example of when an internal representation might be abused.

The bottom line is that exposed mutable state makes code difficult to reason about, and difficult to protect. Your code or others may accidentally, or deliberately, modify something your own code/library uses. If your library then changes its behavior without taking that into account, you may introduce a subtle (or not so subtle) bug.


与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…
Welcome to OStack Knowledge Sharing Community for programmer and developer-Open, Learning and Share
Click Here to Ask a Question

...