このドキュメントは Django のセキュリティ機能について概要をまとめた物です。この中には Django を利用したサイトを安全な物にするためのアドバイスが含まれています。
\nXSS 攻撃はあるユーザーに対してクライアント用のスクリプトを別のユーザーのブラウザに読み込ませる事を可能にしてしまいます。この攻撃は通常他のユーザーに対して選択・表示を行うデータベース内に悪意のあるスクリプトを保存させる、あるいは攻撃者の JavaScript がブラウザで実行されるリンクをユーザーにクリックさせることでなされます。しかしながら、XSS 攻撃はページを読み込む前に十分なサニタイズを行っていなければ、信頼できないクッキーやウェブ・サービスのようなデータが発生の原因となることが有ります。
\nDjango のテンプレートを用いる事で多数の XSS 攻撃に対抗することができます。しかしながら、それがどのような防御策が用意でき、またその利用に際する制限について知ることが重要になります。
\nDjango は HTML に対して特に危険とみなされる 特定の文字列のエスケープ を行います。この防御によってユーザーは大半の悪意のある入力から守られますが、いつも簡単で容易に利用できる訳ではありません。例えば、次に示す例では防御がなされません:
\n<style class={{ var }}>...</style>\nもし var の値が 'class1 onmouseover=javascript:func()' にセットされた場合、不完全な HTML をそのブラウザがどのようにレンダリングするかによっては、許可されていない Javascript を実行させる事になります。(このケースであれば属性値のクオートを行えば対処できます)
カスタム・テンプレート・タグと共に ``is_safe``を用いたり、safe テンプレートタグや、mark_safe の利用に加えてオートエスケープが無効化されている場合十分な注意を払う必要が有ります。
ここまでの内容に加えて、HTML 以外を出力するのにテンプレートシステムを利用している場合、完全に別のエスケープすべき文字や単語が存在するかもしれません。
\nHTML をデータベース内に収集、特にその HTML が選択・表示される場合は十分な注意を払う必要が有ります。
\nCSRF 攻撃は悪意ある利用者が、あるユーザーが自身で持っている情報や承認を用いずに、そのユーザーの認証情報での処理を発生させてしまう攻撃です。
\nDjango は大半の CSRF 攻撃に対応したビルトインの防御機構を備え、適切な所で:ref:有効化して利用できます <using-csrf>。しかしながら、いかなる緩和策にも制限が存在します。例えば、CSRF モジュールをグローバルにあるいは特定のビューだけ無効化できます。これは自身が何をしているのか理解している場合のみ行うべきです。もしあなたのサイト内に管理対象外のサブドメインが存在すればそこにも:ref:`制限 <csrf-limitations>`が存在します。
\nCSRF protection works by checking for a secret in each\nPOST request. This ensures that a malicious user cannot simply "replay" a form\nPOST to your website and have another logged in user unwittingly submit that\nform. The malicious user would have to know the secret, which is user specific\n(using a cookie).
\nWhen deployed with HTTPS,\nCsrfViewMiddleware will check that the HTTP referer header is set to a\nURL on the same origin (including subdomain and port). Because HTTPS\nprovides additional security, it is imperative to ensure connections use HTTPS\nwhere it is available by forwarding insecure connection requests and using\nHSTS for supported browsers.
Be very careful with marking views with the csrf_exempt decorator unless\nit is absolutely necessary.
SQL injection is a type of attack where a malicious user is able to execute\narbitrary SQL code on a database. This can result in records\nbeing deleted or data leakage.
\nBy using Django's querysets, the resulting SQL will be properly escaped by\nthe underlying database driver. However, Django also gives developers power to\nwrite raw queries or execute\ncustom sql. These capabilities should be used\nsparingly and you should always be careful to properly escape any parameters\nthat the user can control. In addition, you should exercise caution when using\nextra() and\nRawSQL.
Clickjacking is a type of attack where a malicious site wraps another site\nin a frame. This attack can result in an unsuspecting user being tricked\ninto performing unintended actions on the target site.
\nDjango contains clickjacking protection in\nthe form of the\nX-Frame-Options middleware\nwhich in a supporting browser can prevent a site from being rendered inside\na frame. It is possible to disable the protection on a per view basis\nor to configure the exact header value sent.
The middleware is strongly recommended for any site that does not need to have\nits pages wrapped in a frame by third party sites, or only needs to allow that\nfor a small section of the site.
\nIt is always better for security to deploy your site behind HTTPS. Without\nthis, it is possible for malicious network users to sniff authentication\ncredentials or any other information transferred between client and server, and\nin some cases -- active network attackers -- to alter data that is sent in\neither direction.
\nIf you want the protection that HTTPS provides, and have enabled it on your\nserver, there are some additional steps you may need:
\nIf necessary, set SECURE_PROXY_SSL_HEADER, ensuring that you have\nunderstood the warnings there thoroughly. Failure to do this can result\nin CSRF vulnerabilities, and failure to do it correctly can also be\ndangerous!
Set SECURE_SSL_REDIRECT to True, so that requests over HTTP\nare redirected to HTTPS.
Please note the caveats under SECURE_PROXY_SSL_HEADER. For the\ncase of a reverse proxy, it may be easier or more secure to configure the\nmain Web server to do the redirect to HTTPS.
Use 'secure' cookies.
\nIf a browser connects initially via HTTP, which is the default for most\nbrowsers, it is possible for existing cookies to be leaked. For this reason,\nyou should set your SESSION_COOKIE_SECURE and\nCSRF_COOKIE_SECURE settings to True. This instructs the browser\nto only send these cookies over HTTPS connections. Note that this will mean\nthat sessions will not work over HTTP, and the CSRF protection will prevent\nany POST data being accepted over HTTP (which will be fine if you are\nredirecting all HTTP traffic to HTTPS).
Use HTTP Strict Transport Security (HSTS)
\nHSTS is an HTTP header that informs a browser that all future connections\nto a particular site should always use HTTPS. Combined with redirecting\nrequests over HTTP to HTTPS, this will ensure that connections always enjoy\nthe added security of SSL provided one successful connection has occurred.\nHSTS may either be configured with SECURE_HSTS_SECONDS and\nSECURE_HSTS_INCLUDE_SUBDOMAINS or on the Web server.
Django uses the Host header provided by the client to construct URLs in\ncertain cases. While these values are sanitized to prevent Cross Site Scripting\nattacks, a fake Host value can be used for Cross-Site Request Forgery,\ncache poisoning attacks, and poisoning links in emails.
Because even seemingly-secure web server configurations are susceptible to fake\nHost headers, Django validates Host headers against the\nALLOWED_HOSTS setting in the\ndjango.http.HttpRequest.get_host() method.
このヘッダの検証は get_host() メソッドの実行時にのみ適用されます。もし request.META から直接 Host ヘッダにアクセスするコードを書いてしまうと、このセキュリティプロテクションを回避してしまうので注意してください。
For more details see the full ALLOWED_HOSTS documentation.
Additionally, Django requires you to explicitly enable support for the\nX-Forwarded-Host header (via the USE_X_FORWARDED_HOST setting)\nif your configuration requires it.
Similar to the CSRF limitations requiring a site to\nbe deployed such that untrusted users don't have access to any subdomains,\ndjango.contrib.sessions also has limitations. See the session\ntopic guide section on security for details.
If your site accepts file uploads, it is strongly advised that you limit\nthese uploads in your Web server configuration to a reasonable\nsize in order to prevent denial of service (DOS) attacks. In Apache, this\ncan be easily set using the LimitRequestBody directive.
If you are serving your own static files, be sure that handlers like Apache's\nmod_php, which would execute static files as code, are disabled. You don't\nwant users to be able to execute arbitrary code by uploading and requesting a\nspecially crafted file.
Django's media upload handling poses some vulnerabilities when that media is\nserved in ways that do not follow security best practices. Specifically, an\nHTML file can be uploaded as an image if that file contains a valid PNG\nheader followed by malicious HTML. This file will pass verification of the\nlibrary that Django uses for ImageField image\nprocessing (Pillow). When this file is subsequently displayed to a\nuser, it may be displayed as HTML depending on the type and configuration of\nyour web server.
No bulletproof technical solution exists at the framework level to safely\nvalidate all user uploaded file content, however, there are some other steps\nyou can take to mitigate these attacks:
\nOne class of attacks can be prevented by always serving user uploaded\ncontent from a distinct top-level or second-level domain. This prevents\nany exploit blocked by same-origin policy protections such as cross\nsite scripting. For example, if your site runs on example.com, you\nwould want to serve uploaded content (the MEDIA_URL setting)\nfrom something like usercontent-example.com. It's not sufficient to\nserve content from a subdomain like usercontent.example.com.
Beyond this, applications may choose to define a whitelist of allowable\nfile extensions for user uploaded files and configure the web server\nto only serve such files.
While Django provides good security protection out of the box, it is still\nimportant to properly deploy your application and take advantage of the\nsecurity protection of the Web server, operating system and other components.
\nMake sure that your Python code is outside of the Web server's root. This\nwill ensure that your Python code is not accidentally served as plain text\n(or accidentally executed).
Take care with any user uploaded files.
Django does not throttle requests to authenticate users. To protect against\nbrute-force attacks against the authentication system, you may consider\ndeploying a Django plugin or Web server module to throttle these requests.
Keep your SECRET_KEY a secret.
It is a good idea to limit the accessibility of your caching system and\ndatabase using a firewall.
Take a look at the Open Web Application Security Project (OWASP) Top 10\nlist which identifies some common vulnerabilities in web applications. While\nDjango has tools to address some of the issues, other issues must be\naccounted for in the design of your project.