Not every input is through the reader. For instance, Integer.parse takes a string argument and returns a java object. So there's no security problem there, unless it's a problem with the Integer class itself.
Another piece of the puzzle, Clojure needs a way to represent objects and code as data. It knows how to encode this object as data if it needs to be serialized, by a case of the the print-dup multimethod. If this is not defined, you'll get an error like: CompilerException java.lang.RuntimeException: Can't embed object in code, maybe print-dup not defined: BufferedImage@612dcb8c: type = 2 DirectColorModel: rmask... This resultant data can be read in order to recreate the java objects that correspond to the data, which of course means 'read' needs to be able to execute arbitrary code to create those objects. Anything using 'read' is subject to security problems by the execution of arbitrary code, however there is control over this facility provided to you in a number of ways. For one, see *read-eval*, although setting it false doesn't totally solve the problem. There is an implementation of the reader that is specific to EDN and doesn't require such measures, also tools.reader can be used in the case where you're dealing with things known as data, not arbitrary code. In short, homoiconicity in principle does not restrict us from creating multiple implementations of readers, each having different capabilities but similar outputs, objects in memory. On Tue, Jan 21, 2014 at 7:36 PM, mynomoto <mynom...@gmail.com> wrote: > Hi Daniel, > > I'm not an expert in security but AFAIK this is not a problem. Every user > input is a string and you chose how to parse it. There is a edn reader that > is safe, but you can use specific parsers depending on the input. Of course > if you read and eval the string anything could happen, but nobody would do > that. > > Best, > mynomoto > > On Tuesday, January 21, 2014 10:22:11 PM UTC-2, Daniel Compton wrote: >> >> I've been thinking for a while about what the security implications are >> for a homoiconic language like Clojure where code is data and data is code. >> What protections do you have against malicious input being automatically >> evaluated by the reader? It seems like every user input would be a possible >> case of 'Clojure injection'. Is this an issue or am I missing something >> really obvious here? >> >> Thanks, Daniel. >> > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/groups/opt_out. > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
