Skip to content

The Agony and the Ecstasy of Securing .NET Applications

    
The Agony and the Ecstasy of Securing .NET Applications

Microsoft .NET applications can be just as vulnerable to attack as other apps.  As with any other development platform, developers are often focused more on business functionality than about making sure their applications protect the data with which they are entrusted. 

On average, 22.4 serious vulnerabilities are discovered within a given enterprise application during manual code review and penetration tests. That’s a staggering number that should cause any Internet user some serious concern. Even worse, most organizations only perform this testing on a small percentage of their applications.  Imagine if this were an airline that only inspects 10% of the planes, but when they do inspect, 22.4 safety problems are typically found. Yikes.

Not surprisingly, the well-respected 2014 Verizon Data Breach Incident Report (DBIR) just concluded that web application vulnerabilities are the leading cause of security breaches. At 36%, web application breaches are far ahead of cyber-espionage (22%), POS intrusions (14%), card skimming (9%), and everything else. Nevertheless, a recent spending study shows that organizations spend only 1.7% of their security budget on application security.

.NET Security Is Awesome

There are a number of reasons why .NET is a great platform for building secure web applications. Right from the start, Microsoft adopted most of the advances introduced in Java and then in some cases made them even better.  Also, because .NET doesn’t have to “run everywhere” it can often be less complex, which makes security easier.

microsoft-net-framework-error

Microsoft has fairly extensive security mechanisms either built-in to the framework or easily available by .NET developers as external libraries accessed via Nuget. Some examples include:

  • LINQ to SQL
  • Entity Framework
  • Anti Cross-Site Scripting Library (AntiXSS now integrated into .NET 4.5)
  • Authentication, Membership and Role Providers
  • Microsoft Enterprise Library (Validation Application Block, Logging Application Block)
  • Windows Identity Foundation (also integrated into .NET 4.5)
  • Many defenses built into the ASP.NET platform itself such as Request Validation, Event Validation, viewstate encryption, automatic output encoding for some web components, header encoding, and more…

However, Beware Configuration and Insecure Coding Practice

Having strong security defenses available is a huge step forward, as it means developers no longer have to develop all of their own security defenses.  This largely eliminates a huge source of vulnerabilities.  However, the majority of vulnerabilities stem not from incorrect defenses, but from:

  • Failure to use defenses in all the right places
  • Failure to properly invoke defenses
  • Failure to properly configure defenses

For example, the .NET web.config file contains many security configuration options, including debugging, tracing, cookie protection, cookieless sessions, enforcing SSL for authentication cookies, authorization rules, header encoding, request validation, event validation, weakened authentication security, and more... Misconfiguring any of these options could introduce a vulnerability that exposes an application.

Further, developers have to know when and how to invoke programmatic security defenses.  For example, failure to properly escape data for the specific HTML context it is destined for can introduce an XSS vulnerability. Staying on top of all these security defenses across a multi-million line of code application takes considerable knowledge and diligence on the part of developers.

What Can You Do? Three Key Recommendations

  1. Make sure that all developers and managers understand the basics of web application security. There are great resources available at Microsoft and OWASP.
  2. You can also get both instructor-led training and eLearning from our friends at Aspect Security.
  3. You’re also going to want to put some continuous automated checking in place to ensure that your .NET applications are properly coded and configured.  You can find a whole spectrum of solutions in the Gartner Magic Quadrant for Application Security.

Trusting developers and Microsoft isn’t enough to create rock solid secure applications.  As with managing any type of bugs, it takes continuous vigilance, education and automation to keep data safe. 


Developing a robust application security program does not need to be a daunting task...

Perhaps, all it takes is rethinking your existing program and moving to one that leverages a continuous application security (CAS) approach. Organizations practicing CAS quickly determine how a new risk affects them, design a defense strategy, and measure their progress to 100% coverage. By implementing eight functions within an enterprise you can assemble an effective application security program. 

continuous-application-security

 

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff Williams, Co-Founder, Chief Technology Officer

Jeff brings more than 20 years of security leadership experience as co-founder and Chief Technology Officer of Contrast Security. He recently authored the DZone DevSecOps, IAST, and RASP refcards and speaks frequently at conferences including JavaOne (Java Rockstar), BlackHat, QCon, RSA, OWASP, Velocity, and PivotalOne. Jeff is also a founder and major contributor to OWASP, where he served as Global Chairman for 9 years, and created the OWASP Top 10, OWASP Enterprise Security API, OWASP Application Security Verification Standard, XSS Prevention Cheat Sheet, and many more popular open source projects. Jeff has a BA from Virginia, an MA from George Mason, and a JD from Georgetown.