Ответ 1

На веб-стороне вещей С# (и, в более общем плане, ASP.NET) обычно уязвим для следующих элементов (элементы, перечисленные OWASP Top 10 2013). Я понимаю, что вы в основном заинтересованы в функциях раковины, из которых я покрываю некоторые, однако вы действительно спрашивали, как люди случайно создают опасный код на С#, поэтому, надеюсь, я представил здесь некоторое понимание.

A1-Injection

SQL Injection

Генерация запросов путем конкатенации строк.

var sql = "SELECT * FROM UserAccount WHERE Username = '" + username "'";
SqlCommand command = new SqlCommand(sql , connection);
SqlDataReader reader = command.ExecuteReader();

Это часто можно решить с помощью параметризованных запросов, но если вы используете условие IN, это в настоящее время невозможно без конкатенации строк.

Инъекция LDAP

Код, например

searcher.Filter = string.Format("(sAMAccountName={1})", loginName);

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

Инъекция команд OS

Этот код уязвим для ввода команд, потому что второй параметр Process.Start может иметь дополнительные команды, переданные ему с помощью символа & для пакетной обработки нескольких команд

string strCmdText= @"/C dir c:\files\" + Request.QueryString["dir"];
ProcessStartInfo info = new ProcessStartInfo("CMD.exe", strCmdText);
Process.Start(info);

например. foldername && ipconfig

A2-Сломанная аутентификация и управление сеансом

Выйти

Метод аутентификации по умолчанию SignOut не обновляет серверную сторону, позволяя продолжить использование захваченного автозапуска.

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

Использование состояния сеанса для проверки подлинности

A фиксация сеанса может существовать уязвимость, если пользователь использовал состояние сеанса для аутентификации.

Скрипты A3-Cross-Site (XSS)

Response.Write (и ярлык <%= =>) уязвимы по умолчанию, если разработчик не запомнил HTML кодирование вывода. Более поздний ярлык <%: HTML кодируется по умолчанию, хотя некоторые разработчики могут использовать его для вставки значений в JavaScript, где злоумышленник может избежать этого. Даже используя современный Razor engine, это сложно сделать правильно:

var name = '@Html.Raw(HttpUtility.JavaScriptStringEncode(Model.Name))';

ASP.NET по умолчанию включает Request Validation, который блокирует любые входные данные из файлов cookie, строки запроса и из данных POST, которые могут потенциально быть вредоносными (например, тегами HTML). Это, похоже, хорошо справляется с входными данными, поступающими через конкретное приложение, но если в базе данных есть контент, который добавлен из других источников, например, из приложения, написанного с использованием других технологий, возможно, что вредоносный код script все еще может быть выведен, Еще одна слабость заключается в том, что данные вставляются внутри значения атрибута. например.

<%
alt = Request.QueryString["alt"];
%>
<img src="http://example.com/foo.jpg" alt="<%=alt %>" />

Это может быть использовано без запуска проверки запроса:

Если alt -

" onload="alert('xss')

то это делает

<img src="http://example.com/foo.jpg" alt="" onload="alert('xss')" />

В старых версиях .NET это было немного mine-field для разработчика, чтобы гарантировать, что их вывод был правильно закодирован с использованием некоторые веб-элементы управления по умолчанию.

К сожалению, синтаксис привязки данных еще не содержит встроенного синтаксиса кодирования; его появление в следующей версии ASP.NET

например. не уязвимы:

  <asp:Repeater ID="Repeater1" runat="server">
    <ItemTemplate>
      <asp:TextBox ID="txtYourField" Text='<%# Bind("YourField") %>'
        runat="server"></asp:TextBox>
    </ItemTemplate>
  </asp:Repeater>

уязвима:

<asp:Repeater ID="Repeater2" runat="server">
  <ItemTemplate>
    <%# Eval("YourField") %>
  </ItemTemplate>
</asp:Repeater>

Ссылки на прямой объект A4-Insecure

Связывание модели MVC может позволить параметры, добавленные в данные POST, для сопоставления с моделью данных. Это может произойти непреднамеренно, поскольку разработчик не понял, что злоумышленник может изменить параметры таким образом. Атрибут Bind можно использовать для предотвратить это.

Неверная конфигурация A5

Существует множество опций конфигурации, которые могут ослабить безопасность приложения. Например, установите customErrors на On или включите трассировку.

Сканеры, такие как ASafaWeb, могут проверить эти общие неправильные конфигурации.

A6-чувствительная экспозиция данных

Хеширование по умолчанию

Методы хэширования по умолчанию в ASP.NET иногда не самые лучшие.

• HashPasswordForStoringInConfigFile() - это также может быть плохо, если он используется для хэширования простого пароля без добавления соли.
• Статья У нашего хэш-процесса без одежды нет" относительно поставщика членства ASP.NET в .NET 4.

Контроль доступа к функциональному уровню A7

