SQL Injection Attacks – DunDDD 2012

Examples

The examples were run against a copy of the Adventure Works database.

Required Tables

For the Second Order Demo you need the following table added to the Adventure Works database:

CREATE TABLE [dbo].[FavouriteSearch](
	[id] [int] IDENTITY(1,1) NOT NULL,
	[name] [nvarchar](128) NOT NULL,
	[searchTerm] [nvarchar](1024) NOT NULL
) ON [PRIMARY]

GO

Slide Deck

The slide deck is available for download in PDF format.

Further Reading

During the talk I mentioned a lesson from history on why firewalls are not enough.

I also showed XKCD’s famous “Bobby Tables” cartoon, and also a link to further information on dynamic SQL in Stored Procedures.

More information about the badly displayed error messages can be found amongst two blog posts: What not to develop, and a follow up some months later.

I wrote a fuller article on SQL Injection Attacks that you can read here although it is a few years old now, it is still relevant given that SQL Injection Attacks remain at the top of the OWASP list of vulnerabilities.

DDD Belfast Parallelisation Talk

Examples

Here are all the examples from Saturday’s introductory talk on Parallelisation at DDD Belfast.

Slide Deck

You can download the slide deck here.

DDD South West Parallelisation Talk Overview

Examples

Here are all the examples from Saturday’s introductory talk on Parallelisation at DDD South West 2011.

Slide Deck

The slide deck is also available as a PDF file (15.9 Mb)

Parallelisation Talk examples – Cancelling Tasks

This example showed what happens when tasks are cancelled. In this example, some tasks will be able to run to completion, others will be cancelled and other won’t even get a chance to start because the cancellation token was signalled before the task gets a chance to start.

Here is the code for the cancellation example shown in the talk

class Program
{
    static void Main(string[] args)
    {
        const int numTasks = 9;

        // Set up the cancellation source and get the token.
        CancellationTokenSource tokenSource = new CancellationTokenSource();
        CancellationToken token = tokenSource.Token;

        // Set up the tasks
        Task[] tasks = new Task[numTasks];
        for (int i = 0; i < numTasks; i++)
            tasks[i] = Task.Factory.StartNew(() => PerformTask(token), token);

        // Now the tasks are all set up, show the state.
        // Most will be WaitingToRun, some will be Running
        foreach (Task t in tasks.OrderBy(t => t.Id))
            Console.WriteLine("Tasks {0} state: {1}", t.Id, t.Status);

        // Give some of the tasks a chance to do something.
        Thread.Sleep(1500);

        // Cancel the tasks
        Console.WriteLine("Cancelling tasks");
        tokenSource.Cancel();
        Console.WriteLine("Cancellation Signalled");

        try
        {
            // Wait for the tasks to cancel if they've not already completed
            Task.WaitAll(tasks);
        }
        catch (AggregateException aex)
        {
            aex.Handle(ex =>
            {
                // Handle the cancelled tasks
                TaskCanceledException tcex = ex as TaskCanceledException;
                if (tcex != null)
                {
                    Console.WriteLine("Handling cancellation of task {0}", tcex.Task.Id);
                    return true;
                }

                // Not handling any other types of exception.
                return false;
            });
        }

        // Show the state of each of the tasks.
        // Some will be RanToCompletion, others will be Cancelled.
        foreach(Task t in tasks.OrderBy(t => t.Id))
            Console.WriteLine("Tasks {0} state: {1}", t.Id, t.Status);


        Console.WriteLine("Program End");
        Console.ReadLine();
    }

    static void PerformTask(CancellationToken token)
    {
        try
        {
            // The loop simulates work that can be cooperatively cancelled.
            Console.WriteLine("Task {0}: Starting", Task.CurrentId);
            for (int i = 0; i < 4; i++)
            {
                // Check for the cancellation to be signalled
                token.ThrowIfCancellationRequested();

                // Write out a little bit showing the progress of the task
                Console.WriteLine("Task {0}: {1}/4 In progress", Task.CurrentId, i + 1);
                Thread.Sleep(500); // Simulate doing some work
            }
            // By getting here the task will RunToCompletion even if the
            // token has been signalled.
            Console.WriteLine("Task {0}: Finished", Task.CurrentId);
        }
        catch (OperationCanceledException)
        {
            // Any clean up code goes here.
            Console.WriteLine("Task {0}: Cancelling", Task.CurrentId);
            throw; // To ensure that the calling code knows the task was cancelled.
        }
        catch(Exception)
        {
            // Clean up other stuff
            throw; // If the calling code also needs to know.
        }
    }
}

 

Here is the output of the program (your results may vary):

Task 1: Starting
Task 1: 1/4 In progress
Task 2: Starting
Task 2: 1/4 In progress
Tasks 1 state: Running
Task 3: Starting
Task 3: 1/4 In progress
Tasks 2 state: Running
Task 4: Starting
Task 4: 1/4 In progress
Tasks 3 state: Running
Tasks 4 state: Running
Tasks 5 state: WaitingToRun
Tasks 6 state: WaitingToRun
Tasks 7 state: WaitingToRun
Tasks 8 state: WaitingToRun
Tasks 9 state: WaitingToRun
Task 1: 2/4 In progress
Task 2: 2/4 In progress
Task 3: 2/4 In progress
Task 4: 2/4 In progress
Task 1: 3/4 In progress
Task 2: 3/4 In progress
Task 4: 3/4 In progress
Task 3: 3/4 In progress
Task 1: 4/4 In progress
Task 2: 4/4 In progress
Task 4: 4/4 In progress
Task 3: 4/4 In progress
Task 5: Starting
Task 5: 1/4 In progress

To this point the tasks have been given a chance to operate normally. The tasks that have started are outputing to the console their progress. The main thread reports on the state of the tasks and shows tasks 1 to 4 are Running while the remainder are WaitingToRun. After a while the scheduler decides to start task 5.

Next the tasks are going to be cancelled.

Cancelling tasks
Cancellation Signalled
Task 1: Finished
Task 2: Finished
Task 4: Finished
Task 3: Finished
Task 5: Cancelling

When the cancellation token is signalled the tasks have to cooperate. Tasks 1 to 4 are too far gone and will run to completion. Task 5, which was only just started, cooperates with the cancellation request and writes that it is cancelling. No waiting tasks are started.

In the main thread, the control is blocked until all the tasks have either finished or cooperate with the cancellation request. Once the WaitAll unblocks the program handles any cancelled tasks in the catch block.

Handling cancellation of task 9
Handling cancellation of task 8
Handling cancellation of task 7
Handling cancellation of task 6
Handling cancellation of task 5

Tasks 6 to 9 never got a chance to start. Task 5 was started, but was cancelled. Therefore task 5’s cancellation can be handled inside the task and outside it. Different clean up may be required in each place.

Finally, the program lists the end state (See also: Task state transitions) of each of the tasks:

Tasks 1 state: RanToCompletion
Tasks 2 state: RanToCompletion
Tasks 3 state: RanToCompletion
Tasks 4 state: RanToCompletion
Tasks 5 state: Canceled
Tasks 6 state: Canceled
Tasks 7 state: Canceled
Tasks 8 state: Canceled
Tasks 9 state: Canceled
Program End

When writing code to handle cancelled tasks, watch out for this gotcha that can trip you up if you are not careful.

DDD South West 3

I’ll be speaking at DDD South West 3 this year. My talk on Parallelisation (“Parallel… Parallelise… Pallar… Doing stuff at the same time in .NET 4.0”) was voted onto the agenda.

