Django
Sicherheit
Suche…
Cross Site Scripting (XSS) -Schutz
XSS-Angriffe bestehen darin, HTML-Code (oder JS-Code) in eine Seite einzufügen. Weitere Informationen finden Sie unter Was ist Cross Site Scripting .
Um diesen Angriff zu verhindern, entgeht Django standardmäßig Zeichenfolgen, die durch eine Vorlagenvariable übergeben werden.
In folgendem Zusammenhang:
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>
Wenn Sie Variablen haben, die HTML enthalten, denen Sie vertrauen und tatsächlich rendern möchten, müssen Sie ausdrücklich sagen, dass es sicher ist:
<p class="{{ class_name|safe }}">{{ paragraph }}</p>
<!-- Will be rendered as: -->
<p class="large" style="font-size: 4000px"><script>alert('hello world!');</script></p>
Wenn Sie einen Block mit mehreren Variablen haben, die alle sicher sind, können Sie die automatische Escape-Funktion lokal deaktivieren:
{% 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>
Sie können eine Zeichenfolge auch außerhalb der Vorlage als sicher markieren:
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>
Einige Django-Dienstprogramme wie format_html bereits als sicher markierte Zeichenfolgen zurück:
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>
Clickjacking-Schutz
Clickjacking ist eine bösartige Technik, bei der ein Webbenutzer dazu verleitet wird, auf etwas zu klicken, das sich von dem unterscheidet, was der Benutzer als er wahrnimmt. Mehr erfahren
Um den Clickjacking-Schutz zu aktivieren, fügen Sie die XFrameOptionsMiddleware Ihren Middleware-Klassen hinzu. Dies sollte bereits vorhanden sein, wenn Sie es nicht entfernt haben.
# settings.py
MIDDLEWARE_CLASSES = [
...
'django.middleware.clickjacking.XFrameOptionsMiddleware',
...
]
Diese Middleware setzt den 'X-Frame-Options'-Header auf alle Ihre Antworten, sofern nicht ausdrücklich freigestellt oder bereits festgelegt (nicht überschrieben, wenn in der Antwort bereits festgelegt). Standardmäßig ist "SAMEORIGIN" eingestellt. Um dies zu ändern, verwenden Sie die Einstellung X_FRAME_OPTIONS :
X_FRAME_OPTIONS = 'DENY'
Sie können das Standardverhalten für einzelne Ansichten überschreiben.
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) -Schutz
Cross-Site Request Forgery, auch als One-Click-Attack oder Session-Riding bezeichnet und als CSRF oder XSRF bezeichnet, ist eine bösartige Ausnutzung einer Website, bei der nicht autorisierte Befehle von einem Benutzer übertragen werden, dem die Website vertraut. Mehr erfahren
Um den CSRF-Schutz zu aktivieren, fügen Sie die CsrfViewMiddleware zu Ihren Middleware-Klassen hinzu. Diese Middleware ist standardmäßig aktiviert.
# settings.py
MIDDLEWARE_CLASSES = [
...
'django.middleware.csrf.CsrfViewMiddleware',
...
]
Diese Middleware setzt in der abgehenden Antwort ein Token in einem Cookie. Immer wenn eine eingehende Anforderung eine unsichere Methode verwendet (eine beliebige Methode außer GET , HEAD , OPTIONS und TRACE ), muss das Cookie einem Token entsprechen, das als csrfmiddlewaretoken Formulardaten oder als X-CsrfToken Header X-CsrfToken . Dadurch wird sichergestellt, dass der Client, der die Anforderung initiiert, auch der Eigentümer des Cookies und in der Folge die (authentifizierte) Sitzung ist.
Wenn eine Anforderung über HTTPS , ist die strikte Verweisprüfung aktiviert. Wenn der HTTP_REFERER Header nicht mit dem Host der aktuellen Anforderung oder einem Host in CSRF_TRUSTED_ORIGINS ( neu in 1.9 ) CSRF_TRUSTED_ORIGINS , wird die Anfrage abgelehnt.
Formulare, die die POST Methode verwenden, sollten das CSRF-Token in die Vorlage aufnehmen. Das Vorlagen-Tag {% csrf_token %} gibt ein ausgeblendetes Feld aus und stellt sicher, dass das Cookie für die Antwort festgelegt ist:
<form method='POST'>
{% csrf_token %}
...
</form>
Einzelne Ansichten, die nicht anfällig für CSRF-Angriffe sind, können mit dem Dekorator @csrf_exempt ausgenommen werden:
from django.views.decorators.csrf import csrf_exempt
@csrf_exempt
def my_view(request, *args, **kwargs):
"""Allows unsafe methods without CSRF protection"""
return HttpResponse(...)
Obwohl dies nicht empfohlen wird, können Sie CsrfViewMiddleware deaktivieren, wenn viele Ihrer Ansichten nicht anfällig für CSRF-Angriffe sind. In diesem Fall können Sie den @csrf_protect Dekorator verwenden, um einzelne Ansichten zu schützen:
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(...)