Django
Seguridad
Buscar..
Protección de Cross Site Scripting (XSS)
Los ataques XSS consisten en inyectar código HTML (o JS) en una página. Consulte Qué es el script de sitios cruzados para obtener más información.
Para evitar este ataque, de forma predeterminada, Django escapa las cadenas que pasan a través de una variable de plantilla.
Dado el siguiente contexto:
context = {
'class_name': 'large" style="font-size:4000px',
'paragraph': (
"<script type=\"text/javascript\">alert('hello world!');</script>"),
}
<p class="{{ class_name }}">{{ paragraph }}</p>
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px"><script>alert('hello world!');</script></p>
Si tiene variables que contienen HTML en las que confía y que realmente desea representar, debe decir explícitamente que es seguro:
<p class="{{ class_name|safe }}">{{ paragraph }}</p>
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px"><script>alert('hello world!');</script></p>
Si tiene un bloque que contiene varias variables que son seguras, puede deshabilitar el escape automático localmente:
{% autoescape off %}
<p class="{{ class_name }}">{{ paragraph }}</p>
{% endautoescape %}
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px"><script>alert('hello world!');</script></p>
También puede marcar una cadena como segura fuera de la plantilla:
from django.utils.safestring import mark_safe
context = {
'class_name': 'large" style="font-size:4000px',
'paragraph': mark_safe(
"<script type=\"text/javascript\">alert('hello world!');</script>"),
}
<p class="{{ class_name }}">{{ paragraph }}</p>
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px"><script>alert('hello world!');</script></p>
Algunas utilidades de Django como format_html
ya devuelven cadenas marcadas como seguras:
from django.utils.html import format_html
context = {
'var': format_html('<b>{}</b> {}', 'hello', '<i>world!</i>'),
}
<p>{{ var }}</p>
<!-- Will be rendered as -->
<p><b>hello</b> <i>world!</i></p>
Protección de clickjacking
Clickjacking es una técnica maliciosa de engañar a un usuario de la Web para que haga clic en algo diferente de lo que el usuario percibe que está haciendo clic. Aprende más
Para habilitar la protección de clickjacking, agregue XFrameOptionsMiddleware
a sus clases de middleware. Esto ya debería estar allí si no lo eliminaste.
# settings.py
MIDDLEWARE_CLASSES = [
...
'django.middleware.clickjacking.XFrameOptionsMiddleware',
...
]
Este middleware establece el encabezado 'X-Frame-Options' en todas sus respuestas, a menos que esté explícitamente exento o ya establecido (no se invalida si ya está establecido en la respuesta). De forma predeterminada, se establece en "SAMEORIGIN". Para cambiar esto, use la configuración X_FRAME_OPTIONS
:
X_FRAME_OPTIONS = 'DENY'
Puede anular el comportamiento predeterminado por vista.
from django.utils.decorators import method_decorator
from django.views.decorators.clickjacking import (
xframe_options_exempt, xframe_options_deny, xframe_options_sameorigin,
)
xframe_options_exempt_m = method_decorator(xframe_options_exempt, name='dispatch')
@xframe_options_sameorigin
def my_view(request, *args, **kwargs):
"""Forces 'X-Frame-Options: SAMEORIGIN'."""
return HttpResponse(...)
@method_decorator(xframe_options_deny, name='dispatch')
class MyView(View):
"""Forces 'X-Frame-Options: DENY'."""
@xframe_options_exempt_m
class MyView(View):
"""Does not set 'X-Frame-Options' header when passing through the
XFrameOptionsMiddleware.
"""
Protección de falsificación de solicitudes entre sitios (CSRF)
La falsificación de solicitudes entre sitios, también conocida como ataque con un solo clic o sesión montada y abreviada como CSRF o XSRF, es un tipo de vulnerabilidad malintencionada de un sitio web donde se transmiten comandos no autorizados de un usuario en el que el sitio confía. Aprende más
Para habilitar la protección CSRF, agregue CsrfViewMiddleware
a sus clases de middleware. Este middleware está habilitado por defecto.
# settings.py
MIDDLEWARE_CLASSES = [
...
'django.middleware.csrf.CsrfViewMiddleware',
...
]
Este middleware establecerá un token en una cookie en la respuesta saliente. Cuando una solicitud entrante utiliza un método inseguro (cualquier método excepto GET
, HEAD
, OPTIONS
y TRACE
), la cookie debe coincidir con un token que se envía como datos de formulario csrfmiddlewaretoken
o como encabezado X-CsrfToken
. Esto garantiza que el cliente que inicia la solicitud también es el propietario de la cookie y, por extensión, la sesión (autenticada).
Si se realiza una solicitud a través de HTTPS
, se habilita la comprobación estricta de referencias. Si el encabezado HTTP_REFERER
no coincide con el host de la solicitud actual o con un host en CSRF_TRUSTED_ORIGINS
( nuevo en 1.9 ), se deniega la solicitud.
Los formularios que utilizan el método POST
deben incluir el token CSRF en la plantilla. La etiqueta de plantilla {% csrf_token %}
generará un campo oculto y garantizará que la cookie esté configurada en la respuesta:
<form method='POST'>
{% csrf_token %}
...
</form>
Las vistas individuales que no son vulnerables a los ataques CSRF pueden quedar exentas utilizando el decorador @csrf_exempt
:
from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def my_view(request, *args, **kwargs):
"""Allows unsafe methods without CSRF protection"""
return HttpResponse(...)
Aunque no se recomienda, puede deshabilitar CsrfViewMiddleware
si muchas de sus vistas no son vulnerables a los ataques CSRF. En este caso, puede utilizar el decorador @csrf_protect
para proteger las vistas individuales:
from django.views.decorators.csrf import csrf_protect
@csrf_protect
def my_view(request, *args, **kwargs):
"""This view is protected against CSRF attacks if the middleware is disabled"""
return HttpResponse(...)