Меры предосторожности и техники безопасности для представленной пользователем демонстрационной зоны кода

Question

Может быть, это не реально. Но в основном я занимаюсь разработкой сайта для обмена фрагментами и хотел бы, чтобы у него была «живая демо-зона».

Например, вы просматриваете некоторые фрагменты и нажимаете кнопку «Демо». Появляется новое окно, которое выполняет веб-код.

Я понимаю, что при этом задействованы миллиарды угроз безопасности - XSS, теги, вредоносное вредоносное ПО / диск при загрузке, pr0n и т. Д. И т. Д. И т. Д.

Сообщество сможет пометить заявки, которые являются явно непослушными, но, очевидно, некоторые из них останутся незамеченными (и во многих случаях кому-то придется стать жертвой, чтобы обнаружить какую-либо неприятную вещь, поданную).

Так что мне нужно знать: Что мне следует сделать - в плане безопасности - чтобы пользователи могли отправлять код, но при этом ничего вредоносного не может быть запущено или выполнено вне сайта и т. Д.?

Для вашего сведения, мой сайт работает на PHP с использованием CodeIgniter.

Jack

Answer 1

Вы не можете вносить белый или черный список PHP, он просто не работает. Если вы пишете список команд, которые я могу использовать, или мешаете мне использовать вредоносные функции, что мешает мне написать:

$a = 'mai';

{$a .'l'}('somebody@important.com', 'You suck', 'A dodgy message sent from your server');

Вы не можете вносить белый или черный список PHP.

Answer 2

Как указал Фрэнк, если вы хотите поддерживать высокий уровень безопасности, используйте технику белого списка. Это, конечно, имеет свою цену (может быть слишком ограничительным, трудно осуществимым).

Альтернативный путь - разработать технику черного списка. т.е. разрешить только код, который не вызвал никаких звонков. Это проще, потому что вы должны указать меньше вещей, но он не будет ловить новые эксплойты.

В Интернете доступно множество информации по обоим методам.

Использование функций безопасности CodeIgniters (фильтрация XSS и т. Д.) Не поможет вам продвинуться вперед, поскольку большинство фрагментов не будут допущены.

Что бы вы ни делали, вы должны помнить это:

Не думайте, что вредоносный код будет иметь целью просто навредить посетителям вашего сайта. Он также может быть направлен на компрометацию вашего сервера с помощью вашего анализатора / инспектора кода. Например, допустим, Алиса загружает фрагмент кода foo. Алиса намеренно создает фрагмент, чтобы ваш анализатор пометил его как вредоносный из-за эксплойта XSS. Допустим, ваш парсер также обновляет базу данных вредоносным фрагментом для дальнейшего изучения. Алиса знает это. Наряду с эксплойтом XSS Алиса внедрила в код некоторый код SQL, поэтому, когда вы вставляете фрагмент в базу данных, он будет делать всякие плохие вещи.

Если вы действительно параноик, у вас может быть изолированный сервер, единственной обязанностью которого будет проверка фрагментов кода. Таким образом, в WCS будет взломан только этот сервер с низким уровнем риска, и у вас будет (надеюсь) достаточно времени для исправления / аудита ситуации.

Надеюсь, это поможет.

Answer 3

Если вы разрешаете только код javascript, то вы должны сделать следующее -

1. Купите одноразовое доменное имя, которое нельзя отождествить с вашим доменом
2. Обслуживание введенного пользователем кода в iframe, размещенном на одноразовом домене

Это, по сути, то, что делает iGoogle. Это предотвращает XSS, потому что вы используете другой домен. Единственная лазейка, о которой я знаю, это то, что злой код может изменить местоположение веб-страницы.

Если вы намереваетесь поделиться фрагментами кода на стороне сервера, тогда это другая игра. Для фрагментов java / jsp вы можете использовать внутренние классы безопасности JVM для запуска кода в песочнице. Вы должны найти много информации об этом, если вы Google. Я хотел бы думать, что это то, что Google использует в App Engine (хотя я не уверен).

Что-нибудь кроме Java, я не уверен, как защитить. Dot Net, возможно, имеет аналогичную концепцию, но я сомневаюсь, что вы можете подобрать фрагменты кода PHP в изолированной среде аналогичным образом.

Answer 4

Для вашего сведения, мой сайт работает на PHP с использованием CodeIgniter

Извините, Джек, если вы считаете, что это мало-мальски актуально, вы очень далеки от понимания любого правильного ответа на вопрос - не говоря уже о том, чтобы отличить неправильные ответы.

Любая создаваемая вами песочница, которая не позволит кому-либо атаковать вашу машину или ваших клиентов, будет настолько ограничена, что ваши клиенты не смогут делать гораздо больше, чем «печатать».

Вам нужно будет запустить CLI-версию suhosin в пользовательской тюрьме chroot - и поддержка отдельных сред для каждого сценария будет абсолютно непрактичной.

С