Как стать автором
Обновить

Комментарии 21

Есть же xml path
Spoiler header
declare @date datetime
	,@tableHTML  NVARCHAR(MAX)
	,@emails NVARCHAR(MAX)
	
set @emails='nov@m'

SET @tableHTML =
    N'<H1></H1>' +
    N'<table bordercolor="green" border="2">' +
    N'<tr bgcolor="#F7FF47"><th>Îòäåë</th><th>ÔÈÎ</th>
    <th>Ïåðâûé ïðîõîä</th>
    <th>Ïîñëåäíèé ïðîõîä</th>
    <th>Âðåìÿ ðàáîòû</th>
    </tr>'


select @tableHTML =@tableHTML +CAST(
(---------------
select
td=t.[dep]
,'' ,td=t.[name]
,'' ,td=t.[starttime]
,'' ,td=t.[endtime]
,'' ,td=t.[work]
,''
from (
----------------- 
SELECT 
dep
,name
,convert(varchar(20),starttime,120) as starttime
,convert(varchar(20),endtime,120) as endtime
,convert(varchar(20),(endtime -starttime),108) as work
FROM table
---------------
) as t
order by t.dep
for XML PATH('tr'), TYPE
)
as nvarchar(max))


select @tableHTML=@tableHTML+
    N'</table>' +
    N'<HR>'+
    N'<b>Regards</b>';

--select @tableHTML

 
EXEC msdb.dbo.sp_send_dbmail
	@profile_name = 'm',
	@recipients=@emails,
    @subject = 'Report',
    @body = @tableHTML,
    @body_format = 'HTML' ;    
   


Причём данный способ вообще почти официальный
docs.microsoft.com/ru-ru/sql/relational-databases/system-stored-procedures/sp-send-dbmail-transact-sql?view=sql-server-ver15#examples

У меня с одной работы остался расчудесный скрипт, который из MySQL базы, настроенной как linked server, из СКУД через MSSQL отправляет в екселе часы отработанные работниками за месяц. Тянет на целую статью в разделе abnormal programming.
Собственно вот они
склейки кусков well-formed HTML и XML в выдаче MS SQL через… FOR XML… — это как раз то, чего хотелось избежать. Сценарий такой — шаблон письма хранится в БД в виде текста, зависимого от типа отсылаемого сообщения. Текст сообщения — это структурный иерархический XML, сгенерированный процедурой тоже в зависимости от его типа. Хочется как раз уйти от индивидуальной склейки кусочков для сообщения каждого типа, а просто выплевывать XML с данными, и если есть шаблон — продавливать его через шаблон и получать документ
да-да, и где-то в этот момент в попытках написать очередной шаблонизатор, начинаешь задумываться между reporting services, Metabase, и их аналогами.
Мне тоже больше нравится через HTML, а склейка кусочками это фактически три поля HEAD + BODY + FOOTER. Все это можно хранить в одной табличке + 4-е поле имя таблицы откуда данные брать + процедуру генерящую HTML просто по имени отчета. Профит.
Вот так люди извращаются, а потом в XML либе микрософта находят дыру (не первый раз и даже не второй) и стройное приложение превращается в дырявую мечту скрипт-киддиса…

Не там экономия, ох не там.

Можете обозначить как предлагается эксплуатировать теоретическую дыру в либе в данном случае?

Как и любую другую xml дыру — для удаленного выполнения произвольного кода. И будет очень хорошо если привилегий хватит только на то, чтобы утащить данные скомпроментированного приложения.

Как вы будете инъекции производить?
Можете схематично прояснить, например, как начиная с формы на веб-странице вы выполните произвольный код из-за бага в XML библиотеке внутри рассылки почты из MS SQL?
Спасибо заранее.

Не думаю, что правилами хабра допускается непосредственное описание взлома.

В любом случае речь шла о том, что человек добавил лишний вектор атаки на приложение не получив существенной пользы при этом. Так делать нельзя, но как ни странно, на хабре есть люди считающие иначе…

А какая из уязвимостей XML либы микрософта может здесь что-то поломать?

XXE-инъекция требует, чтобы XML-документ был получен из ненадёжного источника, а тут он формируется полностью локально, средствами SQL Server.

Так то оно так. Но формируется он на основании данных лежащих в базе. А где гарантия, что в эту самую базу не смогут записать нужный эксплойт?

Большая часть XXE-инъекций небольшая и вполне может поместится в 256 символов, которые, например, выделили для имени пользователя.

Вы забываете, что все XXE работают через DTD, а DTD надо ставить сразу после декларации XML, а не внутри случайного тэга или атрибута.


Плюс все попадающие в XML данные по-нормальному должны экранироваться, что так же исключает любые XXE.

Плюс все попадающие в XML данные по-нормальному должны экранироваться, что так же исключает любые XXE.

Должны, но в данном случае никакого экранирования не наблюдается.

Но не в этом дело. Изначальный комментарий был о том, что очередная обнаруженная уязвимость в подсистеме xml, запросто скомпроментирует все приложение. Такие уязвимости существуют и гарантии, что нашли все из них — нет. Т.е. практически не получив выгоды, была добавлена дополнительная точка отказа.

Где это экранирования не наблюдается-то?

Должны, но в данном случае никакого экранирования не наблюдается.

Волшебный ответ. Диалог похож на разговор физика и домохозяйки, которая считает, что электрический радиатор отопления в отличие от паровых батарей «сжигает кислород», но при этом привести аргумент, отличный от «ну греется, значит сжигает же» не в состоянии.

Извините.
Спасибо. Весьма интересно. Жду продолжения.
Спасибо. Постараюсь написать
Не пытайся. Это потенциальная уязвимость, если у тебя в компании есть служба безопасности — за такое тебя очень сильно дрюкнут. А если злобная СБ — еще и штрафанут.

На минусы не смотри — это друзяшки автора, заминусовали как могли. Они не очень умные, как бы грустно это не звучало((

Респект автору за такле, ведь OLE это же небезопасно, может утекать память, стабильность сервера под вопросом. Также включать функционал для выполнения таких нестандартных функций это значит поощрять ичпользование sql server не по назначению.


лучше уж оффлоадить такие задачи на SSRS/SSIS, а не хардкодить простыню кода которую никто не разберет потом

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации