Нужны ли специальные приложения дезинфекции для приложений и веб-приложений на Лиспе?

Question

РЕДАКТИРОВАТЬ 3 С тех пор, как я задал этот вопрос, произошли некоторые новые события. По сути, я не «видел вещи», и веб-приложения, написанные на Clojure, были признаны уязвимыми, что вызвало изменения в Clojure 1.5 и очень горячем обсуждении групп Clojure Google.

Вот цитата из Hacker News об изменениях в Clojure 1.5:

Еще одна немного интересная вещь - это внезапное улучшение read-eval и EDN [2]. Это в основном из-за непогоды Ruby / Rubygems участвовал в YAML-эксплойтах, что вызвало обсуждение того, как читатель Clojure должен работать по умолчанию.

Отверстия были найдены, и уже слишком поздно, чтобы действительно исправить Clojure, поэтому read-eval по-прежнему будет поставляться по умолчанию с установленным значением true (потому что в противном случае это сломало бы слишком много вещей) , И любой, кто анализирует входные данные в Clojure, не должен использовать функции чтения по умолчанию, кроме функций EDN.

Так что я, конечно, ничего не видел, и людям не потребовалось много времени (даже 18 месяцев), чтобы найти способы атаковать обычные стеки веб-приложений Clojure.

РЕДАКТИРОВАТЬ 2 Я не знал этого, но мой вопрос - обман следующего вопроса (который был описан как «вопрос-убийца»): Безопасность / проверка данных Lisp

Если кому-то интересны ответы на этот вопрос, я бы предложил открыть этот вопрос и прочитать ответы гуру-лиспов, а не ответы типа , здесь ничего не видно, двигаться вперед, это как PHP или JavaScript ".

EDIT : Я хотел бы знать, если каким-то образом, поскольку это Лисп, злоумышленнику будет "проще" преобразовать "данные" (т. Е. "Созданный пользовательский ввод со злым умыслом"). ") в" код ". Например, мне нужно экранировать / заменить все круглые скобки в пользовательском вводе, прежде чем начинать "оценивать" / анализировать или что-то еще?

Оригинальный вопрос

Я все еще читаю о Лиспе, и вдруг мне стало интересно, что со всем этим «код - это данные» / «данные - это код», нужно ли Лисп выполнять очистку ввода для предотвращения атак?

Я специально думал о веб-приложениях, скажем, когда пользователь делает HTTP-пост.

Что если данные, которые он отправляет, содержат такие вещи:

This is some malicious (eval '(nasty-stuff (...)) or whatever.

(я не программист на Лиспе, это всего лишь пример того, что я имею в виду, это не означает, что на самом деле я имею в виду код)

Есть ли что-то особенное, о чем следует помнить из-за того, как работает Lisp? Например, если какой-то хакер темной стороны узнает, что какой-то веб-сервер работает на Clojure, может ли он использовать этот факт и затем ввести «код в скобках», который затем будет оцениваться на веб-сервере?

Это вообще проблема при получении / разборе пользовательских данных (и, следовательно, потенциально созданных данных) из Lisp?

Answer 1

Я написал несколько веб-приложений на Лиспе (то есть Common Lisp), и вот что я имел в виду:

• если вы используете read, вы должны всегда устанавливать *read-eval* в nil для любых ненадежных данных
• если вы имеете дело с генерацией кода - например, генерацией HTML, JS, CSS или SQL - который очень распространен в Лисп-ланде, вы не должны забывать использовать средства очистки, предоставляемые соответствующими библиотеками (не используйте необработанные входные строки)

По сути, это все. Более того, поскольку это Лисп, он обычно делает вашу систему менее подверженной атакам, потому что:

• стандартных атак нет (так как использование Lisp относительно редко)
• система довольно безопасна с точки зрения значений по умолчанию - это не уникально, но многие веб-ориентированные языки (в первую очередь, например, PHP) по умолчанию страдают от небезопасности, хотя и смягчаются современными инфраструктурами

Answer 2

Вы всегда должны предполагать, что инъекционные атаки возможны, пока не доказано обратное. Не зная больше о вашей конкретной среде Lisp и о том, с чем вы ее сравниваете, невозможно ответить, нужна ли вам «специальная» очистка.

• Мы знаем, что возможны атаки машинного кода.
• Мы знаем, что SQL-инъекция возможна.
• Мы должны предположить, что можно взломать любую систему, полную по Тьюрингу, будь то аппаратное или программное обеспечение.

Обратите внимание, что мягкий барьер между "кодом" и "данными" не является уникальным для Лисп. perl, однажды рабочая лошадка в мире Интернета имеет eval. Так делает PHP . Похоже, что внедрение Java-байт-кода также возможно.

Answer 3

Это действительно сводится к следующему: не используйте READ и не используйте EVAL.Вам необходимо точно знать, что вы отправляете одной или обеим этим функциям, а также контексты, в которых они выполняются.Если вы не позвоните ни одному из них, все в порядке.