Rob van der Meijden

During the TechEd 2004 I followed some sessions which where covering the security topic. These sessions where the pre-conf day about Writing secure code by David LeBlanc (nice article); Anatomy of a Hack by Jesper Johansson and Windows forms code access security by Juval Lowy.

So what have I learned and what practices can be used within projects for building and deploying secure .NET applications.

Building:

·        Work with security from the beginning of a project. Not on the day before delivering a build but from the start of a project.

·        If security is a high level requirement (it should be) create threat models for the system to be designed. See technet documentation.

·        Make you’re team aware of writing secure code. Train them, show then security flaws, plan code reviews focused on secure code. See the MSDN references at the bottom.

·        Every input can be evil input; check in an early stage if the input complies with the specification.

·        When you use stored procedures to access you’re database you never have to worry about the sql injection syndrome. All the hack examples during the TechEd started with a simple sql injection. More info look at the Sql Injection walktrough

·        Don’t let implementers build application with de administrator account. This way they never have any security problems, use only that security model they need. When there is a problem don’t fix it with the admin account.

·        And even more, never give the testers the administrator account. Test you’re system in an environment which equals the end user.

·        Make use of the .Net runtime security policy for you’re Windows based system. This can either be done by creating them based on the requirements or by using a wizard in de Visual Studio. A policy file can be created within the .Net framework configuration and deployed using the group policy or SMS.

·        Sign you’re application

·        Don’t use sa accounts to connect to you’re database and check if the password is different than a blank J 

·        David LeBlanc has spend more than 3 hours of speaking of secure code in C and C++, he even wrote an SafeInt type instead of the int to solve some overflow issues. Bottom-line: don’t use C or C++ these days unless you have a very good reason to do so, high performance for example.

Deploy and Maintenance:

·        Don’t worry about worms, worry about hackers manipulating you’re internal (salary for example) systems.

·        Most system are like eggshells; hard from the outside and soft from the inside (Jesper Johansson). Don’t think that defending you’re system with a firewall is enough. Many hacks are easy from the moment they pass through a firewall. An very easy way is SQL injection can do this or by leaving a floppy disk at the lounge saying ‘Salary sheet CEO‘, definitely somebody is going to use it and you’re in.

·        When a system seems to be infected/hacked NEVER log on as a domain admin.

·        When you’re using IIS 5 use the IIS lockdown tool which looks at the IIS server and locks down everything you need. This lockdown tool is the result of the OpenHack events.

·        Use the URLScan which can filter the incoming URL requests, it seems to give you also a performance benefit.

MSDN references

·        Writing Secure Code

·        Top Ten Security Tips Every Developer Must Know

More suggestions are welcome.