Django
Sicurezza

Protezione Cross Site Scripting (XSS)

Gli attacchi XSS consistono nell'iniettare codice HTML (o JS) in una pagina. Vedi Che cos'è cross-site scripting per ulteriori informazioni.

Per evitare questo attacco, per impostazione predefinita, Django sfugge alle stringhe passate attraverso una variabile di modello.

Dato il seguente contesto:

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&quot; style=&quot;font-size: 4000px">&lt;script&gt;alert(&#39;hello world!&#39;);&lt;/script&gt;</p>

Se hai delle variabili contenenti HTML di cui ti fidi e in realtà vuoi eseguire il rendering, devi dire esplicitamente che è sicuro:

<p class="{{ class_name|safe }}">{{ paragraph }}</p>
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px">&lt;script&gt;alert(&#39;hello world!&#39;);&lt;/script&gt;</p>

Se hai un blocco contenente più variabili che sono tutte sicure, puoi disabilitare localmente l'escape automatico:

{% 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>

Puoi anche contrassegnare una stringa come sicura al di fuori del modello:

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&quot; style=&quot;font-size: 4000px"><script>alert('hello world!');</script></p>

Alcune utilità Django come format_html restituiscono già stringhe contrassegnate come sicure:

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> &lt;i&gt;world!&lt;/i&gt;</p>

Protezione da Clickjacking

Il clickjacking è una tecnica dannosa di ingannare un utente Web per fare clic su qualcosa di diverso da ciò che l'utente percepisce su cui sta facendo clic. Per saperne di più

Per abilitare la protezione da clickjacking, aggiungi XFrameOptionsMiddleware alle tue classi middleware. Questo dovrebbe già essere lì se non lo hai rimosso.

# settings.py
MIDDLEWARE_CLASSES = [
    ...
    'django.middleware.clickjacking.XFrameOptionsMiddleware',
    ...
]

Questo middleware imposta l'intestazione 'X-Frame-Options' su tutte le tue risposte, a meno che non sia esplicitamente esentato o impostato (non sovrascritto se già impostato nella risposta). Di default è impostato su "SAMEORIGIN". Per cambiare questo, usa l'impostazione X_FRAME_OPTIONS :

X_FRAME_OPTIONS = 'DENY'

È possibile sovrascrivere il comportamento predefinito su base per visualizzazione.

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.
    """

Protezione da richiesta di cross-site Forgery (CSRF)

La falsificazione della richiesta tra siti, anche nota come attacco con un clic o sessione in corso e abbreviata come CSRF o XSRF, è un tipo di exploit dannoso di un sito Web in cui vengono trasmessi comandi non autorizzati da un utente ritenuto affidabile dal sito Web. Per saperne di più

Per abilitare la protezione CSRF, aggiungi CsrfViewMiddleware alle tue classi middleware. Questo middleware è abilitato per impostazione predefinita.

# settings.py
MIDDLEWARE_CLASSES = [
    ...
    'django.middleware.csrf.CsrfViewMiddleware',
    ...
]

Questo middleware imposterà un token in un cookie sulla risposta in uscita. Ogni volta che una richiesta in entrata utilizza un metodo non sicuro (qualsiasi metodo tranne GET , HEAD , OPTIONS e TRACE ), il cookie deve corrispondere a un token che viene inviato come dati del modulo csrfmiddlewaretoken o come intestazione X-CsrfToken . Ciò garantisce che il client che avvia la richiesta sia anche il proprietario del cookie e, per estensione, la sessione (autenticata).

Se viene eseguita una richiesta su HTTPS , il controllo referrer rigoroso è abilitato. Se l'intestazione HTTP_REFERER non corrisponde all'host della richiesta corrente o di un host in CSRF_TRUSTED_ORIGINS ( novità in 1.9 ), la richiesta viene respinta.

I moduli che utilizzano il metodo POST devono includere il token CSRF nel modello. Il tag del modello {% csrf_token %} un campo nascosto e garantisce che il cookie sia impostato sulla risposta:

<form method='POST'>
{% csrf_token %}
...
</form>

Le singole viste che non sono vulnerabili agli attacchi CSRF possono essere rese esenti utilizzando il decoratore @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(...)

Sebbene non sia raccomandato, è possibile disabilitare CsrfViewMiddleware se molte delle viste non sono vulnerabili agli attacchi CSRF. In questo caso puoi utilizzare il decoratore @csrf_protect per proteggere le singole visualizzazioni:

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(...)