Sök…


Cross Site Scripting (XSS) skydd

XSS-attacker består i att injicera HTML (eller JS) -kod på en sida. Se Vad är cross site scripting för mer information.

För att förhindra detta angrepp undviker Django som standard strängar som passeras genom en mallvariabel.

Följande sammanhang:

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>

Om du har variabler som innehåller HTML som du litar på och faktiskt vill återge måste du uttryckligen säga att det är säkert:

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

Om du har ett block som innehåller flera variabler som alla är säkra kan du lokalt inaktivera automatisk undkommande:

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

Du kan också markera en sträng som säker utanför mallen:

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>

Vissa Django-verktyg som format_html redan strängar markerade som säkra:

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>

Clickjacking-skydd

Clickjacking är en skadlig teknik för att lura en webbanvändare att klicka på något annat än vad användaren uppfattar att de klickar på. Läs mer

Lägg till XFrameOptionsMiddleware i dina mellanvaruklasser för att aktivera klickjackskydd. Detta borde redan vara där om du inte tar bort det.

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

Det här mellanprogrammet sätter rubriken "X-Frame-Options" till alla dina svar, såvida inte uttryckligen undantas eller redan har ställts in (inte åsidosatt om det redan har ställts in i svaret). Som standard är den inställd på "SAMEORIGIN". För att ändra detta använder X_FRAME_OPTIONS inställningen X_FRAME_OPTIONS :

X_FRAME_OPTIONS = 'DENY'

Du kan åsidosätta standardbeteendet per visning.

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

Cross-site Request Forgery (CSRF) skydd

Förfalskning över flera webbplatser, även känd som en klickattack eller session ridning och förkortad CSRF eller XSRF, är en typ av skadlig exploatering av en webbplats där obehöriga kommandon överförs från en användare som webbplatsen litar på. Läs mer

För att aktivera CSRF-skydd lägger du till CsrfViewMiddleware i dina mellanvaruklasser. Det här mellanprogrammet är aktiverat som standard.

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

Det här mellanprogrammet ställer in ett symbol i en cookie på det utgående svaret. När en inkommande begäran använder en osäker metod (vilken metod som helst utom GET , HEAD , OPTIONS och TRACE ) måste cookien matcha ett token som skickas som csrfmiddlewaretoken eller som X-CsrfToken rubrik. Detta säkerställer att klienten som initierar förfrågan också är ägaren till cookien och i förlängningen den (autentiserade) sessionen.

Om en begäran görs via HTTPS , är strikt hänvisningskontroll aktiverad. Om HTTP_REFERER huvudet inte stämmer med värden för den aktuella begäran eller en värd i CSRF_TRUSTED_ORIGINS ( ny i 1.9 ) CSRF_TRUSTED_ORIGINS begäran.

Former som använder POST metoden bör inkludera CSRF-token i mallen. Mallen taggen {% csrf_token %} ger ett doldt fält och ser till att cookien är inställd på svaret:

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

Enskilda vyer som inte är sårbara för CSRF-attacker kan göras undantagna med @csrf_exempt dekoratören:

from django.views.decorators.csrf import csrf_exempt

@csrf_exempt
def my_view(request, *args, **kwargs):
    """Allows unsafe methods without CSRF protection"""
    return HttpResponse(...)

Även om det inte rekommenderas kan du inaktivera CsrfViewMiddleware om många av dina åsikter inte är sårbara för CSRF-attacker. I det här fallet kan du använda @csrf_protect dekoratören för att skydda enskilda vyer:

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


Modified text is an extract of the original Stack Overflow Documentation
Licensierat under CC BY-SA 3.0
Inte anslutet till Stack Overflow