Security implications of code is data/data is code

[Daniel Compton]

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? Is this an issue or am I missing something really obvious here?

Thanks, Daniel.

[Daniel Compton]

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.

[mynomoto]

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

[Jeremy Heiler]

Your thinking is correct. This is why it's important to be able to parse
your data in a context separate from your code. A prime example of this
is having a JSON parser instead of using JavaScript's eval.

For Clojure, you can either dynamically set *read-eval* to false and use
clojure.core/read, or use just clojure.edn/read instead.

You can read more about EDN here: https://github.com/edn-format/edn

;; Jeremy

[Jeremy Heiler]

(Sorry, I didn't realize there were other messages in this thread.)