장고 웹사이트 해킹

Django 문서에서는 SecurityMiddleware이 귀하의 MIDDLEWARE 설정의 맨 위에 위치한다고 제안하는데, 그 이유는 다음과 같습니다. 보안 검사 및 개선 사항을 수행하여 웹사이트를 간단한 해킹에 맡기는 것입니다.

Django 보안 도전에 대한 준비가 되셨습니까? 재생 우리 Django security challenge .

X-콘텐츠 유형 옵션

SecurityMiddleware는 X-Content-Type-Options 헤더를 nosniff로 설정하여 해커가 웹사이트를 속여 업로드한 악성 자바스크립트 파일을 실행하지 못하도록 합니다.

이 헤더는 Content-Type 헤더에 광고된 MIME 유형이 변경되지 않아야 함을 브라우저에 나타냅니다(콘텐츠 "스니핑"). 스니핑 기능은 개발자 또는 서버 구성 오류가 Content-Type를 잘못 식별할 때 도움이 되는 브라우저입니다. 브라우저가 잘못된 MIME 유형을 존중하면 javascript, css 또는 이미지 파일이 작동하지 않고 웹 사이트가 중단됩니다. 매우 유용한 기능입니다. 그러나 다음과 같은 간단한 개념 증명에서 볼 수 있듯이 남용될 수 있습니다.

# settings.py
MIDDLEWARE = [
    # "django.middleware.security.SecurityMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    ...
]

SECURE_CONTENT_TYPE_NOSNIFF = False  # pre-Django 3.0 it was False by default. Post 3.0 it's True

# views.py
class HomePage(View):
    def get(self, *args, **kwargs):
        # simulate a misconfgured server that returns a response that has no content type
        response = HttpResponse("<script>alert('hello world')</script>")
        del response['Content-Type']
        return response

HomePage로 이동했을 때의 결과는 "해킹"이 작동했음을 보여줍니다.



이 간단한 개념 증명은 다음과 같은 보다 복잡한 상황을 시뮬레이션했습니다.

악의적인 행위자가 javascript가 포함된 HTML을 업로드했습니다(아마도 이미지 파일인 척).

웹 사이트에서 파일을 제공했지만 Content-Type 헤더에 MIME 유형을 설정하지 않음

브라우저가 콘텐츠를 기반으로 MIME 유형을 유추했습니다

.

브라우저가 javascript를 실행했습니다

.
SecurityMiddleware가 있고 nosniff 기능이 활성화된 경우 이를 피할 수 있습니다.

# settings.py
MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.common.CommonMiddleware",
    "django.contrib.sessions.middleware.SessionMiddleware",
    ...
]

SECURE_CONTENT_TYPE_NOSNIFF = True

그러면 브라우저는 속임수에 넘어가지 않습니다.

X-XSS-보호

SecurityMiddleware는 X-XSS-Protection가 1; mode=block인 경우 SECURE_BROWSER_XSS_FILTER 헤더를 True로 설정하여 브라우저의 기본 제공 XSS 보호를 활성화합니다.

이 XSS 보호는 대부분 CSP으로 대체되었습니다. 이전 브라우저는 여전히 이 기능을 지원하지만 많은 브라우저에서 이 기능을 제거했습니다. 웹사이트의 보안이 모든 사람이 최신 버전의 Chrome을 실행하고 있다고 가정할 수 없기 때문에 이전 브라우저를 사용하는 사용자는 여전히 수용해야 합니다.
SecurityMiddleware 및 SECURE_BROWSER_XSS_FILTER가 없으면 웹 사이트는 many possible XSS attacks로부터 보호되는 혜택을 받을 수 없습니다.

추천인 정책

SecurityMiddleware는 SECURE_REFERRER_POLICY를 기반으로 리퍼러 정책 헤더를 설정합니다. 이 헤더는 impacts user privacy 사용자를 속여 웹 사이트에 있다고 생각하도록 속이는 것을 목표로 하는 악의적인 행위자에 대한 공격 벡터입니다.

리퍼러 헤더는 대상 웹사이트에서 남용될 수 있습니다. 웹사이트 URL의 비밀이 유출될 수 있습니다. 좀 더 복잡한 것은 악의적인 행위자가 자신의 웹사이트에 링크를 추가할 수 있다는 것입니다. 그런 다음 대상은 리퍼러 헤더를 읽고 자신의 웹사이트가 귀하의 웹사이트처럼 보이도록 스타일을 지정할 수 있습니다. 주의를 기울이지 않는 사용자는 다음과 같은 이유로 여전히 웹사이트에 있다고 생각할 수 있습니다.

연결된 웹사이트

귀하의 웹사이트

와 같습니다.

따라서 사용자는 악의적인 행위자의 웹사이트에 자격 증명과 개인 정보를 입력할 수 있습니다.

이는 SECURE_REFERRER_POLICY 설정에 의해 리퍼러 헤더를 노출하지 않음으로써 방지할 수 있으며, 이는 SecurityMiddleware에 의해 처리됩니다.

클릭재킹

보다

교차 사이트 요청 위조

보다

SSL 리디렉션

SecurityMiddleware는 SECURE_SSL_REDIRECT가 True로 설정된 경우 HTTP 연결을 HTTPS로 리디렉션할 수 있습니다.

HTTP를 HTTPS로 리디렉션하지 않으면 암호와 개인 정보가 일반 텍스트를 통해 전송되고 Man In The Middle에서 읽을 수 있습니다.

보다

웹사이트에 보안 취약점이 있습니까?

시간이 지남에 따라 보안 취약성과 기술 부채가 코드베이스에 쉽게 침투할 수 있습니다. django.doctor에서 확인하거나 review your GitHub PRs에서 확인할 수 있습니다.



또는 시도해 보십시오Django refactor challenges .