Menu > Articles de la revue de presse : - l'ensemble [tous | francophone] - par mots clé [tous] - par site [tous] - le tagwall [voir] - Top bi-hebdo de la revue de presse [Voir]

---

S'abonner au fil RSS global de la revue de presse

---

Présentation : Since I named the first bit as Part I in February, I'm long overdue for the second part. The problem is that my hands are tied by the fact that Sun still hasn't fixed a lot of the things I wanted to write about, so I'm short on material. Immutability wikipedia Aside from being a software design pattern, immutability plays a big role in security, as well. At least in an environment such as the Java security sandbox. The Sun Secure Coding Guidelines section about input and ouput talks about making immutable copies of inputs and outputs. Even if you've never put serious thought into this, the importance of immutability quickly becomes obvious. Steve Let's say my method takes a java.util List of Strings as a parameter, performs some security validation on the list and then performs some privileged action on the list. 001 public class PrivilegedClass 002 003 public void processStrings java.util.List strings 004 for String str strings 005 if isOk str 006 throw new SecurityException 007 008 009 010 for String str strings 011 doPrivilegedOperation str 012 013 014 015 private void doPrivilegedOperation String str 016 privileged stuff 017 code omitted 018 019 020 private boolean isOk String str 021 security check for string 022 code omitted 023 return false 024 025 026 Bob The problem is that java.util.List is in interface and can be implemented in a mutable way. Also virtually all the public List implementations included in Java are mutable, so one wouldn't even have to go through the trouble of creating a mutable version - one could just use java.util.ArrayList. The problem with the mutability is that an ill intentioned caller of the method could pass a list which contains different values while the method does its validation, and then another set of harmful values for the actual processing after the validation has passed. This could be done via timing, or by crafting one's own List implementation for a more exact attack. If the method uses .iterator to iterate through the list, the first call to .iterator used by validation could be made to return one set of Strings and the 2nd call to .iterator used by the post-validation processing could be made to return another set of Strings. It's a well known, generic problem. Let's look at some ways to protect your method and what could go wrong with them. Forgive the silliness of some of these examples, it's just to give the notion of how easy it is to get it wrong. Steve I could change the method signature to only accept a more specialized StevesImmutableList. 003 public void processStrings StevesImmutableList strings Steve I'd then define StevesImmutableList as a class whose constructor receives a String array and stores it in a private String array field and only has a getter method which returns the array. 001 package version1 002 003 public class StevesImmutableList 004 005 private String strings 006 007 public StevesImmutableList String strings 008 this.strings strings 009 010 011 public String getStrings 012 return this.strings 013 014 015 Bob Arrays are always mutable. The size can't be changed, but the contents given its size is greater than zero are free game. And your method is returning a reference to its internal array. Steve What if I define my private internal array as final Bob That doesn't help. It'll guarantee that your private field always points to the same array, but the array contents are free game. Steve Better have the method call .clone on the array and return a copy of the array instead of the internal array. 001 package version2 002 003 public class StevesImmutableList 004 005 private String strings 006 007 public StevesImmutableList String strings 008 this.strings strings 009 010 011 public String getStrings 012 return this.strings.clone 013 014 015 Bob Your constructor is receiving an array and storing it as the internal array. A caller with bad intentions could create an array, keep a reference to it, pass it to your object and later on modify it. Steve Ok, let's call .clone on the incoming array as well. 001 package version3 002 003 public class StevesImmutableList 004 005 private String strings 006 007 public StevesImmutableList String strings 008 this.strings strings.clone 009 010 011 public String getStrings 012 return this.strings.clone 013 014 015 Steve Let's also add an overloaded constructor that receives a List to improve the usability of this class. 001 package version4 002 003 public class StevesImmutableList 004 005 private String strings 006 007 public StevesImmutableList java.util.List stringList 008 this.strings stringList.toArray new String stringList.size 009 010 011 public StevesImmutableList String strings 012 this.strings strings.clone 013 014 015 public String getStrings 016 return this.strings.clone 017 018 019 Bob Now you're calling toArray on a List object that you can't really trust. It could return an array and keep a reference to that array for itself for future modification. Steve Ok, let's do a manual conversion of the List to an array. 001 package version5 002 003 public class StevesImmutableList 004 005 private String strings 006 007 public StevesImmutableList java.util.List stringList 008 this.strings new String stringList.size 009 for int i 0 i stringList 008 this.strings new String stringList.size 009 for int i 0 i stringList 008 this.strings new String stringList.size 009 for int i 0 i stringList.size i 010 this.strings i stringList.get i 011 012 013 014 public StevesImmutableList String strings 015 this.strings strings.clone 016 017 018 public String getStrings 019 return this.strings.clone 020 021 022 private void readObject java.io.ObjectInputStream s 023 throws java.io.IOException, ClassNotFoundException 024 String streamStrings String s.readObject 025 this.strings streamStrings.clone 026 027 028 private void writeObject java.io.ObjectOutputStream s 029 throws java.io.IOException 030 s.writeObject this.strings 031 032 Now some examples from core Java classes java.lang.reflection.Proxy Proxy has a method getProxyClass which takes a ClassLoader and an array of Class objects, that are supposed to be interfaces, as parameters. It performs some validation on the Class array, and then it dynamically defines and returns a new Class for a dynamic Proxy class which implements all the interfaces of the Class array. If the validation fails, the method throws an Exception and obviously doesn't return anything . The getProxyClass uses the user-suplied Class array for the validation and later on for the construction of the Proxy class, so it could be called with an array which has one set of classes for the validation and another set of classes for the Proxy construction. However, the validation here, as far as I can tell, is strictly for usability. Without the validation, if you gave the method an invalid set of parameters it would sometimes fail with some strange class verification exception. With the validation, the caller gets feedback which is more readily understandable. java.lang.String Strings are supposed to be immutable. A lot of things depend on the immutability of Strings. There is no defensive programming in the core classes against mutable Strings which makes sense, because it'd take a lot of work . The immutability of Strings hinges on the fact that one cannot access the char array in which the String contents are stored. Now, String does leak the internal array to any registered CharSet who wants it. However, registering a CharSet requires a CharSetProvider and that, in turn, requires the charsetProvider permission. Unsigned applets don't have that permission and can't create their own registered CharSets. But it is something to keep in mind. If you're granting the charsetProvider permission, you're pretty much implicitly giving away full access.

Les mots clés de la revue de presse pour cet article : security
Les videos sur SecuObs pour les mots clés : security
Les mots clés pour les articles publiés sur SecuObs : security
Les éléments de la revue Twitter pour les mots clé : security





Les derniers articles du site " Slightly Random Broken Thoughts" :

- Java 6 update 26 is out
- Inflated Java Malware Infection Rates
- Oracle Java Applet Clipboard Injection Remote Code Execution Vulnerability
- Java JFileChooser Programmatic Manipulation Vulnerability
- Trusted Method Chaining for Network Interface details
- Trusted Method Chaining to a System.exit
- Hazards of Duke
- Java 6 Update 22 is out
- Breaking Defensive Serialization
- Why Complex Powerful is a bad combination for security

---

S'abonner au fil RSS global de la revue de presse

---