[Tex/LaTex] Escaping special LaTeX characters in user-defined input text

charactersSecurityverbatim

Background

Users can provide text, which is transformed using XSL into a LaTeX document. The XSL template that transforms the XML document (containing user-defined text) currently resembles:

<xsl:template match="user-text">
  <xsl:text>  \item </xsl:text>
  <xsl:apply-templates />
</xsl:template>

This is then transformed into:

\item This is the text the user provided.

Problem

This allows the user to submit maliciously crafted LaTeX:

\item This is the \{latex} the user provided.

Ideas

Some ideas:

\begin{verbatim} and \end{verbatim} cause the text to appear without formatting (i.e., a monospace font).
Write an XSLT function that escapes the special characters.

Question

What is the simplest way to ensure user-defined text does not get interpreted as LaTeX code?

Something like \begin{verbatim} would be perfect if it didn't change the font, and prevent text from wrapping.

Best Answer

If you want to render LateX syntax harmless in user input it either requires balanced braces (so that you can pick up the material as an argument and pass it through \scantokens) or it requires es sequence of "stop" tokens that are known not to be part of the material, e.g., \end{verbatim} or + in in \verb+foo+.

Neither can be guaranteed if you have no control whatsoever about the user input, e.g., what would happen if you user writes: "This text contains \end{verbatim} and now I'm free to use \LaTeX{} code."? Then it will blow up or at least execute the second part.

So if safety is important then XSLT is the way to go in my opinion. If you can live with that danger than consider changing \verbatim@font which is command that sets up the font used in verbatim and \verb. Its default definition is

\def\verbatim@font{\normalfont\ttfamily}

So if you change this to do "nothing" then you would get the normal body font.

Update (sorry wrong time of the day)

Of course that doesn't solve the fact that "verbatim" does not wrap. To fix this what is really needed is to write your own version of a "verbatim" environment" that doesn't change spaces to active and doesn't add

  \obeylines \verbatim@font \@noligs
  \hyphenchar\font\m@ne
  \everypar \expandafter{\the\everypar \unpenalty}%

in the first place, as those are your offenders.

Related Solutions

[Tex/LaTex] Problem copying text from latex PDF – special characters

You could use T1 font encoding with support for special characters:

\usepackage[T1]{fontenc}

[Tex/LaTex] Handling of special LaTeX characters in text

For the underscore it's quite easy:

\documentclass{article}
\usepackage[T1]{fontenc}

\catcode`_=12
\begingroup\lccode`~=`_\lowercase{\endgroup\let~\sb}
\mathcode`_="8000

\begin{document}
Under_score but $a_{x}$
\end{document}

Actually the line \mathcode`_="8000 is redundant, but repeating it makes our intentions clear.

We make the character _ is "math active", i.e., it behaves like a macro, but only in math mode. The \begingroup\lccode... trick defines this macro to be equivalent to \sb which in turn is equivalent to the usual _ for introducing a subscript. In order that it's really seen as a math active character, we need to give it category code 12, which also makes it printable (outside math mode). However, we need a font that has an underscore in the right position, so we load the T1 output encoding.

Other special characters have to be treated in different ways. For example, the $ symbol can be "neutralized" by saying

\usepackage{fixltx2e}
\catcode`$=12

in the preamble; the package is necessary because it "robustifies" the $ and $ commands. In-line formulas must now be input with these commands, of course.

For the &, one can say

\def\AM{&}
\catcode`&=12

and use \AM for marking alignment points in tabular environments.

Also the # character can be neutralized, as long as after saying

\catcode`#=12

one doesn't try defining new commands.

However, I don't recommend to change catcodes (other than the underscore, perhaps). A "search and replace", in case of a conversion to other formats, is safer.