W frameworku Django wykryto podatność typu SQL injection (CWE-89) dotyczącą bezpośredniego użycia lookupa HasKey w kontekście baz danych Oracle. Podatność otrzymała ocenę CVSS 9.8 (CRITICAL), co oznacza możliwość pełnego przejęcia kontroli nad danymi bez żadnego uwierzytelnienia.
▸ Pokaż oryginał (EN)
An issue was discovered in Django 5.1 before 5.1.4, 5.0 before 5.0.10, and 4.2 before 4.2.17. Direct usage of the django.db.models.fields.json.HasKey lookup, when an Oracle database is used, is subject to SQL injection if untrusted data is used as an lhs value. (Applications that use the jsonfield.has_key lookup via __ are unaffected.)
Podatność występuje, gdy aplikacja bezpośrednio korzysta z klasy `django.db.models.fields.json.HasKey` i jako wartość lewostronną (lhs) przekazuje niezaufane dane użytkownika, a backend bazodanowy to Oracle. W takiej konfiguracji dane wejściowe nie są odpowiednio sanityzowane przed wbudowaniem ich w zapytanie SQL, co pozwala atakującemu na wstrzyknięcie własnego kodu SQL. Aplikacje korzystające z lookupa poprzez standardowy interfejs `__` (np. `jsonfield__has_key`) nie są podatne — problem dotyczy wyłącznie bezpośredniego użycia klasy lookupa.
Atakujący może odczytywać, modyfikować lub usuwać dane w bazie danych Oracle, a w określonych konfiguracjach potencjalnie przejąć kontrolę nad serwerem bazodanowym lub eskalować uprawnienia w systemie.
Należy zaktualizować Django do wersji 5.1.4, 5.0.10 lub 4.2.17 (odpowiednio do używanej gałęzi). Do czasu aktualizacji zaleca się unikanie bezpośredniego użycia `django.db.models.fields.json.HasKey` z niezaufanymi danymi jako wartością lhs i zastąpienie go lookupem przez interfejs `__` (np. `jsonfield__has_key`).
Django 5.1 przed wersją 5.1.4, Django 5.0 przed wersją 5.0.10, Django 4.2 przed wersją 4.2.17 — wyłącznie w instalacjach korzystających z bazy danych Oracle.
Podatność dotyczy wyłącznie instalacji z backendem Oracle. Aplikacje używające lookupa przez standardowy interfejs Django (`__`) są bezpieczne. Informacja o podatności została opublikowana na liście oss-security 2024-12-04, czyli przed oficjalną datą publikacji CVE (2024-12-06).
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:HDjangoproject Django
APPDjangoproject4.2 – 4.2.17 (bez)5.0 – 5.0.10 (bez)5.1 – 5.1.4 (bez)
Powiązane podatności
Django: brak walidacji uprawnień dodawania w GenericInlineModelAdmin
SQL injection w Django via argument _connector w QuerySet i Q()
In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when...
An issue was discovered in Django 3.2 before 3.2.14 and 4.0 before 4.0.6. The Trunc() and Extract() database f...
An issue was discovered in Django 2.2 before 2.2.28, 3.2 before 3.2.13, and 4.0 before 4.0.4. QuerySet.annotat...