Глубоко в пучинах спецификации HTML дремлет давно забытый ужасный зверь. Представьте себе узел DOM настолько могучий, что он может изменять тип содержимого разных частей документа. HTML-элемент, который заставляет парсер трепетать и замолкать, и которого не остановить даже его собственным тегом.

Мудрецы из W3C стараются держать информацию об этом ужасе подальше от взора простых смертных, чтобы избавить их от угрозы его безумия. Они советуют нам не использовать имя магического тега, призывающего это древнее зло.

Но мы сегодня, естественно, поступим наоборот и заглянем в глубины элемента <plaintext>, чтобы узнать, какие занятные вещи с его помощью можно делать.

Предостережение

Но сразу отмечу один важный момент — не используйте этот элемент в продакшене. В стандарте HTML это чётко прописано:

Элементы в списке ниже полностью устарели и не должны использоваться: [...] plaintext

Так чем же таким <plaintext> заслужил место в списке устаревших элементов? Если коротко, то он завершает работу HTML-парсера и говорит браузеру, что всё последующее содержимое страницы нужно интерпретировать как простой текст.

И это буквально. То есть реально всё, и даже любые закрывающие теги </plaintext> или </html> будут выводиться так, будто скрытный, незакрытый <pre> обезумел и поглотил оставшуюся часть страницы. Кстати, это делает <plaintext> единственным непустым элементом, вообще лишённым завершающего тега.

И для чего нам эта мощь?

На первый взгляд, такая суперсила выглядит как какая-то глупость. На второй….тоже. Ниже мы рассмотрим, как вообще этот элемент стал частью HTML, а пока используем его для одной конкретной цели: отладки кода сервера.

Естественно, основную работу на себя здесь возьмут специальные отладчики вроде XDebug для PHP или встроенные страницы ошибок во фреймворках вроде Django. И даже старый-добрый print "<script>console.log('here!')</script>" часто окажется кстати. Эти инструменты должны всегда быть у вас под рукой.

Но представьте себе следующий кейс: вы залезли глубоко в код в поиске неуловимого бага, который влияет только на часть вывода HTML, и хотите найти, где конкретно на отрисованной странице он всплывает. Самый быстрый способ — это поместить <plaintext> рядом с проблемным местом, перезагрузить страницу и, вуаля! Просто прокручиваем вывод до места, где начнётся разметка.

Это особенно полезно для просмотра отформатированного отладочного вывода, например при использовании var_dump() в PHP или error.stack в NodeJS. Добавьте тег <plaintext> перед этим выводом, прежде чем обрабатывать его как HTML, и нужная строка станет очевидной.

<?php
 # TODO delme!
 echo '<plaintext>'; var_dump($strange_variable);

При работе над приложением expressJS аналогичное решение может выглядеть так:

try {
     some_method();
 } catch (error) {
     response.send(<plaintext>${error.stack});
 }

История этого зла

Как так случилось, что эта, казалось бы, маргинальная фича попала во все популярные браузеры? По правде говоря, она была там с самого зарождения HTML, что подтверждается этим историческим документом W3C от 1992 года:

Plaintext

Этот тег указывает, что весь последующий текст должен восприниматься буквально [!] вплоть до конца файла. Смысл в том, чтобы отображать простой текст также, как примеры XMP-текста — моноширинным шрифтом и с использованием явных переносов строк. Записывается он так:

<PLAINTEXT>

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

Эта особенность также говорит о причине его изобретения. В те времена мощность передового NeXT PC, на котором Тим Бернерс-Ли писал первый веб-браузер, составляла четверть от уставшего смартфона 2009 года. Тогда было очень важно применять оптимизацию везде, где только можно.

Учитывая, что изначально WWW создавалась как место для обмена научной информацией, наличие больших кусков простого текста в составе вашей новёхонькой и навороченной HTML-страницы было распространённым явлением. Возможность завершать работу дорогостоящего HTML-парсера и возвращаться к стандартному выводу оставшейся части файла в виде простого текста играла очень важную роль.

Хотя такая функциональность не уникальна для HTML. К примеру, в языке Perl используется особый маркер, который сообщает парсеру, что оставшуюся часть файла анализировать не надо:

print 'this is Perl code';
END
cout << 'this isn’t anymore';

Только Perl-программисты используют эту возможность не из соображений производительности, а для встраивания в свои программы дополнительных данных.

Естественно, сегодня в свете многомегабайтных полезных нагрузок JS такая оптимизация стала полностью излишней.

Насколько это опасно?

Но этот элемент по-прежнему маячит во всех браузерах, так что будет нелишним иметь его особенности ввиду.

Чтобы понять, как эта фича может быть использована во вред, представьте себе функцию обработки комментариев в блоге, где комментирующий мог бы тайком встраивать в строку <plaintext>. Как умные разработчики, мы знаем, что пользовательскому вводу доверять нельзя, поэтому прогоняем комментарий через санитайзер. А теперь взглянем, где после этого всё может пойти не так.

Для теста мы используем строку <p><b>hello<plaintext>world!</plaintext></b></p> и проверим, как на неё среагирует несколько библиотек для очистки.

Неожиданный санитайзинг

Каждый санитайзер мы выполняем в самой минимальной конфигурации, которая даёт хоть какой-то вывод. В этом суть — санитайзеры являются инструментами безопасности, и они должны по умолчанию давать безопасный вывод.

Но результат получается довольно удивительный (кликните по названию библиотеки ниже, чтобы увидеть пугающие подробности). Вы заметите, что среди проверенных библиотек не найдётся и двух (кроме Sanitizer API и DOMPurify, первая из которых является прямым последователем второй), которые бы согласились по части правильной очистки строки.

