Django のセキュリティ
Django にはセキュリティのための処理がいくつかあり、設定の処理方法を学ぶことは、セキュリティ テストの知識の学習にも役立ちます。
CSRF
クロスサイト リクエスト フォージェリ (クロスサイト リクエスト フォージェリ、CSRF) は、攻撃者がユーザーをだまして、訪問した Web サイト上で悪意のある操作を実行し、ユーザーの現在の ID と権限を使用してユーザーの許可なしにリクエストを送信するネットワーク攻撃手法です。
わかりやすく言うと、ソーシャル メディア サイトを閲覧していて、ログインしているとします。別のタブで、電子メールなどで受け取った悪意のあるリンクをクリックしたが、それが悪意のあるものであることに気づかなかった。このリンクは実際には銀行の Web サイトへのリクエストであり、攻撃者はリンクに攻撃者の口座への送金などの悪意のあるアクションを含めています。CSRF 防御が導入されていない銀行 Web サイトにログインした場合、この悪意のある操作が成功する可能性があります。
一般的な防御策
CSRF 攻撃を防御するために、一般的に使用される防御策は次のとおりです。
-
CSRF トークン: アプリケーションはユーザーごとに一意の CSRF トークンを生成し、それをリクエストに埋め込むことができます。送信されるすべての POST リクエストにはこのトークンが含まれており、サーバー側で検証される必要があります。このように、悪意のある Web サイトは有効なトークンを取得できず、リクエストを正しく構築できません。
-
SameSite Cookie: SameSite 属性を Strict または Lax に設定すると、同じサイトによって開始されたリクエストにのみ Cookie が自動的に添付されるように制限できます。これにより、クロスサイトリクエスト攻撃を防止します。
-
ソース ドメイン名を確認する: サーバーはリクエストのソース ドメイン名を確認でき、リクエストが正当なドメイン名からのものでない場合は、操作の実行を拒否します。オリジンは、Referer ヘッダー、Origin ヘッダーを使用するか、ホスト フィールドをチェックすることによって確認できます。
-
二重確認: 機密性の高い操作の場合、セキュリティ層を追加するために、パスワードや確認コードなどの追加の確認情報の入力をユーザーに要求することができます。
-
安全なコーディングの実践: 開発者は、ユーザー入力の適切なエスケープと検証、リクエスト内の機密情報の開示の回避など、安全なコーディングの実践に従う必要があります。
これらの防御により、CSRF 攻撃に対する Web サイトのセキュリティを強化できます。ただし、Web サイトごとに状況が異なるため、エラー メッセージ、アクセス制御、セキュリティ監査などの要素を総合的に考慮して、自社のアプリケーションに適した CSRF 防御戦略をカスタマイズして適用することが非常に重要です。
ジャンゴディフェンス
1) CSRF ミドルウェアは、MIDDLEWARE 構成でデフォルトでアクティブ化されます。この構成をオーバーライドする場合は、CSRF 攻撃が処理されたことを前提とするビュー ミドルウェアよりも前に「django.middleware.csrf.CsrfViewMiddleware」を注文する必要があることに注意してください。
2) POST フォームを使用するテンプレートで、テンプレートは追加します。
<form method="post">{% csrf_token %}
SQLインジェクション
SQL インジェクションを使用すると、悪意のあるユーザーがデータベース内で任意の SQL コードを実行できます。これにより、記録が削除されたり侵害されたりする可能性があります。
Django のクエリセットはパラメータ化されたクエリから構築されているため、SQL インジェクションから保護されています。クエリの SQL コードは、クエリのパラメータとは別に定義されます。パラメータはユーザーから取得される可能性があるため安全ではないため、基礎となるデータベース エンジンによってエスケープされます。
Django は、開発者に生のクエリを作成したり、カスタム SQL を実行したりする機能も提供します。これらのメソッドはできる限り控えめに使用する必要があり、ユーザーが制御可能なパラメータを適切にエスケープするように注意する必要があります。また、RawSQL で extra() を使用する場合は注意が必要です。
クリックジャッキングに対する防御 - クリックジャッキング保護
Web ページが他の iframe に埋め込まれないようにする
ブラウザは、リソースをフレームまたは iframe にロードできるかどうかを示す X-Frame-Options HTTP ヘッダーをサポートしています。応答に値 SAMEORIGIN のヘッダーが含まれている場合、リクエストが同じ Web サイトからのものである場合、ブラウザーはフレーム内のリソースのみを読み込みます。ヘッダーが DENY に設定されている場合、リクエストがどの Web サイトから行われたかに関係なく、ブラウザーはリソースがフレームに読み込まれるのを防ぎます。
ジャンゴクリックジャッキング
https://docs.djangoproject.com/zh-hans/4.2/ref/clickjacking/#clickjacking-prevention
オンライン ストアに、ログイン ユーザーが「今すぐ購入」をクリックして商品を購入できるページがあるとします。便宜上、ユーザーはストアにログインしたままにすることを選択します。攻撃者サイトは、そのページの 1 つに「I Like Ponies」ボタンを作成し、そのストアのページを透明な iframe にロードし、「I Like Ponies」ボタンの上に「今すぐ購入」ボタンを目に見えないように重ねて表示する可能性があります。ユーザーが攻撃者の Web サイトにアクセスした場合、「I Like Pony」をクリックすると、誤って「今すぐ購入」ボタンをクリックしてしまい、知らないうちに商品を購入してしまうことになります。
Django 防御インスタンス
Django アプリケーションに直接アクセスすると、
X-Frame-Options が DENY に設定されており、他の iframe の埋め込みが禁止されていることがわかります。
iframe を含む HTML にはアドレスが埋め込まれます
<!DOCTYPE html>
<html>
<head>
<title>包含 iframe 的页面</title>
</head>
<body>
<h1>这是一个包含 iframe 的页面</h1>
<iframe src="http://127.0.0.1:8000/polls/" width="500" height="300"></iframe>
</body>
</html>
この HTML にアクセスすると、Web ページが表示できないことがわかります。
ユーザーがアップロードしたコンテンツ攻撃
ユーザーアップロードコンテンツ攻撃とは、悪意のあるユーザーまたは攻撃者が、攻撃や悪用を目的として、悪意のあるコードまたは悪意のあるファイルを含むコンテンツを Web サイトまたはアプリケーションにアップロードすることを指します。
この攻撃は、次のセキュリティ上の問題を引き起こす可能性があります。
-
コードインジェクション: 攻撃者は、他のユーザーがそのファイルにアクセスしたときにそのスクリプトが実行される悪意のあるスクリプトを含むファイルをアップロードする可能性があります。この種の攻撃はコード インジェクションまたはリモート コード実行 (Remote Code Execution、RCE) と呼ばれ、攻撃されたユーザーのブラウザを制御され、任意の悪意のある操作を実行する可能性があります。
-
ファイル インクルードの脆弱性: 攻撃者は、ファイル インクルードの脆弱性を発見して悪用するために、機密データまたはシステム ファイル パスを含むファイルをアップロードする可能性があります。これらの脆弱性を悪用すると、攻撃者はシステム上の重要なファイルを読み取り、置換、または削除できる可能性があります。
-
悪意のあるファイルの配布: 攻撃者は、マルウェア、ウイルス、またはランサムウェアを含むファイルをアップロードする可能性があります。他のユーザーがこれらのファイルをダウンロードまたは実行すると、コンピューターが感染したり、データ漏洩、データ破損、ランサムウェアなどの脅威にさらされる可能性があります。
共通のセキュリティ対策
ユーザーがアップロードしたコンテンツ攻撃を防ぐために、一般的に使用されるセキュリティ対策のいくつかを次に示します。
-
ファイル タイプの検証: ユーザーがアップロードするファイル タイプを制限し、アップロードされたファイルの拡張子と MIME タイプを検証します。信頼できる安全なファイル タイプのみアップロードが許可され、不明なファイル タイプやリスクの高いファイル タイプは拒否されます。
-
ファイル サイズ制限: サーバーまたはアプリケーションの処理能力を超えないように、アップロードされるファイルのサイズを制限します。
-
ファイル封じ込めの脆弱性の修正とセキュリティ構成: アプリケーションにファイル封じ込めの脆弱性を引き起こす可能性のあるコードの問題が修正されていること、および機密ファイルへのアクセスを制限し、システム パスなどの情報の公開を避けるためにサーバー上に適切なセキュリティ構成があることを確認します。
-
安全なファイル ストレージ: ユーザーがアップロードしたファイルを安全な場所に保存し、直接アクセスによってファイルが実行またはダウンロードされないようにする措置を講じます。アップロードされたファイルを Web アクセス不可能なディレクトリに保存し、サーバー側スクリプトを使用して安全な読み取りおよびダウンロード インターフェイスを提供します。
-
安全なコーディングの実践: 開発中は、適切な入力検証および出力エンコーディング手法を使用して、コード インジェクションやクロスサイト スクリプティング (XSS) などのセキュリティの問題を防ぎます。
要約すると、ユーザーがアップロードしたコンテンツへの攻撃は重大なセキュリティ上の脅威です。そのような攻撃から守るために、アプリケーションの設計、開発、保守中に適切なセキュリティ対策を講じる必要があり、定期的なセキュリティ監査と脆弱性スキャンを実行する必要があります。タイムリーな修復、脆弱性の発見。
ジャンゴの提案
1) このような問題を回避するには、クラウド サービスまたは CDN から静的ファイルを提供することを検討してください。
2) サービス妨害 (DOS) 攻撃を防ぐために、アップロードされるファイルを Web サーバー構成で適切なサイズに制限します。Apache では、LimitRequestBody ディレクティブを使用できます。
3) 静的ファイルをコードとして実行できる Apache の mod_php などのハンドラーがオフになっていることを確認します。
4) 必要に応じて、ユーザーがアップロードできるファイル拡張子を制限するリストを定義します。
他の提案
- Python コードが Web サーバーのルート ディレクトリの外にあることを確認してください。これにより、Python コードが誤ってプレーン テキストとして提供 (または誤って実行) されることがなくなります。
- ユーザーがアップロードしたすべてのファイルには注意してください。Django は、認証されたユーザーのリクエストを抑制しません。認証システムに対するブルート フォース攻撃を防ぐには、Django
プラグインまたは Web サーバー モジュールをデプロイして、これらのリクエストを抑制することを検討してください。 - SECRET_KEY、および使用中の場合は SECRET_KEY_FALLBACKS を秘密にしておきます。ファイアウォールを使用してキャッシュ システムとデータベースへのアクセスを制限することをお勧めします。
- オープン ソース Web アプリケーション セキュリティ プロジェクト (OWASP) のトップ 10 リストを見てください。このリストでは、Web アプリケーションの一般的な脆弱性をいくつか示しています。Django には
いくつかの問題を解決するツールがありますが、プロジェクト設計では他の問題を考慮する必要があります。
2023 年版: https://owasp.org/API-Security/editions/2023/en/0x11-t10/ - Mozilla では、Web セキュリティに関連する多くのトピックについて議論しています。彼らの Web ページには、あらゆるシステムに適用されるセキュリティ原則も含まれています。