• Django 문서확인

다음과 같은 경우에도 서명이 유용할 수 있습니다.

• 직렬화 된 데이터 서명
• 비밀번호를 분실한 사용자에게 보낼 “내 계정 복구” URL 생성.
• 숨겨진 양식 필드에 저장된 데이터가 변조되지 않았는지 확인합니다.
• 보호된 리소스(예: 사용자가 비용을 지불한 다운로드 가능한 파일)에 대한 임시 액세스를 허용하기 위해 일회성 비밀 URL을 생성합니다.

settings.py

SECRET_KEY = 'HelloMySampleSecretKey'

command에서 테스트하기

python:.sh

import os
from django.core.signing import Signer, TimestampSigner
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'settings')
 
signer = Signer()
value = signer.sign("My String.")
signer.unsign(value)

서명은 콜론 다음에 오는 문자열 끝에 추가됩니다. 다음 unsign방법을 사용하여 원래 값을 검색할 수 있습니다 .

XSS 공격을 통해 사용자는 클라이언트 측 스크립트를 다른 사용자의 브라우저에 삽입할 수 있습니다. 이것은 일반적으로 악성 스크립트를 검색하여 다른 사용자에게 표시할 데이터베이스에 저장하거나 사용자가 링크를 클릭하도록 하여 공격자의 JavaScript가 사용자의 브라우저에서 실행되도록 함으로써 달성됩니다. 그러나 XSS 공격은 데이터가 페이지에 포함되기 전에 충분히 삭제되지 않을 때마다 쿠키 또는 웹 서비스와 같은 신뢰할 수 없는 데이터 소스에서 시작될 수 있습니다.

Django 템플릿을 사용하면 대부분의 XSS 공격으로부터 사용자를 보호할 수 있습니다. 그러나 제공하는 보호 기능과 제한 사항을 이해하는 것이 중요합니다.

Django 템플릿 은 HTML에 특히 위험한 특정 문자를 이스케이프합니다 . 이것은 대부분의 악의적인 입력으로부터 사용자를 보호하지만 완전히 안전한 것은 아닙니다. 예를 들어 다음을 보호하지 않습니다.

<style class={{ var }}>...</style>

경우 var로 설정되어 ,이 브라우저가 불완전한 HTML 렌더링 방식에 따라, 무단 자바 스크립트 실행이 발생할 수 있습니다. (속성 값을 인용하면 이 경우가 해결됩니다.)'class1 onmouseover=javascript:func()'

또한 is_safe사용자 정의 템플릿 태그, safe템플릿 태그 mark_safe및 자동 이스케이프가 꺼져 있을 때 사용할 때 특히 주의하는 것이 중요합니다 .

또한 템플릿 시스템을 사용하여 HTML 이외의 것을 출력하는 경우 이스케이프가 필요한 완전히 별도의 문자와 단어가 있을 수 있습니다.

또한 HTML을 데이터베이스에 저장할 때, 특히 해당 HTML이 검색 및 표시될 때 매우 주의해야 합니다.

CSRF 공격을 통해 악의적인 사용자는 해당 사용자가 알지 못하거나 동의하지 않고 다른 사용자의 자격 증명을 사용하여 작업을 실행할 수 있습니다.

Django에는 대부분의 CSRF 공격 유형에 대한 보호 기능이 내장 되어 있으며 적절한 경우 이를 활성화하고 사용합니다 . 그러나 모든 완화 기술과 마찬가지로 제한 사항이 있습니다. 예를 들어 CSRF 모듈을 전역적으로 또는 특정 보기에 대해 비활성화할 수 있습니다. 수행 중인 작업을 알고 있는 경우에만 이 작업을 수행해야 합니다. 사이트에 제어할 수 없는 하위 도메인이 있는 경우 다른 제한 사항 이 있습니다.

CSRF 보호는 각 POST 요청에서 비밀을 확인하여 작동합니다 . 이렇게 하면 악의적인 사용자가 웹사이트에 POST 양식을 단순히 “재생”할 수 없으며 로그인한 다른 사용자가 무의식적으로 해당 양식을 제출하도록 할 수 있습니다. 악의적인 사용자는 사용자 고유의 비밀(쿠키 사용)을 알아야 합니다.

함께 배포하면 HTTPS , CsrfViewMiddleware는 HTTP 리퍼러 헤더 (하위 도메인 및 포트 포함) 같은 기원에서 URL로 설정되어 있는지 확인합니다. HTTPS는 추가 보안을 제공하므로 안전하지 않은 연결 요청을 전달하고 지원되는 브라우저에 HSTS를 사용하여 HTTPS가 사용 가능한 경우 연결이 HTTPS를 사용하도록 해야 합니다.

꼭 csrf_exempt필요한 경우가 아니면 데코레이터로 뷰를 표시할 때 매우 주의하십시오.

SQL 인젝션은 악의적인 사용자가 데이터베이스에서 임의의 SQL 코드를 실행할 수 있는 공격 유형입니다. 이로 인해 기록이 삭제되거나 데이터가 유출될 수 있습니다.

