А причем тут ASP.NET?! Я не говорил о том, как взломать ASP.NET, я говорил о том, какие могут быть (и были) проблемы с использованием ASP.NET. Основная мысль, развеять миф, что если снаружи выглядит достаточно секьюрно и безопасно, всегда найдется слабое место. И если рассматривать статью с этой позиции, то все становится ясно и понятно. Я не собирался писать мануалы по взлому, с которыми можно идти в интернет и крушить проекты. С конкретными ресёрчами я бы пришел не на хабру а hackerone. Поэтому я не вижу претензий публики на тему: «А если сделать идеально, то уязвимости — нет» — разумеется это так. Это не security мануал по безопасной разработке, это выборка интересных, на мой взгляд, кейсов, встречающихся на практике и упрощенных для понимания, которые до бесконечности можно обыгрывать. Я согласен, что и XXE и SMTP Header Injection и т.д., это целые вектора уязвимостей разных технологий, а не только ASP. В том числе по OWASP'у.
Теперь я понял. В чем Ваша претензия. Это не проблема Майкрософта. Этот кейс — взят из жизни из реального проекта. Данные из VIEW попадали в контроллер(а точнее в Action), который собирал Partial View и возвращал назад, это хорошо видно из картинки. Обратите внимание на алгоритм:
Алгоритм:
Пользователь делает запрос в контроллер;
Контроллер отрисовывает View;
Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
Готовый Partial View возвращается в основной, а основной – пользователю.
Не воспринимайте эту статью как мануал по зеродеям в ASP. Любой из предложенных пунктов можно обыграть, что ничего работать не будет или будет. Я говорю о том, можно ли хакнуть ASP, а не как это сделать. И основная мысль, это, что системы ломаются всегда, но намного чаще, их можно сломать через ошибки в человеческой логике.
И обратите внимание на название статьи «Можно ли «хакнуть» ASP инфраструктуру?» а не Можно ли «хакнуть» ASP.NET?
Очень странный комментарий. Какая разница что сделать на серверной стороне? Вывести содержимое модели или вывести содержимое ViewBag? Я могу вывести @((2 + 2).ToString()).
Нагрузка передается от View -> в PartialView. Во View как и обычно.
А вот почему так происходит, это уже поле для исследований. Нагрузка попадает не в razor, а в Server-Side и вариантов может быть масса. Надеюсь, теперь вам стало понятно. Спасибо.
В целом Вы Правы. Но ASP это не PHP. Многие вещи, написанные на нем живут годы, а некоторые и десятилетия. Например в моей карьере разработчика я часто встречался с ASP.NET WebForms, когда во всю уже был MVC, а сейчас активно занимает позиции Core. Но и Web Forms живет до сих пор.
Нагрузка (Payload) — Это тот сценарий (код), который мы хотим выполнить в контексте RCE.
2) Рассмотрим пример. Мы кладём модель во вьюху (ViewModel), полученную от контроллера, далее мы выполняем какие то действия и у нас отрисовывается PartialView, вероятность того, что туда уйдет компилируемый user-input очень мала. Поэтому во View — это просто не будет работать. А через Partial-View должен пройти input.
3) Здесь имеется ввиду штатные механизмы ASP, не дадут пробросить какую Вам захочется нагрузку. И будет ругаться фильтр.
4) Не все RCE обязательно уровнем High. Если мы вспомним CVSS 3. Там есть параметр «Сложность атаки (AC)», что заметно уменьшает оценку уязвимости.
5) И ещё от себя — это не гайд и не мануал, как взломать АСП, это описание некоторых проблем, которые могут возникнуть. Поэтому в статье нет и не предполагается точных алгоритмов развития атаки. Спасибо.
Начну с обратного… Разумеется вывод @Model — это опять же просто игровой сценарий, но нельзя вывести содержимое свойства любого объекта просто на клиентской стороне. Так или иначе должен быть Server-Side. Поэтому, вместо этой нагрузки, можно было бы и тот же калькулятор запускать.
По поводу PartialView и View. В этом вся и проблема. Если бы нагрузку можно было бы прокинуть в PartialView так же легко (причем не забывать, что ещё и пре-процессинг включиться, который надо обойти) — это уже было бы CVE с High уровнем. А так, этот вектор так же из реальной жизни взят, но упрощён для понимания, что не только эксплоитами возможно выполнить удаленный код. Спасибо за вопрос.
Разумеется, Вы правы. Это сценарий притянутый «за уши» — как можно манипулировать SMTP заголовками в контексте приложения — это не проблема Майкрософта или бага в продукте ASP — это ошибка разработчиков и логики (кейс взят из реальной жизни).
Не воспринимайте эту статью как мануал по зеродеям в ASP. Любой из предложенных пунктов можно обыграть, что ничего работать не будет или будет. Я говорю о том, можно ли хакнуть ASP, а не как это сделать. И основная мысль, это, что системы ломаются всегда, но намного чаще, их можно сломать через ошибки в человеческой логике.
И обратите внимание на название статьи «Можно ли «хакнуть» ASP инфраструктуру?» а не Можно ли «хакнуть» ASP.NET?
А вот почему так происходит, это уже поле для исследований. Нагрузка попадает не в razor, а в Server-Side и вариантов может быть масса. Надеюсь, теперь вам стало понятно. Спасибо.
2) Рассмотрим пример. Мы кладём модель во вьюху (ViewModel), полученную от контроллера, далее мы выполняем какие то действия и у нас отрисовывается PartialView, вероятность того, что туда уйдет компилируемый user-input очень мала. Поэтому во View — это просто не будет работать. А через Partial-View должен пройти input.
3) Здесь имеется ввиду штатные механизмы ASP, не дадут пробросить какую Вам захочется нагрузку. И будет ругаться фильтр.
4) Не все RCE обязательно уровнем High. Если мы вспомним CVSS 3. Там есть параметр «Сложность атаки (AC)», что заметно уменьшает оценку уязвимости.
5) И ещё от себя — это не гайд и не мануал, как взломать АСП, это описание некоторых проблем, которые могут возникнуть. Поэтому в статье нет и не предполагается точных алгоритмов развития атаки. Спасибо.
По поводу PartialView и View. В этом вся и проблема. Если бы нагрузку можно было бы прокинуть в PartialView так же легко (причем не забывать, что ещё и пре-процессинг включиться, который надо обойти) — это уже было бы CVE с High уровнем. А так, этот вектор так же из реальной жизни взят, но упрощён для понимания, что не только эксплоитами возможно выполнить удаленный код. Спасибо за вопрос.