Отказ от ограничения доступа к URL

В режиме интегрированного конвейера .NET может видеть каждый запрос, и дескрипторы могут разрешать каждый запрос даже для ресурсов не .NET(например, .js и изображений). Однако, если приложение я работает в классическом режиме,.NET видит только запросы к файлам, таким как .aspx, поэтому другие файлы могут быть случайно необеспеченными. Подробнее см. этот ответ.

например. www.example.com/images/private_photograph_user1.jpg скорее всего будет уязвим в приложении, которое работает в классическом режиме, хотя есть обходные пути.

A8-Подпрограмма запроса на межсайтовый запрос (CSRF)

Хотя устаревшие приложения для веб-форм обычно более безопасны для CSRF из-за того, что злоумышленник должен подделать состояние View State и Event Validation, более новые приложения MVC могут быть уязвимы, если разработчик не выполнил вручную анти-поддельные жетоны. Заметьте, я не говорю, что веб-формы не уязвимы, просто сложнее просто передать несколько базовых параметров - есть исправления, хотя, например, интеграция ключа пользователя в значение "Состояние представления".

Если для свойства EnableEventValidation установлено значение true, ASP.NET проверяет, что управляющее событие возникло из пользовательского интерфейса, который был визуализирован этим элементом управления. Элемент управления регистрирует свои события во время рендеринга, а затем проверяет события во время обратной передачи или обработки обратного вызова. Например, если элемент управления списком включает в себя параметры с номерами 1, 2 или 3, когда страница отображается, и если получен обратный запрос, задающий параметр номер 4, ASP.NET вызывает исключение. Все управляемые событиями элементы управления в ASP.NET используют эту функцию по умолчанию.

Функция

[EnableEventValidation] снижает риск несанкционированных или вредоносных обратных запросов и обратных вызовов. Настоятельно рекомендуется отключить проверку событий.

A10-Unvalidated - перенаправление и переадресация

Добавление кода, например

Response.Redirect(Request.QueryString["Url"]);

сделает ваш сайт уязвимым. Атака может быть инициирована путем отправки фишингового письма пользователю, содержащему ссылку. Если пользователь проявляет бдительность, он может дважды проверить домен URL перед нажатием. Тем не менее, поскольку домен будет соответствовать вашему домену, которому доверяет пользователь, он нажимает ссылку, не подозревая, что страница перенаправит пользователя в домен злоумышленника.

Проверка должна проводиться на Url, чтобы гарантировать, что это либо относительный, разрешенный URL, либо абсолютный URL-адрес для одного из ваших собственных разрешенных доменов и страниц. Вы можете проверить, что кто-то не перенаправляет ваших пользователей на /Logout.aspx, например. Хотя не может быть ничего, что помешало бы злоумышленнику напрямую связать с http://www.example.com/Logout.aspx, они могли бы использовать перенаправление, чтобы скрыть URL-адрес, поэтому пользователю сложнее понять, к какой странице обращаются (http://www.example.com/Redirect.aspx?Url=%2f%4c%6f%67%6f%75%74%2e%61%73%70%78).

Другие

Другие категории OWASP:

• A9 - Использование компонентов с известными уязвимостями

о котором я не могу думать ни о чем, что характерно для С#/ASP.NET. Я буду обновлять свой ответ, если я думаю о каком-либо (если вы считаете, что они имеют отношение к вашему вопросу).

Ответ 2

Все, что использует регулярные выражения (в частности, RegularExpressionValidator). Чтобы увидеть это, запустите RegularExpressionValidator с регулярным выражением ^(\d+)+$ и дайте ему 30 цифр и альфа-символ для проверки.

Некоторые сообщения:

• http://msdn.microsoft.com/en-us/magazine/ff646973.aspx
• http://www.abemiester.com/abemiester/post/RegEx-DOS-attack-Regular-Expressions-Now-you-have-3-problems.aspx (это сообщение в блоге из моего собственного блога, в котором более подробно рассказывается о статье MSDN).

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

Ответ 3

Process.Start - это первое, что приходит на ум.

Я уверен, что WindowsIdentity и большая часть System.Security также можно использовать для зла.

Конечно, есть атаки SQL-инъекций, но я не думаю, что вы имеете в виду (хотя удаленное выполнение может происходить через SQL Server).

Ответ 4

Помимо очевидного Process.Start(), уже упомянутого, я вижу пару способов потенциальной косвенной эксплуатации.

• WinAPI вызывает через PInvoke до CreateProcess() и еще что-то.
• Любой вид механизма загрузки динамической сборки с использованием Assembly.Load() и других подобных перегрузок. Если скомпрометированная сборка перешла в систему и загрузилась.
• Если вы в полной мере доверяете.
• При наличии прав доступа любые операции реестра могут поставить вас под угрозу.

Это все, что приходит на ум прямо сейчас.

