«Безопасный» процессор уценки для PHP?

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

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

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

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

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

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

В основном:

  • Есть ли «безопасная» реализация уценки в PHP?
  • Есть ли редактор уценки HTML / javascript, который может иметь одинаковые параметры легко отключить?

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

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

У PHP Markdown есть опция sanitizer, но, похоже, она не рекламируется нигде. Взгляните на вершину класса Markdown_Parser в markdown.php (начинается в строке 191 в версии 1.0.1m). Нам интересны строки 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 Гипотеза:

  • Используйте редактор Markdown, управляемый JavaScript, например, на основе вскрытия
  • Удалите все значки и визуальные подсказки с панели инструментов для нежелательных элементов.
  • Настройка фильтра JavaScript для очистки нежелательной разметки при отправке
  • Тестирование и упрощение всех изменений и фильтров JavaScript на локальном компьютере
  • Зеркалируйте эти фильтры в сценарии отправки PHP, чтобы их поймать на стороне сервера.
  • Удалите все ссылки на нежелательные элементы из справки / руководства

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

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

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

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

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