Dispelling Common Myths About Using Managed Code

We have often heard developers and testers attest that their application is free of certain security vulnerabilities because it is written in managed code. Although using managed code can help reduce certain types of security vulnerabilities, it cannot guarantee that your application won t have any. Several myths exist about preventing security issues by using managed code, and the following subsections show why these assumptions are not valid.

Whenever untrusted user data is supplied to an application, it can introduce security vulnerabilities. Testing for these vulnerabilities is covered in other chapters throughout this book. Even if the application uses managed code exclusively, basic security testing principles still apply. However, before we discuss the security issues that can be found in applications that use managed code, let s dismiss some of the common myths about using managed code.

Myth 1: Buffer Overflows Don t Exist in Managed Code

As discussed in Chapter 8, Buffer Overflows and Stack and Heap Manipulation, buffer overflows can lead to arbitrary execution of an attacker s code. Although using managed code protects against the majority of buffer overflow issues found in applications, overflows in applications written in managed code are still be possible.

Managed code can have code that is unverifiable . Any code that is unverifiable has the potential of causing serious security problems like buffer overflows, garbage collection (GC) heap corruption, and violating the type system. When you use C#, the unsafe keyword must be used to declare a block of code as unverifiable. Other managed languages do not have an explicit unsafe keyword and may emit unverifiable code for some constructs by default.

Also, many applications are not written entirely in managed code. Instead, a managed application might interact with unmanaged code, such as by using a Component Object Model (COM) object. As such, an application written in managed code calling into unmanaged code using a COM interop, PInvoke, etc. can still cause buffer overflows, integer overflows, format string issues, and array indexing errors. Refer to the section titled Using Unverifiable Code later in this chapter for more information.

Myth 2: ASP.NET Web Controls Prevent Cross-Site Scripting

In Web application development, ASP.NET enables a programmer to design a Web page by using Web controls that automatically render the HTML, much like building a Microsoft Windows application. This enables the developer to create a complex Web page without having to write a lot of HTML. The developer can set properties on the Web controls that affect how the controls behave when users browse to the page. For example, the following code shows the values set for an image Web control.

 this.exampleImage.ImageUrl = Request.QueryString("imageUrl"); this.exampleImage.AlternateText = Request.QueryString("imageText"); 

It might seem that there are cross-site scripting (XSS) vulnerabilities in this code because the untrusted client input is used to set the value of the image s properties. However, many of the ASP.NET controls automatically encode the values, such as the ImageUrl and AlternateText properties for an Image Web control. However, not all of the controls automatically encode the values. Take the following example:

 this.exampleLink.NavigateUrl = Request.QueryString("linkUrl"); this.exampleLink.Text = Request.QueryString("linkText"); 

If exampleLink is an ASP.NET HyperLink control, you might think that the control will automatically encode the values for NavigateUrl and Text like the image Web control did. However, the Text property for a HyperLink control does not automatically encode the value. Instead, the application should use the appropriate HtmlEncode method to prevent XSS vulnerabilities.

Chapter 10, HTML Scripting Attacks, goes into further detail on XSS attacks, and you can also refer to the book s Web site for the list of ASP.NET controls and whether they encode or not. Use this list and the tips in Chapter 10 to help figure out where to look for these vulnerabilities ”never assume that .NET controls don t need to be tested for XSS bugs .

Myth 3: Garbage Collection Prevents Memory Leaks

In programming languages such as C and C++, the developer must ensure any memory that was previously allocated is freed, which leads to many memory leaks in applications. Using the .NET Framework generally makes it easier to manage memory allocation and deallocation because both are handled by garbage collection. When resources aren t needed any more, the CLR automatically frees the memory ”or that is what might be expected to happen.

Managed code has the ability to call into unmanaged code to perform certain operations. For example, your application might call into a native Windows API to perform certain operations. If your managed assembly calls into unmanaged code that allocates memory for an object, how does the managed code know when or how to free the memory? It doesn t, unless you explicitly handle cleaning up this memory.

Even if your application does not leak memory, managed code makes it easy to write badly designed code that could allow your assembly to consume all the system memory. These aren t memory leaks, but could lead to poor application performance or denial of service attacks, such as those discussed in Chapter 14, Denial of Service Attacks. Look at the following code example:

 // Get untrusted data from user and split on semicolons. string[] values = inputString.Split(';'); foreach (string value in values) {     // Create a new object and add to list.     AddToList(new HugeMemoryStructure(value)); } 

In this example, user input is used to create an array of strings by splitting the input on semicolons. The code then loops through the array of strings and constructs a new object and adds it to a list. Because each semicolon causes an object to be created and added to a list, it makes it easy for an attacker to consume a lot of memory by providing an input string of several semicolons. Do not assume using managed code obviates the need to test for resource starvation attacks.

Myth 4: Managed Code Prevents SQL Injection

The .NET Framework provides some really useful libraries that enable your code to access databases. SQL injection vulnerabilities are caused when user input is used when constructing SQL statements that allow the logic of the statement to be modified in undesirable ways. If your application is using managed code to access a database, it is still susceptible to SQL injection attacks. Chapter 16, SQL Injection, explains and shows how to test for SQL injection, and includes examples that illustrate that managed code is still vulnerable.

Important  

Although several myths about the security of managed code exist, managed code does provide a great code access security mechanism, which improves the overall security of a system by providing an extra layer of protection on top of user security.