Django
Bezpieczeństwo

Ochrona przed skryptami krzyżowymi (XSS)

Ataki XSS polegają na wstrzykiwaniu kodu HTML (lub JS) na stronę. Aby uzyskać więcej informacji, zobacz Co to jest skrypty między witrynami .

Aby zapobiec temu atakowi, Django domyślnie unika ciągów znaków przechodzących przez zmienną szablonu.

Biorąc pod uwagę następujący kontekst:

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>

Jeśli masz zmienne zawierające HTML, którym ufasz i naprawdę chcesz renderować, musisz wyraźnie powiedzieć, że jest bezpieczny:

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

Jeśli masz blok zawierający wiele zmiennych, z których wszystkie są bezpieczne, możesz lokalnie wyłączyć automatyczne zmiany znaczenia:

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

Możesz również oznaczyć ciąg jako bezpieczny poza szablonem:

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>

Niektóre narzędzia Django, takie jak format_html już zwracają ciągi oznaczone jako bezpieczne:

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>

Ochrona przed kliknięciem

Clickjacking to złośliwa technika nakłaniania użytkownika sieci do kliknięcia na czymś innym niż to, co użytkownik postrzega jako klikający. Ucz się więcej

Aby włączyć ochronę przed XFrameOptionsMiddleware , dodaj XFrameOptionsMiddleware do swoich klas oprogramowania pośredniego. To powinno już tam być, jeśli go nie usunąłeś.

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

To oprogramowanie pośrednie ustawia nagłówek „Opcje X-Frame” dla wszystkich twoich odpowiedzi, chyba że jest wyraźnie zwolniony lub już ustawiony (nie zastępowany, jeśli jest już ustawiony w odpowiedzi). Domyślnie jest ustawiony na „SAMEORIGIN”. Aby to zmienić, użyj ustawienia X_FRAME_OPTIONS :

X_FRAME_OPTIONS = 'DENY'

Możesz zastąpić domyślne zachowanie dla poszczególnych wyświetleń.

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

Ochrona przed fałszowaniem żądań (CSRF)

Fałszowanie żądań między witrynami, znane również jako atak jednym kliknięciem lub jazda sesyjna, w skrócie CSRF lub XSRF, jest rodzajem złośliwego wykorzystania strony internetowej, w którym przesyłane są nieautoryzowane polecenia od użytkownika, któremu strona ta ufa. Ucz się więcej

Aby włączyć ochronę CSRF, dodaj CsrfViewMiddleware do swoich klas oprogramowania pośredniego. To oprogramowanie pośrednie jest domyślnie włączone.

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

To oprogramowanie pośrednie ustawi token w pliku cookie w odpowiedzi wychodzącej. Ilekroć w przychodzącym żądaniu jest wykorzystywana niebezpieczna metoda (dowolna metoda oprócz GET , HEAD , OPTIONS i TRACE ), plik cookie musi pasować do tokena, który jest wysyłany jako dane formularza csrfmiddlewaretoken lub jako nagłówek X-CsrfToken . Zapewnia to, że klient inicjujący żądanie jest również właścicielem pliku cookie, a co za tym idzie sesji (uwierzytelnionej).

Jeśli żądanie jest HTTPS przez HTTPS , włączone jest ścisłe sprawdzanie stron odsyłających. Jeśli nagłówek HTTP_REFERER nie pasuje do hosta bieżącego żądania lub hosta w CSRF_TRUSTED_ORIGINS ( nowość w wersji 1.9 ), żądanie zostanie odrzucone.

Formularze korzystające z metody POST powinny zawierać token CSRF w szablonie. Tag szablonu {% csrf_token %} wyświetli ukryte pole i zapewni, że plik cookie zostanie ustawiony w odpowiedzi:

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

Poszczególne widoki, które nie są podatne na ataki CSRF, można wyłączyć za pomocą dekoratora @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(...)

Chociaż nie jest to zalecane, możesz wyłączyć CsrfViewMiddleware jeśli wiele twoich widoków nie jest podatnych na ataki CSRF. W takim przypadku możesz użyć dekoratora @csrf_protect aby zabezpieczyć poszczególne widoki:

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