Protección de Cross Site Scripting (XSS)

Los ataques XSS permiten al usuario inyectar scripts del lado del cliente en los navegadores de otros usuarios.

Esto se logra generalmente almacenando los scripts maliciosos en la base de datos donde se recuperará y mostrará a otros usuarios, o haciendo que los usuarios hagan clic en un enlace que hará que el JavaScript del atacante sea ejecutado por el navegador del usuario. Sin embargo, los ataques XSS pueden originarse desde cualquier fuente no confiable de datos, como cookies o servicios Web, siempre que los datos no estén lo suficientemente desinfectados antes de incluirlos en una página.

El uso de las plantillas de Django le protege contra la mayoría de los ataques XSS. Sin embargo, es importante entender qué protecciones proporciona y sus limitaciones.

Las plantillas de Django evitan caracteres específicos que son particularmente peligrosos para HTML. Si bien esto protege a los usuarios de la entrada más malintencionada, no es totalmente infalible. Por ejemplo, no protegerá lo siguiente:

Si var está configurado como ‘class1 onmouseover = javascript: func ()’, esto puede resultar en una ejecución no autorizada de JavaScript, dependiendo de cómo el navegador haga HTML defectuoso. (Citando el valor del atributo se solucionaría este caso.)

También es importante tener especial cuidado al utilizar is_safe con etiquetas de plantilla personalizadas, la etiqueta de plantilla safe, mark_safe y cuando se desactiva autoescape.

Además, si está utilizando el sistema de plantilla para generar algo distinto de HTML, puede haber caracteres y palabras totalmente independientes que requieran escapar.

También debe tener mucho cuidado al almacenar HTML en la base de datos, especialmente cuando se recupera y se muestra ese HTML.

Protección contra la falsificación de solicitudes cruzadas (Cross Site Request Forgery CSRF)

Los ataques CSRF permiten a un usuario malintencionado ejecutar acciones utilizando las credenciales de otro usuario sin el conocimiento o consentimiento de ese usuario.

Django tiene una protección integrada contra la mayoría de los ataques CSRF, siempre que lo haya habilitado y utilizado cuando corresponda. Sin embargo, como con cualquier técnica de mitigación, existen limitaciones.

Por ejemplo, es posible desactivar el módulo CSRF globalmente o para determinadas vistas. Sólo debe hacer esto si sabe lo que está haciendo. Hay otras limitaciones si su sitio tiene subdominios que están fuera de su control.

La protección CSRF funciona comprobando un nonce en cada solicitud POST. Esto garantiza que un usuario malintencionado no puede simplemente reproducir un formulario POST en su sitio Web y que otro usuario registrado inicie involuntariamente ese formulario. El usuario malicioso tendría que conocer el nonce, que es específico del usuario (mediante una cookie).

Cuando se despliega con HTTPS, CsrfViewMiddleware comprobará que el encabezado de referencia HTTP se establece en una URL con el mismo origen (incluido subdominio y puerto). Debido a que HTTPS proporciona seguridad adicional, es imprescindible asegurar que las conexiones usen HTTPS donde esté disponible enviando solicitudes de conexión inseguras y usando HSTS para los navegadores compatibles.

Tenga mucho cuidado con las vistas de marcado con el decorador csrf_exempt a menos que sea absolutamente necesario.

El middleware CSRF de Django y la etiqueta de plantilla proporcionan una protección fácil de usar contra las falsificaciones de solicitud de sitio cruzado.

La primera defensa contra ataques CSRF es asegurar que las solicitudes GET (y otros métodos “seguros”, tal como se definen en 9.1.1 Métodos seguros, HTTP 1.1, RFC 2616) tienen efecto secundario. Las peticiones a través de métodos “inseguros”, como POST, PUT y DELETE, pueden ser protegidas siguiendo los pasos a continuación.

Cómo usarlo

