¿Cómo escapar/eliminar caracteres especiales en el documento LaTeX?

Entiende el código de forma correcta antes de adaptarlo a tu trabajo y si ttienes algo que aportar puedes comentarlo.

Solución:

Aquí hay un código para implementar la respuesta de Geoff Reedy. Coloco este código en el dominio público.

"\#",
            "$"=>"\$",
            "%"=>"\%",
            "&"=>"\&",
            "~"=>"\~",
            "_"=>"\_",
            "^"=>"\^",
            "\"=>"\textbackslash",
            ""=>"\",
            ""=>"\",
    );
    return preg_replace( "/([^%~\\#$%&_\])/e", "$map['$1']", $string );

La única posibilidad (AFAIK) de realizar operaciones dañinas usando LaTeX es habilitar la posibilidad de llamar a comandos externos usando write18. Esto solo funciona si ejecuta LaTeX con el argumento –shell-escape o –enable-write18 (dependiendo de su distribución).

Entonces, mientras no lo ejecute con uno de estos argumentos, debería estar seguro sin la necesidad de filtrar ninguna parte.

Además de eso, uno todavía puede escribir otros archivos usando el newwrite, openout y write comandos ¿Es posible que no desee que el usuario cree y (sobre)escriba archivos? Entonces podría filtrar las ocurrencias de estos comandos. Pero mantener listas negras de ciertos comandos es propenso a fallar, ya que alguien con malas intenciones puede ocultar fácilmente el comando real ofuscando el documento de entrada.

Editar: Ejecutar el comando LaTeX utilizando una cuenta limitada (es decir, sin escribir en directorios no relacionados con látex/proyectos) en combinación con la desactivación write18 podría ser más fácil y más seguro que mantener una lista negra de comandos ‘peligrosos’.

En general, lograr la seguridad simplemente escapando de las secuencias de comandos es difícil de lograr sin reducir drásticamente la expresividad, ya que no existe una forma basada en principios para distinguir los CS seguros de los inseguros: Tex simplemente no es un lenguaje de programación lo suficientemente limpio como para permitir esto. Yo diría que abandone este enfoque a favor de eliminar la existencia de agujeros de seguridad.

El resumen de Veger de los agujeros de seguridad en Latex concuerda con el mío: es decir, los problemas son los escapes de shell y la creación de archivos. A continuación, algunos puntos adicionales, luego algunas recomendaciones:

1. No es suficiente evitar invocar activamente --shell-escape, ya que se puede habilitar implícitamente en texmf.cnf. Debe pasar explícitamente --no-shell-escape para anular texmf.cnf;
2. write18 es una primitiva de Etex, no de Tex de Knuth. Por lo tanto, puede evitar los Latex que lo implementan (que, desafortunadamente, es la mayoría de ellos);
3. Si está utilizando Dvips, existe otro riesgo: special Los comandos pueden crear archivos .dvi que soliciten a dvips que ejecuten comandos de shell. Entonces, si usa dvips, debe pasar el -R2 comando para prohibir la invocación de comandos de shell;
4. texmf.cnf le permite especificar dónde Tex puede crear archivos;
5. Es posible que no pueda evitar deshabilitar la creación de fuentes si desea que sus clientes tengan mucha libertad en las fuentes que pueden crear. Eche un vistazo a las notas sobre seguridad para Kpathsea; el comportamiento predeterminado me parece razonable, pero podría tener un árbol de fuentes por usuario, para evitar que un usuario pise los dedos de los pies de otros usuarios.

Opciones:

1. Sandbox las invocaciones de Latex de su cliente, y permítales la libertad de portarse mal en el sandbox;
2. Confíe en los valores predeterminados de kpathsea y prohíba los escapes de shell en látex y cualquier otro ejecutable utilizado para crear la salida PDF;
3. Reduzca drásticamente la expresividad, prohibiendo a sus clientes la capacidad de crear archivos de fuentes o cualquier archivo nuevo especificado por el cliente. Ejecute latex como un proceso que solo puede escribir en ciertos archivos ya existentes;
4. Puede crear un archivo de formato en el que el write18 cs, y el css de creación de archivos, no están vinculados, y solo existen macros que los invocan de manera segura, como para la creación de fuentes/toc/bbl. Esto significa que debe decidir qué funcionalidad tienen sus clientes: no podrán elegir libremente qué paquetes importar, sino que deben hacer uso de las opciones que les ha impuesto. Dependiendo del tipo de ‘plantillas’ que tenga en mente, esta podría ser una buena opción, ya que permite el uso de paquetes que usan escapes de shell, pero deberá auditar el código Tex/Latex que se encuentra en su archivo de formato.

Posdata

Hay un artículo de TUGBoat, Generación de PDF del lado del servidor basada en plantillas LATEX, que aborda otra versión de la pregunta a la que tomé, a saber, generar archivos PDF a partir de la entrada de formulario usando Latex.

Si te ha sido útil nuestro artículo, sería de mucha ayuda si lo compartieras con más seniors así nos ayudas a extender esta información.

---

---

Utiliza Nuestro Buscador