Снизить вероятность того, что плагины PHP являются вредоносными - PullRequest
4 голосов
/ 03 июля 2010

Мне было интересно, какие шаги вы используете, чтобы сохранить загруженные плагины от злонамеренных?

Например, что делает WordPress для того, чтобы загружаемые плагины не просто выполнялись unlink('/')

Я предполагаю, что это частично зависит от того, как загрузчик устанавливает плагины, чтобы использовать его или ее собственное усмотрение, но принимают ли системы плагинов меры, чтобы минимизировать риск безопасности запуска сторонних плагинов?

Спасибо! Мэтт Мюллер

Ответы [ 3 ]

5 голосов
/ 03 июля 2010

Простой ответ: вы не можете сделать это программно. Просто не может быть сделано. Конечно, Wordpress имеет своего рода валидатор, чтобы определить, является ли плагин непристойным, но нет уверенности, что он безопасен.

Этим летом я стажер в Mozilla и работаю над валидатором, который сканирует надстройки, когда они отправляются на addons.mozilla.org. Я могу только представить, что Wordpress имеет очень похожий инструмент на их конце. Идея состоит в том, что приложение полностью отвергает явно вредоносный код (eval("evil nasty code");), а остальная его часть анализируется с помощью простой эвристики. Алгоритмы на месте отмечают некоторые потенциальные красные флажки на основе того, что он видит в пакете надстроек, и представляют эти заметки редакторам, которые затем просматривают код. Фактически, он превращается в процесс, управляемый человеком, но программное обеспечение помогает справиться с тяжелой работой.

Некоторые методы, которые использует валидатор Mozilla:

  • Проверка синтаксиса
  • Разбор кода и разметки (HTML / CSS) для поиска уязвимостей удаленного кода
  • Синтаксический анализ и анализ Javascript (проанализируйте JS в дереве AST и проанализируйте каждое утверждение, оценивая статические выражения максимально глубоко)
  • Тестирование на совместимость / устаревание

Вы можете проверить код здесь:

http://github.com/mattbasta/amo-validator

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

3 голосов
/ 03 июля 2010

unlink('/') не принесет никакого вреда, поскольку он только удаляет файлы, вам придется использовать rmdir или, точнее, рекурсивную rmdir реализацию.Я не думаю, что есть какой-либо способ предотвратить выполнение вредоносного кода, потому что существует много способов быть вредоносным.Вы можете ограничить вызов определенных функций в php.ini, но это поможет вам только до определенного момента.Например, str_repeat и unserialize являются общими функциями, но при вызове с правильными аргументами они могут быстро исчерпать всю память, выделенную для ваших PHP-скриптов.Но это только пример, более гнусный может выступить в качестве бэкдора или отправить все логины разработчику.Я думаю, в конце концов, вам придется довериться разработчику и сообществу, если вы не хотите самостоятельно проверять код.

1 голос
/ 03 июля 2010

Существуют инструменты для PHP, которые Статический анализ исходного кода , чтобы найти уязвимости. Инструменты анализа с открытым исходным кодом для php включают RATS и PHP-SAT .

Если вы когда-либо использовали статический анализ исходного кода, то вы знаете, что эти инструменты будут производить TON ложных срабатываний и ложных отрицаний. Никакой инструмент анализа исходного кода не может сказать вам, на 100% погоду или нет, программа имеет бэкдор или может быть вредоносной. Если бы это было возможно, у нас не было бы столько проблем с взломом сайтов. Wordpress сам по себе крайне небезопасен, равно как и все плагины, и это из-за ошибок, а не злобы.

Вредоносный код может быть запутан, скрыт и принимать множество различных форм. Попытка найти случайную уязвимость является гораздо более простой проблемой, чем преднамеренная. Бэкдор в PHP может быть простым, как добавление или удаление 2 байта .

Удаление 2 байтов:

$id=mysql_real_escape_string($id);
"select * from test where id=$id"
vs
"select * from test where id='$id'"

или добавление 2 байтов:

`$_GET[b]`;
...