Para aprovechar la protección CSRF en sus vistas, siga estos pasos:

  1.     El middleware CSRF se activa de forma predeterminada en la configuración MIDDLEWARE_CLASSES. Si anula esa configuración, recuerde que ‘django.middleware.csrf.CsrfViewMiddleware’ debe aparecer antes de cualquier middleware de vista que asuma que los ataques CSRF han sido tratados. Si lo deshabilitó, lo que no se recomienda, puede utilizar csrf_protect () en determinadas vistas que desea proteger (ver más abajo).
  2.     En cualquier plantilla que utilice un formulario POST, utilice la etiqueta csrf_token dentro del elemento <form> si el formulario es para una URL interna, por ejemplo:     Esto no debería hacerse para los formularios POST que se dirigen a direcciones URL externas, ya que esto provocaría que se filtrase el token CSRF, dando lugar a una vulnerabilidad.
  3.      En las funciones de vista correspondientes, asegúrese de que se está utilizando el procesador de contexto ‘django.template.context_processors.csrf’. Por lo general, esto puede hacerse de dos maneras:
    1. Utilice RequestContext, que siempre utiliza ‘django.template.context_processors.csrf’ (sin importar qué procesadores de contexto de plantilla estén configurados en el ajuste TEMPLATES). Si está utilizando vistas genéricas o aplicaciones contrib, ya está cubierto ya, ya que estas aplicaciones utilizan RequestContext en todas partes.
    2. Importe manualmente y utilice el procesador para generar el token CSRF y agregarlo al contexto de la plantilla. p.ej.:Es posible que desee escribir su propio contenedor render_to_response () que se encargue de este paso para usted.

AJAX

Si bien el método anterior se puede utilizar para las solicitudes AJAX POST, tiene algunos inconvenientes: hay que recordar pasar el token CSRF como datos POST con cada solicitud POST. Por esta razón, existe un método alternativo: en cada XMLHttpRequest, establezca un encabezado personalizado de                 X-CSRFToken en el valor del token CSRF. Esto es a menudo más fácil, ya que muchos frameworks de JavaScript proporcionan ganchos que permiten que los encabezados se establezcan en cada solicitud.

Como primer paso, debe obtener el token CSRF en sí. La fuente recomendada para el token es la cookie csrftoken, que se establecerá si ha activado la protección CSRF para sus vistas, como se ha explicado anteriormente.

La cookie de token CSRF se denomina csrftoken de forma predeterminada, pero puede controlar el nombre de la cookie mediante la configuración CSRF_COOKIE_NAME.

Adquirir el token es sencillo:

El símbolo CSRF también está presente en el DOM, pero sólo si se incluye explícitamente utilizando csrf_token en una plantilla. La cookie contiene el token canónico; el CsrfViewMiddleware preferirá la cookie al token en el DOM. Independientemente, usted está garantizado para tener la cookie si el símbolo está presente en el DOM, por lo que debe utilizar la cookie!

 

Si su vista no está mostrando una plantilla que contenga la etiqueta de plantilla csrf_token, Django podría no establecer la cookie de token CSRF. Esto es común en los casos en que los formularios se añaden dinámicamente a la página. Para resolver este caso, Django proporciona un decorador de vistas que obliga a configurar la cookie: ensure_csrf_cookie ().

 

Finalmente, tendrás que configurar el encabezado en tu solicitud de AJAX, mientras proteges el token CSRF de ser enviado a otros dominios usando settings.crossDomain en jQuery 1.5.1 y versiones más recientes:

Otros motores de plantilla

Cuando se utiliza un motor de plantilla diferente al motor incorporado de Django, puede establecer el token en los formularios manualmente después de asegurarse de que está disponible en el contexto de la plantilla.

Por ejemplo, en el lenguaje de plantilla Jinja2, su formulario podría contener lo siguiente:

Puede utilizar JavaScript similar al código AJAX anterior para obtener el valor del token CSRF.

Referencia

Security in Django

Share: