My first introduction to the Security World of Cruz was during DDD2 back in October 2005. An hour of ’Oh my god… how secure is my code’ and ’Boy, does this guy know his stuff!’. It was the most energetic Session of the day and left me wanting to hear more. When I found out I could attend a two day course run by Dinis I was filled with excitement, but also trepidation that I would be out of my depth, so decided that I must prepare well for the two days. This unfortunately did not go to plan.

Car blew to hose.

RAC could not fix it. Find out course started on Tuesday not on Wednesday. Sunday. Laptop blows it’s graphics card. Decide to take desktop.

Get part for car and spend 4 hours fixing it. Find out VMWare doesn’t run under Vista. Rush of to PC world to find a laptop running XP and finally arrive at the Flying Club for this evenings NxtGenUG Internationalisation meeting. Get home, setup new laptop, get to bed late!

A civilized 09:30 start, an introduction by Dave McMahon we started by introducing ourselves and I was please to see that we did not have that much Security Experience between us. At 09:50 we started in earnest.

We started with Threat Modelling, this is where a small group of people get together and review a system looking for ways that a 3rd party (the hacker) can make money from or disrupt your site. This comes in many forms including Extortion, selling your data/business Intelligence to modifying payment details. One of the students volunteered to describe their business, so that we could find possible attack points. This was an eye-opener as five major issues were discovered in less than an hour, followed by a couple that came out of the woodwork a little later.

Top Tip No. 1 - ‘Think Like a Hacker’

As we all know web sites rely on information being send from the browser to the server. Not only were we shown is how easy it is to view this data, but also how to change it prior to it getting to the server. An example would be the number of attempts a user can have to get their password right prior to the account being locked out. Other methodologies should be used.

Top Tip No. 2 - ‘Slow down responses back to the client once a threshold has been reached’

We all seemed happy that our passwords were stored as Hash values within the database, then Dinis introduced us to Rainbow sites. These sites have encoded the majority of standard passwords, so that if you give them the hash they will provide the password. Use a salt, but don’t store this alongside the hash, keep it somewhere else, preferably on the server based on part of the users details. Don’t have a standard salt for your site.

The Membership Provider (ASP.NET 2.0) does assist in keeping sites secure, however there is an issue with the session cookies. Once a user ‘Logs Off’ the cookie is deleted off the client, but left on the server and could be used by a hacker. Keep a list of valid cookies within your code.

Top Tip No. 3 - ‘If it needs to be encrypted use a 3rd party using public/private keys’

Time to start getting our hands dirty and start to hack into a web site (all legal I must add) using SQL Injection. SQL Injection is where you can insert SQL commands into the textbox’s on a sites form. When this form is submitted the original SQL being performed by the site is overridden by yours, giving you access to all sorts of information and the ability to modify data. Using the sites form this would be a tedious manual method , however we were shown how an application could be written to automate this process and how the contents of the entire database could be extracted within a couple of minutes.

Top Tip No. 4 - ‘Use Parameterised SQL Commands’ they can eliminate SQL Injections.

It was getting late into the day when we started looking at Confusion Type Attacks and to do it we had to go right down into the depths of .NET. This section was extremely technical and meant that we needed to change IL code and reverse engineer the results. This allowed us to get access to the private fields and change their contents. However if you run preverify .NET throws an error, but not the compiler.

Top Tip No. 5 - ’Don’t run in Full Trust. This switches off preverify, run in Partial Trust’

By now it was 18:00 and I was starting to feel a bit punch drunk. Roll on dinner and a good night sleep as I think I’m going to need it for tomorrow.

After the students had a relaxing breakfast, with Dinis working away on his ‘Secure’ laptop we started day two at 09:00 all eager to see what was in store for us today.

It was now time for us to be introduced to some of the tools that can be used to check that your code is secure, at least as far as it can be. This session took most of the morning and one student commented that this section alone was worth the cost of the course. I’ll list some of the tools below: -

1. WebGoat http://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

This is an insecure website that is used to teach you how to build secure web apps. It has over 30 lessons and is a good place to get to grips with web site security.

2. Manager Spy http://msdn.microsoft.com/msdnmag/issues/06/04/ManagedSpy/

This program is provided by Microsoft, and allows you to interrogate a running application. It also shows the true power of reflection.

3. CLRProfiler http://www.aisto.com/roeder/

The King of reflection. Don‘t code without it.

4. Lutz Roeder Reflector http://msdn2.microsoft.com/en-us/library/ms979205.aspx

Another Microsoft tool that allows you to monitor memory usage, garbage collection and possible memory leaks.

5. Fiddler http://www.fiddlertool.com/fiddler/

A great way to see what traffic is going between your computer and the internet.

Top Tip No. 6 - ‘Always run these tools on a virtual PC, for how much trust can you have in them’

Cross side scripting is the process of inserting your own code into the Browser that is to be rendered on the current page, or for use at a later stage. We were shown the damage that could be done and some of the methods used to combat it.

Top Tip No. 7 - ‘Use EventValidation as this will help to combat this issue’

Then we moved onto Web Services and how we can make them secure. The main suggestions were that they are restricted only to the users that require the service and validate data the entry point.

Top Tip No. 8 ‘Consider using the Web Service Extenstions’

The course was about to come to a close and time for us to learn the difference between Full Trust and Partial Trust assemblies and how Code Access Security can be implemented to reduce the attack surface area of your code.

Top Tip No. 9 ‘Implement Code Access Security in your Apps’

By the time we finished it was way past 18:00 and time for us all to head our separate ways. During the drive home I had chance to reflect over the events leading up to the course and the course itself. Was it all worth it? Yep every penny and I would strongly recommend that all developers attend this course regardless of the type of client that they develop. If you don’t know how your code can be attacked you will not do anything to protect against it.

My thanks must go to Dave, John & Rich for arranging the course, but a special thank you must go to Dinis for imparting his knowledge to me.