Django의 쿼리 세트는 쿼리 매개변수화를 사용하여 쿼리를 구성하기 때문에 SQL 주입으로부터 보호됩니다. 쿼리의 SQL 코드는 쿼리의 매개변수와 별도로 정의됩니다. 매개변수는 사용자가 제공하여 안전하지 않을 수 있으므로 기본 데이터베이스 드라이버에 의해 이스케이프됩니다.

Django는 또한 개발자에게 원시 쿼리 를 작성 하거나 사용자 지정 SQL을 실행할 수 있는 권한을 제공합니다 . 이러한 기능은 드물게 사용해야 하며 사용자가 제어할 수 있는 매개변수를 적절하게 이스케이프하도록 항상 주의해야 합니다. 또한 extra() 및 를 사용할 때 주의해야 합니다 RawSQL.

클릭재킹은 악성 사이트가 다른 사이트를 프레임으로 감싸는 공격 유형입니다. 이 공격으로 인해 순진한 사용자가 대상 사이트에서 의도하지 않은 작업을 수행하도록 속일 수 있습니다.

Django에는 지원 브라우저에서 사이트가 프레임 내부에서 렌더링되는 것을 방지할 수 있는 형태의 클릭재킹 방지 기능이 포함되어 있습니다 . 보기별로 보호를 비활성화하거나 전송된 정확한 헤더 값을 구성할 수 있습니다.X-Frame-Options middleware

미들웨어는 타사 사이트에서 프레임에 페이지를 래핑할 필요가 없거나 사이트의 작은 섹션에 대해서만 허용해야 하는 모든 사이트에 강력히 권장됩니다.

HTTPS 뒤에 사이트를 배포하는 것이 보안을 위해 항상 더 좋습니다. 이것이 없으면 악의적인 네트워크 사용자가 인증 자격 증명 또는 클라이언트와 서버 간에 전송되는 기타 정보를 스니핑할 수 있으며 경우에 따라 활성 네트워크 공격자가 양방향으로 전송되는 데이터를 변경할 수 있습니다.

HTTPS가 제공하는 보호를 원하고 서버에서 활성화한 경우 몇 가지 추가 단계가 필요할 수 있습니다.

필요한 경우 를 설정 SECURE_PROXY_SSL_HEADER하여 거기에 있는 경고를 완전히 이해했는지 확인합니다. 이렇게 하지 않으면 CSRF 취약성이 발생할 수 있으며 올바르게 하지 않으면 위험할 수도 있습니다!

HTTP를 통한 요청이 HTTPS로 리디렉션되도록 로 설정 SECURE_SSL_REDIRECT합니다 True.

아래의 주의사항에 유의하십시오 SECURE_PROXY_SSL_HEADER. 역방향 프록시의 경우 HTTPS로 리디렉션하도록 기본 웹 서버를 구성하는 것이 더 쉽거나 더 안전할 수 있습니다.

브라우저가 초기에 대부분의 브라우저의 기본값인 HTTP를 통해 연결하는 경우 기존 쿠키가 누출될 수 있습니다. 이러한 이유로 SESSION_COOKIE_SECURE및 CSRF_COOKIE_SECURE설정을 로 설정해야 True합니다. 이것은 브라우저가 HTTPS 연결을 통해서만 이러한 쿠키를 보내도록 지시합니다. 이것은 세션이 HTTP를 통해 작동하지 않으며 CSRF 보호가 HTTP를 통해 수락되는 POST 데이터를 방지함을 의미합니다(모든 HTTP 트래픽을 HTTPS로 리디렉션하는 경우 괜찮음).

HSTS는 특정 사이트에 대한 모든 향후 연결이 항상 HTTPS를 사용해야 함을 브라우저에 알리는 HTTP 헤더입니다. HTTP를 통한 요청을 HTTPS로 리디렉션하는 것과 결합하면 하나의 성공적인 연결이 발생한 경우 연결이 항상 SSL의 추가 보안을 누릴 수 있습니다. HSTS는 SECURE_HSTS_SECONDS, SECURE_HSTS_INCLUDE_SUBDOMAINS, 및 로 구성 SECURE_HSTS_PRELOAD하거나 웹 서버에서 구성할 수 있습니다 .

Django는 Host특정 경우에 URL을 구성하기 위해 클라이언트가 제공한 헤더를 사용합니다 . 이러한 값은 Cross Site Scripting 공격을 방지하기 위해 삭제되지만, 가짜 Host값은 Cross-Site Request Forgery, 캐시 포이즈닝 공격 및 이메일의 링크 포이즈닝에 사용될 수 있습니다.

겉보기에 안전한 웹 서버 구성이라도 가짜 Host헤더에 취약하기 때문에 Django 는 메서드 Host의 ALLOWED_HOSTS설정에 대해 헤더의 유효성을 검사 합니다 django.http.HttpRequest.get_host().

이 유효성 검사는 다음을 통해서만 적용됩니다 get_host(). 코드가 Host헤더에 직접 액세스하면 request.META이 보안 보호를 우회하는 것입니다.

자세한 내용은 전체 ALLOWED_HOSTS문서를 참조하십시오 .