.NET 4 has some very nifty features to aid the creation of multiple threads of operation. In this talk I’ll be introducing those features and demonstrating what they can do for you, how you can benefit… And importantly, what you shouldn’t do if you want to maintain your sanity. I’ll also be doing my best work out how to correctly pronounce "parallelisation" by DDD South West.

If you are interested in an introduction to Parallelisation in .NET 4 then it would be a great opportunity to learn more about it.

Incidentally, if you can’t make it to Bristol I’ll be doing the talk at DDD Scotland 2011 in May. And if you can’t wait at all then just check out the Parallelisation tag on my blog for a number of articles on the subject or the overview from the talk I did at Scottish Developers last night.

DDD Scotland: The feedback

I’ll be standing down as chairman of Scottish Developers shortly. I’m not leaving, I’m just looking for a different role within the user group. But as I’m hanging up that particular hat I felt I would add my own personal feedback to the feedback we have received over the last three DDD Scotland events.

On the whole the DDD events in Scotland have been exceptionally well received, especially considering the amount of polish in the main DDD events that happen in Microsoft’s UK HQ in Reading. I suppose from my perspective, sitting on the inside, seeing exactly how it is hanging together I’m always amazed that the feedback is so positive. It is a testament to all the other organisers, speakers and helpers on the day that help keep the event running smoothly.

That said, I feel there are some people that are not fully aware of what goes into organising this event, and on what kind of a budget that we manage it. The speakers are not paid, they volunteer their time, travel, and accommodation expenses.

What makes a DDD event?

The goals for DDD events, as a whole are:

  • The event is free to delegates
  • There are no marketing talks.
  • No speakers from Microsoft.
  • The sessions are voted on to the agenda prior to the event.

You don’t have to aim for everything on this list, and at DDD Scotland we didn’t for various reasons.

We do our best to ensure that it is free to delegates. And we’ve managed that three years running and we will continue to do that for as long as we can.

What follows is some information about how we run the events based on the feedback we have received. I hope this gives you a little insight in to the event. We have received other feedback too that we will be acting upon to improve the event, and if possible we will act on the feedback below to improve things too. I just really wanted to get over the constraints we were running under so you didn’t think that after three years we weren’t listening. We do value all feedback.

The event is “not very well advertised”

We have no advertising budget so we use social media such as blogs, twitter and the like to get the word out. However, even with no advertising we were still oversubscribed. The event “sold out” in 15 days, 3 hours and 35 minutes. After that it went to a waiting list. At its peak there were 88 people on the waiting list.

“Tons of people who signed up didn’t come, maybe the people on the waiting list should the get the spaces of the people who didn’t turn up.”

We do our best on this count. If people realise they cannot come they can unregister which means the website will invite someone on the waiting list along. However, if someone doesn’t want to go and they also don’t unregister then there is little we can do about it.

Over the three years we have run the event we have had a 30%-33% drop out rate and we take that into account when allowing people to sign up. For example, this year we allowed 280 people to sign up before the waiting list was activated, in the end we had 188 delegates turn up on the day. We were aiming for 200 delegates, the same as last year. Last year we had 176 turn up.

In the 24 hours prior to the event the waiting list dropped by 60% allowing nearly 50 people that otherwise would not have had the opportunity to go a chance to get to the event.

“As you go feedback [is] better than a few days later”

This is interesting. There is a debate between some of the various DDD organisers as to which is better: online feedback after the event or paper based during the event.

I can’t say which provides better quality feedback. However, my particular take is that I want to get feedback to the speakers as quickly as possible. The sooner a speaker gets feedback the quicker they can see issues they may have and resolve them, or the quicker they can see what is working or what people appreciate about their presentation.

I also feel that when I get asked for feedback immediately I have a better recollection of what I’m feeding back on. If I wait a couple of days the memories are fading and I won’t recall something that would have helped the speaker improve.

