Roslyn diagnostic analyzers utilize the power of Roslyn open-source C# and Visual Basic (VB) compilers to help you write more robust and secure code through rich code analysis and detailed issue explanation. In this blog post, we’ll cover some of the basics to get you started on using the security specific set of analyzers for your project.
What is Roslyn?
Roslyn is the open source .NET compiler platform providing developers using C# and VB the ability to see what is happening with their source code as it goes through the compiler pipeline and its API layers. For a more in depth explanation, please check out the project’s GitHub page.
What are Roslyn Analyzers?
Roslyn Analyzers expose the live static analysis APIs available through the Diagnostics layer to give you a deep analytical insight into the syntax, semantics, security and other issues found in your code, along with instructions on how and where to fix them. Since our focus in this article will be on security, check out the GitHub project page for more on the other analyzers.
What Security Analyzers are available today?
Currently, we have six analyzers that cover common vulnerabilities on cryptography, XML and exception handling. They’re found as one NuGet package known as Desktop.Analyzers, and here’s a bit more about them:
- CA5350: Do Not Use Weak Cryptographic Algorithms – this analyzer checks to see if you’re using any of the cryptographic algorithms claimed to be weak by the security community, which as of this blog post timestamp include TripleDES, SHA1 and RIPEMD160. These algorithms shouldn’t be used if you’re guaranteeing confidentiality on the product or service you’re using it on.
- CA5351: Do Not Use Broken Cryptographic Algorithms – this, like the analyzer above, checks to see if you’re using any cryptographic algorithms that are no longer effective at keeping secrets but instead of weak are known to be “broken”. This analyzer checks for MD5, DES and RC2 usage.
- CA3075: Insecure DTD Processing – using Document Type Definition (DTD) processing can be tricky, especially since it allows your parser to accept external untrusted input, which could be leveraged by attackers to disclose information or compromise your system. This analyzer checks a number of security aspects of DtdProcessing. First, it tells you to not use Dtd at all, unless you need to. Second, if you have Dtd enabled, it ensures you only resolve external entities using XmlSecureResolver. Third, it ensures you specify an XmlReader instance in all Load() cases.
- CA3076: Insecure XSLT Script Execution – this analyzer checks to see if you’re using Extensible Stylesheets Language Transformations XSLT to transform XML to HTML, text or other format insecurely and throws you a warning to ensure you don’t execute malicious script from an untrusted source.
- CA3077: Insecure Processing in API Design, XML Document and XML Text Reader – this analyzer, similar to the CA3075, focuses on the DTDProcessing using XmlDocument and XmlTextReader’s subclasses. It checks how you handle exceptions and resolve external entities.
- CA2153: Do Not Catch Corrupted State Exceptions – CSE indicates that the state of a process has been corrupted and not caught by the system. In the corrupted state scenario, a general handler only catches the exception if you mark your method with the proper handling attribute. By default, the Common Language Runtime (CLR)will not invoke catch handlers for CSEs. This warning triggers when catching CSEs with a general handler that catches all exceptions, such as catch(exception) or catch(no exception specification).
How Do I Use Them?
To get started, follow these steps:
- Install the Desktop.Analyzers package from NuGet in the Visual Studio Package Manager Console
- Add the Microsoft Security Recommended ruleset (make sure to change the extension to “.ruleset”) and follow the steps to use it as an additional ruleset, which pre-selects the appropriate security rules for you
Once you have the two items above installed, just go to the “Analysis” menu item and select “Run code analysis on the solution” from the drop down. Any warnings will appear in the Error List tab and clicking on the warning number will take you to the MSDN article that explains each issue identified more in detail.
Take our analyzers for a spin and let us know if you encounter any issues by commenting on this blog post. Also, we encourage you to play around with the code on GitHub, develop your own set of security analyzers to use in your own projects or submit them to Microsoft for future consideration in the Security Analyzers rule package.
We look forward to seeing what you can do!