경고 <info> 이 문서의 이전 버전에서는 들어오는 HTTP Host헤더의 유효성을 검사하도록 웹 서버를 구성할 것을 권장했습니다 . 이것이 여전히 권장되지만 많은 일반 웹 서버에서 Host헤더의 유효성을 검사하는 것처럼 보이는 구성이 실제로는 그렇지 않을 수 있습니다. 예를 들어, Django 사이트가 기본이 아닌 가상 호스트에서 제공되도록 Apache를 구성한 경우에도 ServerNameHTTP 요청이 이 가상 호스트와 일치하고 가짜 Host헤더를 제공할 수 있습니다. 따라서 Django는 이제 ALLOWED_HOSTS웹 서버 구성에 의존하지 않고 명시적으로 설정해야 합니다. </info>

또한 Django는 구성에 필요한 경우 X-Forwarded-Host헤더에 대한 지원을 명시적으로 활성화해야 합니다 ( USE_X_FORWARDED_HOST설정을 통해 ).

신뢰할 수 없는 사용자가 하위 도메인에 액세스할 수 없도록 사이트를 배포해야 하는 CSRF 제한 사항과 유사하게 제한 사항django.contrib.sessions 도 있습니다. 자세한 내용 은 보안에 대한 세션 주제 가이드 섹션 을 참조하십시오.

메모

고려 클라우드 서비스 나 CDN에서 정적 파일을 제공하는 이러한 문제 중 일부를 피하기 위해. 사이트에서 파일 업로드를 허용하는 경우 DOS(서비스 거부) 공격을 방지하기 위해 웹 서버 구성에서 이러한 업로드를 적절한 크기로 제한하는 것이 좋습니다. Apache에서는 LimitRequestBody 지시문을 사용하여 쉽게 설정할 수 있습니다 .

자신의 정적 파일을 제공하는 경우 mod_php정적 파일을 코드로 실행하는 Apache와 같은 핸들러 가 비활성화되어 있는지 확인하십시오 . 사용자가 특수하게 조작된 파일을 업로드 및 요청하여 임의의 코드를 실행할 수 없도록 하고 싶습니다.

Django의 미디어 업로드 처리는 해당 미디어가 보안 모범 사례를 따르지 않는 방식으로 제공될 때 몇 가지 취약성을 나타냅니다. 특히 HTML 파일에 유효한 PNG 헤더 뒤에 악성 HTML이 포함된 경우 HTML 파일을 이미지로 업로드할 수 있습니다. 이 파일은 Django가 ImageField이미지 처리에 사용하는 라이브러리 (Pillow)의 확인을 통과합니다 . 이 파일이 이후에 사용자에게 표시될 때 웹 서버의 유형 및 구성에 따라 HTML로 표시될 수 있습니다.

프레임워크 수준에는 사용자가 업로드한 모든 파일 콘텐츠를 안전하게 검증할 수 있는 완벽한 기술 솔루션이 없지만 이러한 공격을 완화하기 위해 취할 수 있는 몇 가지 다른 단계가 있습니다.

한 가지 유형의 공격은 별개의 최상위 또는 두 번째 수준 도메인에서 사용자가 업로드한 콘텐츠를 항상 제공하여 방지할 수 있습니다. 이렇게 하면 사이트 간 스크립팅과 같은 동일 출처 정책 보호에 의해 차단된 모든 악용이 방지 됩니다. 예를 들어 사이트가 에서 실행되는 경우 에서 example.com업로드된 콘텐츠( MEDIA_URL설정)를 제공할 수 usercontent-example.com있습니다. 그건 하지 같은 하위 도메인에서 콘텐츠를 제공하기에 충분 usercontent.example.com. 이 외에도 애플리케이션은 사용자가 업로드한 파일에 대해 허용되는 파일 확장자의 화이트리스트를 정의하고 이러한 파일만 제공하도록 웹 서버를 구성하도록 선택할 수 있습니다.

Django는 기본적으로 우수한 보안 보호 기능을 제공하지만 애플리케이션을 적절하게 배포하고 웹 서버, 운영 체제 및 기타 구성 요소의 보안 보호 기능을 활용하는 것이 여전히 중요합니다.

• Python코드가 웹 서버의 루트 외부에 있는지 확인하십시오. 이렇게 하면 Python 코드가 실수로 일반 텍스트로 제공되지 않거나 실수로 실행되지 않습니다.
• 사용자가 업로드한 파일에 주의 하십시오.
• Django는 사용자 인증 요청을 조절하지 않습니다. 인증 시스템에 대한 무차별 대입 공격으로부터 보호하기 위해 Django 플러그인 또는 웹 서버 모듈을 배포하여 이러한 요청을 제한할 수 있습니다.
• SECRET_KEY비밀을 지켜주세요.
• 방화벽을 사용하여 캐싱 시스템 및 데이터베이스의 액세스 가능성을 제한하는 것이 좋습니다.
• 웹 애플리케이션의 몇 가지 일반적인 취약점을 식별하는 OWASP(Open Web Application Security Project) 상위 10개 목록 을 살펴보십시오 . Django에는 일부 문제를 해결할 수 있는 도구가 있지만 프로젝트 설계 시 다른 문제를 고려해야 합니다.