I am sorry to tell you that you AND your collegues are (probably) not producing secure code here. If there is one rule for server security it's this:

Never trust the client

No matter how hard you filter and check the input in your client program, there is in fact no way for you to be sure the client hasn't been compromised. Think for instance about an HTML form with javascript checks on the input. Anyone can turn javascript off, write an anternative form, write an alternative client with LWP etc etc etc. This is (at least theoretically) true for every client program.

You MUST test the input on the server side if you are going to do any potentionally dangerous things with it.

To answer your question though, the best way to demonstrate a security hole is to demonstrate exploiting it. Gather your coworkers around, enter some invalid data and see the system crash (or worse). Good security is not something that is achieved with only good intentions, it takes real effort and studying to do it right.

A very good guide to the various problems in this area can be found at the Open Web Application Security Project. Read it and let others read it. At the very least it will give your coworkers some feel for the variety of the problems.

-- 
Joost       downtime n. The period during which a system
            is error-free and immune from user input.
[download]