We did a little experiment, with one of the speaker’s permission. He happened to run the same session at DDD8 in Reading as well as at DDD Scotland this year. We compared the feedback he got on line for DDD8 versus the paper feedback he got from DDD Scotland. Roughly the same percentage of the audience filled in feedback, of those that did, roughly the same percentage filled out comments (which is more valuable to the speaker than the raw ratings do). However, where there was a significant difference was that the amount that was written in the freeform feedback was greater online… Perhaps, as developers, we are so used to typing that we can’t write so much these days. But then, was all that extra written material an increase in quality as well as quantity?

I guess the debate will continue on that front.

“Make it a 2 day event, do it twice a year (or more)”

I’d love to do that. It is just very hard work for doing it once a year. But the two day idea is certainly something I’d entertain.

Scottish Developers have noticed that if we run day events during the week we do get a slightly different audience so perhaps it would be an excellent way of reaching out to those that can’t make a Saturday.

Incidentally, the Saturday concept was so that the event didn’t impact on the working week so that contractors didn’t lose a days pay and so that the genuinely enthusiastic could continue geeking out at the weekend.

“The lunch break was too short”

The lunch break was 90 minutes. However, we do have activities on during the lunch break to keep people interested. Unlike previous years, this year we only had grok talks – these are short 10 minute talks that represent topics that would not suit a full presentation or a taster for a full length session.

“more in depth” – “not for beginners”

One of the key aspects of DDD events are their democratic nature. Some people may want more elementary sessions while others may prefer more in-depth sessions. But on the day, what is on the schedule was put there by votes. Every single session was voted in. Back up sessions are chosen by votes too. No session appears without having been voted in.

However, that said, when the ash cloud threatened to disrupt the travel plans of most of our speakers we would have been prepared to bend the rules on that one slightly just to be able to put on an event.

“put feedback forms in goodie bag”

Interestingly we did that last year and we didn’t get that many of them back. People either just didn’t realise they were there or forgot about them. Either way, it meant that the feedback was not as comprehensive as we’d have liked.

Putting the feedback forms on the seats works better for us we’ve found.

“The food was a bit disappointing” – “More coffee in breaks” – “Why not run a café?”

Yes, we know. Unfortunately our budget didn’t allow us to stretch any further than we did. The catering bill was by far the largest expense. Since GCU kindly donated the venue to us for the day the catering budget accounted for about 90% of the running costs.

The first year we ran we got feedback decrying the fact that we didn’t put on breakfast. Possibly this was due to some people who were used to the DDD events in Reading which have the backing of a big corporation that can afford, to us, such luxuries.

There is a café on the ground floor at the venue, however it is closed on a Saturday. We did, the first year, look in to opening it up but were told that was not possible.

Ultimately, what we can afford depends on how much sponsorship we can pull in. This year was particularly disappointing. We were lucky in that we still had a sizeable chunk of money left over from last year which, in fact paid for most of the conference this year. Next year we will be starting from a relatively clean slate financially. Simply put, the cupboard is bare.

“Too much Microsoft oriented presentations”

The conference is run as democratically as we can. If you want to see more non-Microsoft oriented technologies then we need more submissions from people offering non-Microsoft oriented sessions and then we need enough people to vote on them.

We also had people asking for more consistent tracks and we do our best to work in a route through the agenda so that a person who has a high level interest in a particular area, say web technologies, has a route from start to end. But ultimately we can only work with what we have, and what we have are sessions that were submitted and a set of votes telling us what people want to see.

For the future

There are a number of points above that we will try to fix, just as soon as we can. For example, we’d love to keep you all properly fed and watered during the day. We’d love to do this more often, have an event every 6 months or a two day event. We’d love to vary the city.

For these things we need more sponsorship. Not just the variety where a vendor gives us free licenses. I’m not saying we don’t want that. We love to get items from sponsors to use as prizes or swag, it keeps things interesting during the day, but ultimately we need things we can use and the bottom line is mostly money.

If you have any ideas that will help up put on a better event, especially if it helps us solve the issues we currently have then please get in touch at support@scottishdevelopers.com