console.log(Document.parseHTML(TEST_STRING).body.innerHTML);

<p><b>hello</b></p>

const div = document.createElement('div');
 div.innerHTML = TEST_STRING;
 console.log(div.innerHTML);

<p><b>hello</b></p><plaintext><b>world!&lt;/plaintext&gt;&lt;/b&gt;&lt;/p&gt;</b></plaintext>

Document.parseHTML(TEST_STRING, { sanitizer: { removeElements: []}}).body.innerHTML

echo -n "$TEST_STRING" | tidy

<p><b>hello</b></p>
<pre><b>world!</b></pre>

import xss from 'xss';
console.log(xss(TEST_STRING));

<p><b>hello&lt;plaintext&gt;world!&lt;/plaintext&gt;</b></p>

import { JSDOM } from 'jsdom';
import DOMPurify from 'dompurify';
 
const purify = DOMPurify(new JSDOM('').window);
console.log(purify.sanitize(TEST_STRING));

<p><b>hello</b></p>

<?php
 $config = HTMLPurifier_Config::createDefault();
 $purifier = new HTMLPurifier($config);
 printf($purifier->purify(TEST_STRING));

<p><b>helloworld!</b></p>

<?php
 use Symfony\Component\HtmlSanitizer\HtmlSanitizer;
 use Symfony\Component\HtmlSanitizer\HtmlSanitizerConfig;
 
 $config = (new HtmlSanitizerConfig())->allowSafeElements();
 $sanitizer = new HTMLSanitizer($config);
 printf($sanitizer->sanitize(TEST_STRING));

<p><b>hello</b></p><plaintext>world!</plaintext>

echo -n "$TEST_STRING" | xmllint --html -

<p><b>hello<plaintext>world!</plaintext></b></p>

import bleach
print(bleach.clean(TEST_STRING))

&lt;p&gt;<b>hello&lt;plaintext&gt;world!&lt;/plaintext&gt;</b>&lt;/p&gt;

import org.owasp.html.PolicyFactory;
 import org.owasp.html.Sanitizers;
 
 public class Sanitize {
     public static void main(String[] args) {
         PolicyFactory policy = Sanitizers.FORMATTING.and(Sanitizers.LINKS);
         String safe = policy.sanitize(TEST_STRING);
         System.out.println(safe);
     }
 }

<b>helloworld!&lt;/plaintext&gt;&lt;/b&gt;&lt;/p&gt;</b>

import nh3
print(nh3.clean(TEST_STRING))

<p><b>hello</b></p><b>world!&lt;/plaintext&gt;&lt;/b&gt;&lt;/p&gt;</b>

Итого, при использовании 11 методов очистки, мы получили 10 разных результатов!

Но сразу оговорюсь — я здесь не пытаюсь раскритиковать какие-либо библиотеки. Каждая из них имеет веские основания для своего поведения, и все они служат несколько разным целям.

Но этот эксперимент подчёркивает, что нужно чётко понимать предполагаемые задачи выбранного санитайзера и то, каким образом он изменит входные данные. Возможно, эта конкретная библиотека предназначена для удаления только потенциально опасных элементов с максимальным сохранением остального HTML без изменений? А может, её задача — соскрейпить из строки весь HTML или только экранировать спецсимволы HTML? Это будет сильно влиять на конечный результат.

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

Возьмём, например DOMPurify и HTML Purifier, взаимодействие которых может оказаться весьма опасным. DOMPurify будет удалять весь <plaintext>, включая его содержимое, и любая последующая проверка на присутствие вредоносной начинки даст отрицательный результат. HTML Purifier же, напротив, просто будет обрезать тег <plaintext>, сохраняя его содержимое на странице. Если мы доверимся предыдущему результату DOMPurify, то удивимся внезапному появлению в HTML-коде нового содержимого в буквальном виде.

Если одна библиотека используется для валидации ввода, а другая — для экранирования вывода, это создаёт угрозу межсайтового скриптинга, если только мы не идём на это сознательно, преследуя конкретные цели.

Пусть древнее зло дремлет дальше

В случае самого <plaintext> особой угрозы нет. Поскольку этот тег имеет встроенное экранирование HTML, его потенциальная опасность сильно ограничена. Потребуется весьма редкая комбинация ошибок и недочётов, чтобы выполнить в нём вредоносный код.

Ну и для подкрепления этого утверждения предлагаю создать такую комбинацию. Предположим, что вы на своём сайте встраиваете Content-Security Policy (CSP) в элемент <meta>, а не HTTP-заголовок:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

Это достаточно защитит вас от загрузки сторонних скриптов. Если атакующий найдёт возможность загрузить HTML-код до этого элемента, то сможет обнулить вашу CSP:

<script src="https://example.com/malicious.js"></script>
<plaintext>
<meta http-equiv="Content-Security-Policy" content="script-src 'self'">

Но, опять же, чтобы это сработало, должно совпасть ещё два момента:

• атакующий должен иметь возможность разместить HTML-код в <head> (так как метатеги CSP можно использовать только там);

• CSP не должна быть установлена через HTTP-заголовок.

Причём оставшаяся часть страницы в итоге преобразуется в text/plain, что лишает атаку какой-либо скрытности.

Так что сделаем вывод: знать особенности <plaintext> важно. Но если следовать проверенным практикам безопасности (например, стандарту OWASP Application Security Verification Standard), то это древнее зло будет нам не страшно.