Secure .NET Development Introduction

There is a fine line between a secure .NET Web Application and an insecure .NET Web Application. A handful of tweaks here and there can make a world of difference

Back in March, the company I work for, Farm Credit Services of America, paid for co-worker and me to fly down to Disney World to take the SANS "Secure .NET Development" course. Yes, the course was at Disney World. I didn't pick the location. But I did ride a lot of rides.

The number one thing I took away from the class was a lot of features have been added into the .NET Framework to help with security. A lot of them are turned off by default. Why? Reasons.

The vast majority of them are not hard to implement, a lot of time we were only making one or two configuration changes or modifying a couple lines of code. That was the most shocking part of the class. There is not a big difference between secure code and insecure code. By making a few tweaks to your code base you can improve security.

This post is the beginning of a series which will detail out some of the changes I have made to .NET Web Applications to make them more secure.

It would naïve of me to walk up to a team, tell them to make these changes, and boom your application is 100% secure. I mean I could do that. For extra excitement I could bring a fake mic and drop it before leaving. It is up to you and your business to establish a priority for implementing changes or adding security into your development workflow.

Astute readers of future posts will notice the changes proposed seem rather redundant. For example, the recommendation is to encode text coming out to prevent XSS (Cross Site Scripting). In addition, we can add a header to the response that will prevent JavaScript from calling out to another site.

You are right, this is redundant. That is intentional. 100% security is impossible.

The key is to use multiple layers of defense.

Time to use a bad analogy as to why. Back in medieval times kings and queens needed to protect their stuff. Gold, Jewels, large fur coats, scepters, and candy. You know, the important things we take for granted everyday. Castles were built. Looking at a castle and you can see it provided multiple layers of defense in order to get to the sweet sweet loot. On the outer most layer there were moats, walls, towers and gates. Inside the castle was a keep with more walls and gates. If someone really wanted to get that cool stuff they could. They would have lay siege to the castle. Maybe build some battering rams or siege towers. But, none of that was free. Men have to be fed and clothed. Wood is needed for battering rams and towers.

Think back to the movie Lord of the Rings: The Two Towers. If you haven’t seen it, this analogy will not work for you. But seriously, how can you work in IT and not have seen that movie. Anyway, Dracula wanted to get in because the king banished that creepy looking guy for being a little too creepy. Perhaps he called him a jive sucker when kicking him out. I can’t remember the specifics, the movie was like three hours long. It was payback time, so Dracula constructed a massive army of orcs. For a while the elves, dwarves, and humans(?) kept the orcs back. At one point the bearded dwarf got into a counting contest with that guy from Pirates from the Caribbean for how many orcs they killed. Eventually the orcs got through the outer wall. They would’ve gotten through to the keep if Magneto didn’t show up.

The point is, the attackers got in. Eventually. But they paid a heavy price.

“But we secure all communication using https! We validate the strings as they are coming into our system. There is no way a hacker can insert XSS. Encoding the output is just a waste of time. Adding response headers just adds extra useless data to the response.”

What if your validation fails to properly check for XSS or encode as it is writing to the database? Encoding the data as it is coming out of the database will ensure it will be written to the webpage in a proper format. But the encoder could have a bug. Adding response headers will tell the browser to not execute JavaScript that it shouldn’t.

Now the attacker will have to get through three layers of defense, encoding the text as it comes in, encoding the text as it goes and having the browser help us if both fail. Each layer takes time. Hopefully enough time for someone to notice and fix.

I am looking forward to posting some details on how to make your .NET Web Applications more secure.