 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / March 2006Exposing internal representation - security?
I have some table model classes that contain String[] objects that contain the column names. Now, since a String[] is mutable, even if the String[] is declared final, someone calling getColumnNames() could change the column names. Would it be overkill to, in getColumnNames(), return a copy of the array instead via: return (String[]) columnNames.clone(); or would that be considered a good practice so that the column names cannot be changed by ill-mannered code? Thanks in advance..  SignatureJoe Attardi >I have some table model classes that contain String[] objects that > contain the column names. Now, since a String[] is mutable, even if the [quoted text clipped - 7 lines] > or would that be considered a good practice so that the column names > cannot be changed by ill-mannered code? The latter; it's a good idea. Alternatively, you could define getColumnNames to return a List, and do something like return new ArrayList(Arrays.asList(columnNames)); or return Collections.unmodifiableList(Arrays.asList(columnNames)); >I have some table model classes that contain String[] objects that > contain the column names. Now, since a String[] is mutable, even if the [quoted text clipped - 9 lines] > > Thanks in advance.. Is this for security, e.g. you have rogue programmers that may screw around with your program, or is it for code correctness, e.g. you might accidentally change the variable, but you want to be able to detect these changes as bugs and fix them? - Oliver > Is this for security, e.g. you have rogue programmers that may screw > around with your program, or is it for code correctness, e.g. you might > accidentally change the variable, but you want to be able to detect these > changes as bugs and fix them? Mostly for correctness. Actually, I ran FindBugs [http://findbugs.sourceforge.net/] on the code and that was one of the potential flaws it uncovered. >> Is this for security, e.g. you have rogue programmers that may screw >> around with your program, or is it for code correctness, e.g. you might [quoted text clipped - 4 lines] > [http://findbugs.sourceforge.net/] on the code and that was one of the > potential flaws it uncovered. As another poster pointed out, you can use the Collections class' "give me an immutable version of this list" methods for this purpose. I believe that this method just wraps your collection, rather than duplicating all the pointers within it, thus saving a bit of memory and time over cloning. However, cloning may be more secure in that rogue programmers could use reflection and casting and stuff like that to gain access to the underlying (mutable) collection. - Oliver Joe Attardi wrote On 03/21/06 10:46,: > I have some table model classes that contain String[] objects that > contain the column names. Now, since a String[] is mutable, even if the [quoted text clipped - 7 lines] > or would that be considered a good practice so that the column names > cannot be changed by ill-mannered code? I'd start by asking what harm will come if the column names are changed, and to whom. If the name- changing rogue can only hurt himself, how much effort should you expend to shield him from his own folly? If he can hurt others, though, ... Also, consider intermediate-level protection schemes. If the column headers are doing double duty as database field names or something (and hence mustn't be changed lest your communications with the database go awry), it might be better to separate the roles: Keep one closely- guarded array of database names, and another "decorative" array of column headers. Let the rogue mess with the headers if he likes (and if no other harm ensues), while keeping the database field names hidden away out of harm's reach. SignatureEric.Sosman@sun.com > I'd start by asking what harm will come if the > column names are changed, and to whom. [quoted text clipped - 4 lines] > lest your communications with the database go awry), it > might be better to separate the roles That is a good point, Eric, and the answer to your first question is, not much harm at all. The column names are just for display purposes. The column values are tied to integer constants for each column, i.e. private static final int COLUMN_NAME = 0; private static final int COLUMN_AGE = 1; ... switch (column) { case COLUMN_NAME: value = rowObject.getName(); break; case COLUMN_AGE: value = rowObject.getAge(); break; } ... etc. > Joe Attardi wrote On 03/21/06 10:46,: >> I have some table model classes that contain String[] objects that [quoted text clipped - 14 lines] > should you expend to shield him from his own folly? > If he can hurt others, though, ... I don't understand the distinction between himself and others. If passing the raw array allows bugs to be introduced either from malice or misunderstanding, then don't do it. It's much cheaper to prevent the problem than to debug and fix it >> I'd start by asking what harm will come if the >> column names are changed, and to whom. If the name- [quoted text clipped - 6 lines] > misunderstanding, then don't do it. It's much cheaper to prevent the > problem than to debug and fix it It's like the how on a typical file server, you can delete, muck around with, or otherwise damage your own files, but you can't damage other people's files. If the array contains a billion elements, it may be very costly to create a duplicate of the array. While you wouldn't nescessarily need to duplicate every element, you'd have to at least duplicate all of the pointers. - Oliver > If the array contains a billion elements, it may be very costly to > create a duplicate of the array. While you wouldn't nescessarily need to > duplicate every element, you'd have to at least duplicate all of the > pointers. The arrays are very small, and are of a fixed size. The biggest table in the app has like 9 columns, so the biggest array is an int[9]. So I suppose it's cheap enough to just do a shallow copy, so I might as well. >>> I'd start by asking what harm will come if the >>> column names are changed, and to whom. If the name- [quoted text clipped - 10 lines] > with, or otherwise damage your own files, but you can't damage other > people's files. But objects don't have owners, at least in Java. Corrupted data has a way of causing bugs in the oddest places. > If the array contains a billion elements, it may be very costly to > create a duplicate of the array. While you wouldn't nescessarily need to > duplicate every element, you'd have to at least duplicate all of the > pointers. If the objects themselves are immutable (as they are here, since they're Strings) , all you need is Collections.unmodifiableList(Arrays.asList(array)); Two additional objects, both small and independent of the size of the array. (Arrays$ArrayList seems to have only two fields, a pointer to the array and a modification count for the fast-fail iterators. Collections$UnmodifiableList also has two, both pointers to the list.) >>>> I'd start by asking what harm will come if the >>>> column names are changed, and to whom. If the name- [quoted text clipped - 6 lines] >>> misunderstanding, then don't do it. It's much cheaper to prevent the >>> problem than to debug and fix it [...] > If the objects themselves are immutable (as they are here, since they're > Strings) , all you need is > > Collections.unmodifiableList(Arrays.asList(array)); See other posts I've been making on this thread about the distinction between security (e.g. hurting others) and bug prevention (e.g. hurting oneself). - Oliver > I'd start by asking what harm will come if the > column names are changed, and to whom. [quoted text clipped - 4 lines] > lest your communications with the database go awry), it > might be better to separate the roles That is a good point, Eric, and the answer to your first question is, not much harm at all. The column names are just for display purposes. The column values are tied to integer constants for each column, i.e. private static final int COLUMN_NAME = 0; private static final int COLUMN_AGE = 1; ... switch (column) { case COLUMN_NAME: value = rowObject.getName(); break; case COLUMN_AGE: value = rowObject.getAge(); break; } ... etc. > Would it be overkill to, in getColumnNames(), return a copy of the > array instead via: > return (String[]) columnNames.clone(); From 1.5 you can write: return columnNames.clone(); > or would that be considered a good practice so that the column names > cannot be changed by ill-mannered code? You should always make a defensive copy when passing mutable values into or out of an object. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.