PVS-Studio corporate blog
Information Security
Open source
.NET
C#
Comments 28
+11

Больше похоже на вступление к статье, чем на саму статью.

+24
А почему вас смущает малое количество уязвимостей в проектах на C#? Это же особенность самой платформы — «управляемый» код в виртуальной машине, отсутствие сырых указателей, отлов переполнений, некорректных преобразований типов и выходов за границы массивов средой исполнения, и многое многое другое — даже если разработчик от души наделает ошибок при кодировании (не считая именно логических ошибок, типа хранения паролей в нехэшированном виде или неправильных условий в if'ах), в большинстве самое худшее что может случиться — необработанное исключение и никаких там remote code execution.
А при веб-разработке, сам фреймворк во многих случаях фильтрует CSRF, XSS, ORM-библиотека экранирует входные данные, и т.д., что тоже сильно снижает требования к уровню разработчика и вероятность по невнимательности оставить дыру.
+8
Мне кажется основной посыл не малое количество уязвимостей в C# проектах, а их плохое оформление. То есть одно дело когда уязвимостей в базе мало, но те, что есть оформлено хорошо, другое дело когда уязвимостей в базе мало, а те что есть оформлены абы как.
+3

Тогда почему в 4 приведённых фиксах уязвимостей в Umbraco — XXE, XSS, XSRF, XSRF?

+3
Да, всегда можно реализовать что-то не по «лучшим практикам», всегда можно навернуть свой костыль для каких-то целей, или же просто оказаться в ситуации, которую не предусмотрели авторы фреймворка. Да и в самом C#, к примеру, можно упороться unsafe-методами и маршаллингом структур и отстрелить себе обе ноги, но необходимость в этом возникает крайней редко.
Я не говорил что уязвимости невозможны в приципе, я говорил что многое сделано для сокращения их возможного числа.
0

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

+6

Или огорчаешься, потому что мало серьёзных проектов с открытым кодом на C#.

+7

CVE-2017-15280 — это давно уже не уязвимость. Потому что XXE через XmlTextReader с настройками по умолчанию закрыли в .NET 4.5.2, за три года до 2017го...

+1

Эмм… Может на C# тупо мало софта и не в чем искать уязвимости? На типичном не-Windows компьютере (включая мобилы-планшеты) софта на шарпе примерно ноль.


Наверняка в программах на D, Cobol, SmallTalk, Haskell тоже мало CVE.

+3

Касательно уязвимостей.
Им в дотнете взяться особо неоткуда. Управляемый код со строгой статической типизацией перекрывает большинство классических проблем, так что выстрелить себе в ногу намного сложнее. Из потенциально дырявых технологий могу назвать разве что Remoting, которым уже лет 10 как не пользуются.
Остаются в основном штуки связанные с вебом, но и там можно поймать разве что XSS — SQL-инъеккциям тоже неоткуда взяться, ибо все используют LINQ.

-7

Вот вообще не очень понимаю, что все в этот LINQ упоролись…
От слова — совсем… даже вон — товарищь по оптимизации, один из разрабов дотнет писал — что таки линком не стоит особо сильно увлекаться…

+4

Это Entity Framework-ом не стоит особо увлекаться, ибо тормозит из-за своего change-tracking-а. Нормальные реализации типа linq2db (не путать с linq2sql) по производительности сравнимы с ручным написанием запросов.


Это касательно доступа к БД. Манипуляции же с объектами внутри процесса, там да, можно использованием LINQ себе производительность хорошо так просадить. В особо терминальных случаях его запускают поверх байтмассивов, а потом удивляются, чому оно работает на 4-5 порядков медленнее вручную написанного цикла.

0

Ну, там где я читал — речь шла про LINQ в принципе, хотя — может быть не применительно к базам, опять же, а манипуляций с объектами… К сожалению не могу найти статью тут на хабре....

-1

Мощьная и удобная — понятие субъективное


Мне например коннекты и датасеты — удобнее, как не крути… :)

+2

Вот именно потому, что субъективная, вы и не понимаете.


(правда, надо заметить, что статическая типизация и AST — вещи все-таки объективные, ну не суть)

0

Удобная и мощная != производительная.
Суть моего высказывания была в этом.

+1

Ну так любят и не за производительность (хотя в умелых руках производительность LINQ, как бы бессмысленно эта фраза не звучала, достаточна).

0

На вкус и цвет, все фломастеры разные.
Некоторые мои коллеги/знакомые считают на полном серьезе что производительность — не их забота, главное побыстрее сдать заказ и получить бабла. А производительность… ну, купит заказчик новый сервер за пару лимонов, и будет все хорошо с производительностью :)

0
На вкус и цвет, все фломастеры разные.

Ну так это и есть субъективная характеристика.

+1

А чем linq вам не нравится? Не сложные запросы на нем можно писать и очень даже удобно, а для более сложных запросов можно написать sql-запрос

+1
Microsoft C# — очень хороший пример качественной реализации C# и IL транскомпиляции вообще. Безопасность типов реализуется так, что в принципе, ошибки не являются критическими.
0
Исходя из моих наблюдений, общество C# разработчиков имеет больше вертикальных связей и меньше горизонтальных, за счет этого больше фрагментировано.
Идеи и хорошие практики распространяются медленнее, ну и вообще вкладываться в OSS у дотнетчиков — редкость.
0
Мне кажется это от того, что там вообще плохо с написанием велосипедов. В смысле, фреймворк покрывает 95% нужд, остальное подпирается костылем под конкретную задачу и… и никаких уязвимостей. Ну и OSS такое же — небольшие костыли. Во что вкладываться то?

Совсем другое дело на JS — есть голый язык, и на него как только не изгаляются для прикручивания лучших практик. Тут без OSS вообще никак.
Only those users with full accounts are able to leave comments. , please.