[C#] Как указать/GS, параметры для приложения C#?

Question

Как известно, /GS - это Visual C++ Compiler или Linker Options.

1. Могу ли я указать/GS в компиляторе или компоновщике C#?

2. Эти флаги включены по умолчанию в приложениях C#?

   [Изменить]: изменить содержание вопроса:

   2а. Включены ли эти функции (по этим параметрам компилятора, как в Visual C++) по умолчанию в приложениях C#?

3. Есть ли способ узнать, сгенерирован ли файл .exe/.dll с этими флагами?

Заранее спасибо.

Answer 1

Я предполагаю, что вы пытаетесь выполнить проверку кода/запустить инструменты статического анализа, чтобы следить за тем, чтобы соблюдались security/SDL best practices. Если вы продолжаете читать ...

Существует инструмент под названием Binscope, который может быть использован для проверки того, что ваши собственные/C++-файлы скомпилированы с помощью/GS,/SafeSEH,/NXCOMPAT и/DYNAMICBASE. Это специальные параметры на C++, которые затрудняют использование злоумышленниками переполнения буфера. (Binscope также проверяет несколько других вещей)

Единственное, что Binscope проверяет в C#/управляемых двоичных файлах, это если они используют сильные имена. Ближайшей вещью для binscope для C# является FxCop, которая подробно расскажет о множестве потенциальных проблем в вашем управляемом коде .Net. Для обеспечения безопасности исправьте предупреждения о безопасности, которые FxCop производит, и вы находитесь на своем пути.

Флаг/анализ заставляет Visual Studio выполнять некоторый статический анализ вашего собственного кода и позволяет узнать, обнаруживает ли он что-либо подозрительное. Эквивалент C# /. Net - это часть безопасности FxCop.

Answer 2

Ни один из этих вариантов не существует в C#, потому что C# генерирует управляемый код, а C++ генерирует собственный код (код машинного языка). Управляемый код называется «проверяемым», потому что он имеет гораздо более строгую проверку, чем C/C++, и обеспечивает безопасность типов способами, которые C++ и собственный код не могут. (Эти проверки не имеют отношения к управляемому коду, написанному на C++/CLI).

Большая часть этого объясняется тем фактом, что этот собственный код работает непосредственно на аппаратном обеспечении и управляемом коде, выполняемом в течение времени выполнения .NET (CLR).

Позвольте мне перейти вариантов один на один

1. /анализ - я не все знакомы с этой опцией, но, глядя на list of what it checks, ни одна из этих ошибок не представляется возможным или проблема в управляемый код. Например, первое предупреждение C6031 не является проблемой, поскольку управляемые коды генерируют исключение, которое нельзя игнорировать, если оно не выполняется.
2. /GS - Управляемый код (без учета unsafe) не имеет прямого доступа к памяти и не защищен от переполнения буфера. Вы получите исключение, а не переполнение в другую память.
3. /DynamicBase - Управляемый код создает байт под названием Intermediate Language (IL) и динамически компилируется в собственный код (JIT) во время выполнения, поэтому он не имеет фиксированного адресного пространства для рандомизации.
4. /SafeSEH - Управляемый код имеет свой собственный механизм исключения и не использует SEH.