"Безопасный" процессор markdown для PHP?

есть ли PHP-реализация markdown, подходящая для использования в публичных комментариях?

в основном он должен разрешать только подмножество синтаксиса markdown (полужирный, курсив, ссылки, блок-кавычки, блоки кода и списки) и удалять все встроенные HTML (или, возможно, избегать его?)

Я думаю, один из вариантов-использовать обычный синтаксический анализатор markdown и запускать вывод через HTML-очиститель, но есть ли лучший способ сделать это..?

мы используем PHP markdown Extra для остальной части сайта, поэтому нам уже придется использовать вторичный парсер (не"дополнительная" версия, поскольку такие вещи, как поддержка сноски, не нужны).. Также кажется более приятным разбор только *bold* текст и все бежали в &lt;a href="etc"&gt;, чем генерирующие <b>bold</b> текст и попытка очистить биты, которые мы не хотим..

кроме того, в соответствующей заметке мы используем элемент управления WMD для" основного " сайта, но для комментариев, какие еще есть варианты? Предварительный просмотр javascript WMD хорош, но для этого потребуется такая же "кастрация", как и уцененный процессор PHP (он не может отображать изображения и т. д., иначе кто-то отправит, и их рабочая уценка "сломается")

В настоящее время мой план заключается в использовании метода PHP-markdown - > HTML santiser и редактировании WMD для удаления синтаксиса изображения/заголовка из showdown.js - но, похоже, это было сделано бесчисленное количество раз..

по сути:

  • есть ли" безопасная " реализация markdown в РНР?
  • есть ли редактор разметки HTML/javascript, который может иметь те же параметры, которые легко отключить?

обновление: я закончил тем, что просто запустил markdown() выход через очиститель HTML.

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

4 ответов


PHP Markdown имеет параметр дезинфицирующего средства, но он, похоже, нигде не рекламируется. Взгляните на верхнюю часть Markdown_Parser класс markdown.php (начинается на строке 191 в версии 1.0.1 m). Нас интересуют строки 209-211:

# Change to `true` to disallow markup or entities.
var $no_markup = false;
var $no_entities = false;

если вы измените их на true, разметка и сущности, соответственно, должны быть экранированы, а не вставлены дословно. Кажется, что нет встроенного способа изменить их (например, через конструктор), но вы всегда можете добавить один:

function do_markdown($text, $safe=false) {
    $parser = new Markdown_Parser;
    if ($safe) {
        $parser->no_markup = true;
        $parser->no_entities = true;
    }
    return $parser->transform($text);
}

обратите внимание, что вышеуказанная функция создает новый парсер при каждом запуске, а не кэширует его, как предоставленный Markdown функция (строки 43-56) делает, так что это может быть немного на медленной стороне.


JavaScript Markdown Editor Гипотеза:

  • используйте JavaScript-управляемый редактор Markdown, например, на основе showdown
  • удалить все значки и визуальные подсказки с панели инструментов для нежелательных элементов
  • настройка фильтра JavaScript для очистки нежелательной разметки при отправке
  • проверьте и затвердеть все изменения JavaScript и фильтры локально на вашем компьютере
  • зеркало этих фильтров в скрипте представления PHP, чтобы поймать то же самое на серверный.
  • удалить все ссылки на нежелательные элементы из справки / учебники

Я создал редактор Markdown в JavaScript, но он имеет расширенные функции. Это заняло большой кусок времени и пересмотра SVN. Но я не думаю, что было бы так сложно изменить редактор Markdown, чтобы ограничить разрешенный HTML.


Если вы хотите написать свой собственный парсер, почему бы не использовать архитектуру кода.

при отправке ваших / (пользовательских) комментариев вам нужно санировать текст с помощью mysql_escape_real_string (), да, есть другие функции, но это остановит любые инъекции JS.


Как насчет запуска htmlspecialchars на вводимом пользователем входе, прежде чем обрабатывать его через markdown? Он должен избегать всего опасного, но оставить все, что markdown понимает.

Я пытаюсь придумать случай, когда это не сработает, но не могу ничего придумать.