¿Cómo crear el editor de texto más seguro en Django?

2

Como seguimiento de esta pregunta , me pregunto cuál es la forma más segura (usando el marcado o la reducción) para permitir a los usuarios formatear sus entradas y cargar imágenes en una aplicación Django.

No pregunto por una guía detallada paso a paso, sino por la estrategia que debería adoptar, y posiblemente las aplicaciones / bibliotecas disponibles para usar.

ACTUALIZACIÓN: Por most secure , me refiero a inmune a XSS y otros vectores de ataque comunes contra editores de texto.

    
pregunta Jand 03.09.2015 - 01:07
fuente

1 respuesta

1

Independientemente del marco o el idioma, hay algunas cosas que debe considerar:

  • ¿Qué funcionalidad necesito (o deseo)?
  • ¿Cómo puedo equilibrar las funciones con Principle of Least Privilege?
  • ¿Qué recursos tengo que pueden ser limitaciones?

Mi respuesta será independiente del lenguaje porque estos principios se aplicarán independientemente del idioma o el marco que esté utilizando.

Desde su publicación, desea que los usuarios puedan agregar comentarios (como el contenido de SE) y subir imágenes. Hay algunos métodos comunes para hacer esto.

  • controles HTML para usuarios (mala idea)
  • BBCode o marca similar (puede ser efectivo, pero molesto para los usuarios)
  • Markdown o RST (ambos están diseñados para ser más naturales)
  • Texto sin formato (no permite el formato de la interfaz de usuario)

Como lo han demostrado Wordpress y otras aplicaciones, permitir que los usuarios publiquen código HTML es una mala idea (tm). Si desea que los usuarios tengan un formato de UI, el texto plano es el más seguro, pero no permitirá el formato de UI. Así que eso deja a BBCode y Markdown como las dos soluciones comunes restantes. SE utiliza Markdown. Es más natural que los usuarios escriban lo que es [b]Blah[/b] porque, para mayor énfasis, los usuarios escribirían **blah** para texto en negrita de todos modos. Por supuesto, este no es el único método, pero reduce en gran medida (¡pero no elimina!) XSS. Entonces, ¿por qué no eliminar? Si no tiene cuidado con el análisis de Markdown (o el lenguaje de marcado que elija), puede terminar con ataques XSS en los enlaces. La mayoría de los casos de uso solo necesitan los manejadores de protocolos http y https en las URL, por lo que tiene la oportunidad de ejercer el principio de privilegio mínimo allí.

En cuanto a la carga de imágenes, esto puede ser un poco más difícil. Aquí es donde entran los recursos que mencioné. ¿Tiene la capacidad de comprar un dominio de zona de pruebas? Si lo hace, además de procesar imágenes, puede servirlas desde un dominio de zona de pruebas de modo que limite la exposición para XSS, RCE y otros ataques. Un dominio de sandbox es aquel que elimina contenido del origen de la aplicación. Por ejemplo, las aplicaciones de www.google.com (Gmail, Google Docs) utilizan googleusercontent.com como el dominio de sandbox. El único propósito de este dominio es servir contenido proporcionado por el usuario. Las cookies de Google y DOM no son accesibles porque el origen es diferente. Además, este dominio debe servir contenido de un servidor que no tiene la capacidad de hacer nada más que servir contenido estático, por lo que el código PHP no se puede incrustar en las imágenes, o una vulnerabilidad en el procesamiento de imágenes no afectará su base de datos y el código de la aplicación. .

¿Procesamiento de imágenes? Otra práctica recomendada es pasar las cargas de imágenes a través del procesamiento de imágenes. Si solo espera JPG y PNG, por ejemplo, esto es fácil. Puede cambiar el tamaño de una imagen 1: 1, y fallará en las imágenes rotas, eliminando gran parte de los vectores XSS y RCE.

Como sin duda habrás notado, mi respuesta ha sido sobre las capas de defensa. Cuando consumes datos de usuario, no hay panacea. Debe sopesar los riesgos, las funciones deseadas y la mejor manera de limitar la exposición de las funciones que desea ofrecer a los usuarios.

    
respondido por el user79537 03.09.2015 - 04:30
fuente

Lea otras preguntas en las etiquetas