Agenda for DDD Scotland 2010

We have finally got all the speakers confirmed and the agenda sorted out for DDD Scotland 2010. Subject to any last minute changes this is is:

Time

Room A (80)

Room B (40)

Room C (40)

Room D (40)

08:45-09:20

Registration

09:20-09:30

Housekeeping

09:30-10:30

HTML 5: The Language of the Cloud (Craig Nicol)

Contractual Obligations: Getting Up and Running with Code Contracts (Barry Carr)

WCF Data Services (Iain Angus)

Team Foundation Server 2010 for Successful Project Management (Martin Hinshelwood)

10:30-10:40

Break

10:40-11:40

Exception Driven Development (Phil Winstanley)

Real World Application Development with Castle Windsor and ASP.NET MVC 2 (Chris Canal)

Get Going with jQuery (George Adamson)

T4 and How it Can Be Used for Code Generation in Visual Studio 2008/2010 (Rob Blackmore)

11:40-12:00

Break

12:00-13:00

Web Standards are Broken, and it’s Getting Worse (Sebastien Lambla)

A Guided Tour of Silverlight 4 (Mike Taulty)

Commercial Software Development Is Easy, Not Going Bust Is the Hard Bit (Liam Westley)

Defensive Programming 101 (Niall Merrigan)

13:00-14:30

Lunch time: Grok Talks

Lunch time:
Local Open Source Incubator

Lunch time: Sponsor talk

Lunch time: Sponsor talk

14:30-15:30

Getting Started with Behaviour-Driven Development Using Cucumber (Steve Sanderson)

Silverlight – Real World Gotchas (Ray Booysen)

What ASP.NET (MVC) Developers Can Learn from Rails (Paul Cowan)

Developments in MultiCode and Concurrent Programming with .NET 4 (Barry Wimlett)

15:30-15:40

Break

15:40-16:40

Real World MVC Architectures (Ian Cooper)

Cloud Coffee – A Year Developing on Windows Azure (Dominic Green)

C# on the iPhone with Monotouch (Chris Hardy)

Domain Specific Languages – What Are They and Why Should You Care? (Mark Dalgarno)

16:40-17:00

Closing

Developer Day Scotland 2009

Developer Day Scotland - 2nd May 2009There is less than 2 weeks until Developer Day Scotland 2009. There are still a few places left so if you haven’t got one, now is your chance. If you’re still not sure then read on.

Developer Developer Developer events are founded on a number of principles which I think makes it unique and well worth a single day of your time once a year.

DDD events are free. It doesn’t cost you anything to attend. Think of any large conference that you might like to go along to. They costs hundreds of pounds, if not more. Sure, we might not have all the bells and whistles of a big fancy conference, but at the end of the day what do you want out of an event like that? Do you want the glitz and schmaltz or do you want to learn something new?

Speakers from the community. We invite people that have something to say, a story to tell, or an experience to learn from. This year we had 84 session submissions from all sorts of folks and on all sorts of subjects. The majority of these people are real day-to-day software developers or DBAs that actually work for a living.

DDD events are democratic. All the sessions are voted in by the community, so we only put on what people have asked to see. This year the 84 sessions were whittled down to 20. We have 5 database sessions all lined up so if you are a DBA or database developer you won’t miss anything. We also have a route through the agenda for Web Developers. We also have sessions on languages (dynamic and functional languages as well as what’s coming soon in C#), processes and tools (such as scrum, virtualisation, TDD and refactoring) and architecture & patterns (such as MVC, MVVM and AOP)

No Marketing BS. The core philosophy for the sessions are that they contain useful information. Stuff that you can either take back and start using the next day or (if not yet available) to start planning how to move to that technology.

To paraphrase the Lincoln’s Gettysburg address, Developer Day Scotland is of the developer community, by the developer community and for the developer community.

Developer Day Scotland