Back in 1984 I thought I was pretty good at writing programs for my BBC Micro. I could write BASIC programs that worked; I was learning 6502 assembler. I could hack on programs, break copy protection. I definitely knew more than my teachers.
But my brother was able to break my code.
For example, I wrote a simple “football” program for him. The idea was that he’d select two teams and the game would simulate a match and generate some scores.
The opening screen would present a list of teams and let him select them. I thought it would go something like this:
What my brother did, to my surprise, was something like this:
That was a new thought for me; people entering unexpected input! But a good lesson to learn at such an early age. Always validate the input.
This lesson really came into its own in the early days of the ‘net; a
co-worker was really proud of the CGI program he wrote that would allow
stored files to be displayed. He was less happy when I passed ?file=../../../../../../etc/passwd as a parameter :-)
Today a number of these lessons have been formalised into patterns by organisations such as OWASP top ten project. Obviously, today, threats are so much more advanced than the simple problem my brother found 30 years ago. But sometimes just reminding people “don’t trust the client to send good data” is essential; people can be focused on making sure they get an A+ SSL rating but then allow SQL injection attacks through blind trust of supplied input.