Безопасность PHP: риски при оценке введенной пользователем строки - PullRequest
2 голосов
/ 22 марта 2012

Позвольте мне предвосхитить это, сказав, что я хорошо знаю, что запускать пользовательский код в серверной среде рискованно. Забавьте меня - мой вопрос относится к оценке строк и подмножеству языка, который может быть выполнен в этом контексте.

Итак, я сейчас создаю систему генерации шаблонов и хочу, чтобы она была быстрой. Супер, супер, супер быстро. Эта вещь будет избита за массовые рассылки по электронной почте и тому подобное. Подход, который я использую, заключается в том, чтобы пользователи предоставляли введенные пользователем теги шаблонов, которые перед сохранением превращаются в подстановки переменных PHP через регулярные выражения. Предполагая, что мои регулярные выражения являются пуленепробиваемыми, считаете ли вы, что безопасность этого процесса приемлема?

  • шаблон вводится пользователем, с такими тегами, как [[contact.name]] и аналогичными.
  • после сохранения regex преобразует их в переменные PHP, поэтому вышеуказанный подстановочный знак становится {$contact['name']} в строке шаблона.
  • Мы также проверяем наличие чего-либо, что может быть преобразовано в доступную переменную из суперглобальной области, поэтому [[_SERVER]], [[GLOBALS]] и т. Д., А также [[this все запрещены и регистрируются как попытки взлома.
  • Другие символы, имеющие особое значение в строке в двойных кавычках ($, " и \), также экранируются.
  • процесс генерации выглядит следующим образом:
    • генерация - это метод класса, который запускается. Единственная передаваемая переменная - это $contact, который является массивом.
    • строка шаблона считывается в другую локальную переменную (в данном случае $__templateString). Теоретически пользователи могут получить доступ к этой переменной в своих шаблонах, но на самом деле не имеет значения, делают ли они - не угроза безопасности, просто глупость.
    • Код для генерации шаблона будет просто eval('return "' . $__templateString . '";');

Есть ли здесь какие-нибудь дыры, которые мне не хватает? Я почти уверен, что единственными потенциальными рисками являются вопросы доступа к области, и я думаю, что я охватил все свои базы там.

Ответы [ 2 ]

1 голос
/ 22 марта 2012

Бесполезный бред: когда я был контактом по безопасности для дистрибутива Linux, разработчики PHP попросили нас прекратить вызывать сбои интерпретатора при некорректном вводе «уязвимостей безопасности». Они были непреклонны в том, что кто бы ни предоставил сценарии, ему доверяли на 100%, и я полностью ожидал, что с eval() будут обращаться так же.

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

Далее рассмотрите возможность развертывания с системой обязательного контроля доступа , такой как AppArmor , SELinux , TOMOYO или SMACK . Таким образом, вы можете ограничить потенциальный ущерб от взломанного ввода минимальным количеством ресурсов, необходимых для выполнения работы. . (Я работаю над AppArmor с 2000 года, так что это был бы мой предпочтительный выбор для многих сред. Но, учитывая другие, все они представляют собой высококачественные продукты, предназначенные для решения различных проблем, и одна или другая может лучше подходить для вашей среды .)

1 голос
/ 22 марта 2012

Так что, если я введу этот шаблон:

" . mysql_query('DROP TABLE users') . "

Приятно, что вы защищаете от возможного доступа к переменным , вы не хотите, чтобы люди обращались, но eval оценивает весь код, а не только переменные. И попробуйте найти регулярное выражение, чтобы отфильтровать это ...

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...