Ответ 5

IMO: 1-я функциональные функции, невинно выглядящие, но очень опасные при использовании без мысли.

В ASP.Net Response.Write или ярлык:

  <%= searchTermFromUser %>

В ADO.Net:

• Оператор string +:
  var sql = "SELECT * FROM table WHERE name = '" + searchTermFromUser + "'"

Ответ 6

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

Если вы получаете строку от пользователя и отображаете ее другому пользователю, не используя HtmlEncode, это потенциальный эксплойт.

Если вы получаете строку от пользователя и используете ее для построения SQL, это потенциальная инъекция SQL.

Если вы получаете строку от пользователя и используете ее для сжатия имени файла для Process.Start или Assembly.Load, это уязвимость удаленного выполнения

Вы понимаете, опасность связана с использованием несаминированных данных, если вы никогда не проходите вход пользователя во внешнюю систему без ее очистки (например, HtmlEncode) или с использованием безопасных для инъекций интерфейсов (пример: параметры SQL), вы относительно безопасны - в тот момент, когда вы забываете о том, чтобы санировать то, что самый невинный метод может стать уязвимостью безопасности.

Примечание: файлы cookie, html-заголовки и все, что проходит по сети, также являются данными от пользователя, в большинстве случаев даже данные в вашей базе данных являются данными от пользователя.

Ответ 7

Множество вещей в System.Net, System.XML, System.IO(все, что принимает URI и/или путь к файлу и фактически имеет дело с ресурсом, который они идентифицируют) System.Reflection, System.Security, System. Web, System.Data и System.Threading пространства имен могут быть опасными, так как они могут использоваться для создания плохих вещей, которые идут дальше, чем просто испортить текущее исполнение. Настолько, что было бы много времени, чтобы попытаться определить их.

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

И я не считаю это особенно плодотворным. Создание контрольного списка функций действительно работает только с ограниченной библиотекой или с большим языком, где многое из того, что было бы в библиотеке с языком, подобным С#, находится на самом языке.

Есть некоторые классически опасные примеры, такие как Process.Start() или что-либо, что напрямую выполняет другой процесс, но они сбалансированы, будучи совершенно очевидно опасным. Даже относительно безрассудный и некомпетентный кодер может позаботиться о том, когда они его используют, оставляя данные, которые относятся к другим методам, неактифицированным.

Это санитария данных - это более плодотворная вещь, чем любой список функций. Проверяются ли данные для удаления явно неправильного ввода (что может быть связано с атакой или может быть просто ошибкой) и закодировано ли оно соответствующим образом для определенного слоя (слишком много разговоров о "опасных" последовательностях символов, ' никогда не причинят вреда никому, он ' не правильно экранирован для SQL, что может повредить, когда он действительно находится на уровне SQL - задание, необходимое для обеспечения правильного ввода данных, является таким же, как и во избежание эксплойтов). Являются ли слои, на которых связь с чем-то вне кода прочная. Например, URI построены с использованием нерассмотренного ввода, если вы не можете включить некоторые из наиболее часто используемых методов System.Net и System.XML в отверстия.

Ответ 8

Использование любого типа небезопасного кода может вызвать проблемы, такие как указатели. Microsoft предоставила хорошую статью о небезопасном коде здесь: http://msdn.microsoft.com/en-us/library/aa288474(VS.71).aspx

Ответ 9

Reflection.Emit и CodeDom

Изменить:

Разрешения плагинов или сторонних библиотек, которые используют потоки, могут привести все ваше приложение, если вы не загрузите эти библиотеки/плагины в отдельную область приложения.

Ответ 10

Вероятно, половина фреймворка содержит очень страшные функции. Я сам думаю, что File.WriteAllText() очень страшно, так как он может перезаписать любой файл, к которому имеет доступ текущий пользователь.

Другой подход к этому вопросу будет заключаться в том, как вы можете управлять безопасностью. В статье http://ondotnet.com/pub/a/dotnet/2003/02/18/permissions.html содержится базовое описание системы безопасности .NET с System.Security.Permissions, содержащее все разрешения .NET. Вы также можете посмотреть http://msdn.microsoft.com/en-us/library/5ba4k1c5.aspx для получения дополнительной информации.

Короче говоря,.NET позволяет ограничить разрешения, которые может иметь процесс, например, запретить методы, которые изменяют данные на диске. Затем вы можете проверить эти права и действовать независимо от того, есть ли у них процесс или нет.

Ответ 11

может возникнуть проблема даже с простым сравнением строк.

Если приложение делает доверие решение, основанное на результатах этого Операция String.Compare, результат этого решения можно изменение CurrentCulture

Взгляните на пример. Довольно легко пропустить

Ответ 12

Я видел код, в котором пользователь мог установить имя и параметры для вызова функции в базе данных. Затем система выполнит именованную функцию через Reflection, не проверив ничего...