Karen Nicole Johnson

SQL injections. I recounted my first experience testing with SQL injections last weekend at IWST. About a year and a half ago, I had read an article about SQL injections and tried a drop table command. Within seconds, the DBA came to my desk glaring at me and I learned what I did had caused some serious damage. (I was working in test not prod.)

One of the challenges experimenting with SQL injections is having a website to test. Generically testing against public sites to learn more about SQL injections is both poor form and potentially illegal so finding somewhere to learn is a challenge.

I found a site with a pod cast on SQL injections, show notes, and a hosted website built solely for hacking. A safe playground for learning; check out the hack me site.

In addition to practice time, I’ve been reading up on specific characters in terms of working with SQL injections. Characters that signify the start of a SQL command such as the single quote or the semi-colon.

And characters that instruct the database to comment out or ignore characters after following the special chars. Chars like the # (pound sign), –’(space space single quote) or * / (asterisk slash) are some.

Different databases use different characters to signal so you need to know the specific database type (SQL server, MySQL, etc.)

The more you know about the site and the schema, the more you can go after tables specifically. This means trying to learn without having a site you’re currently testing can be a bit of a dead end.

Ultimately, I’d like to build a little notepad file with a dozen or so injections. I could carry around the notepad file on my flash drive like a utility application and then modify the generic injections to suit the site and schema I’m working with. I suppose this ideal SQL injection test file would have notes on the characters that apply to each database type too so I could be ready to signal a new SQL statement, comment out text, and use wildcards.

(Thanks to Dan Kuykendall for the hack me site. I have somewhere to practice without a glaring DBA.)

Pod slurping, stemming, cloaking, biometric authentication, insecure direct object reference, and mashups are a few of the topics I’ve been reading up on lately. Which of these topics will I need? None immediately.

Knowledge comes and goes. Some technologies enter my life and leave after a short stay and years later I can barely recall them. Some technologies enter my life and stay around.

So the questions become … How fast can I learn? What are the resources I turn to when I have to learn something new? And how deeply can I embrace a new topic?

I suppose what’s cool about the chronic change in my life is not just that I’ve become adaptable or flexible but change has taught me to be a perpetual student.

Someone recently asked me if I was frustrated by learning things and having chunks of my needed knowledge go away. Not at all was my response. Given that I purposely look for projects that will alter the technical environment I’m working in and that I don’t specialize in one industry, it’s nearly a given that some of what I need to know today will be unneeded on my next assignment.

Knowing a little bit about a lot of things is pretty typical in testing. I like change. I feel that change keeps me on my toes.

One thing I’ve had to learn about learning is assessing when I need to deep dive on a topic versus when a skim of information is enough. Deeper knowledge may be helpful but it’s unlikely and impractical to become masterful on many topics. And time is nearly always a factor.

Another thing I’ve learned about learning is how I learn. I know for me, small bites work best. I’ll find one article or one book or one resource and dig for a bit and walk away. I go back for the next chunk of information. Learning for me is iterative.

When I go back for more, I’ll collect multiple resources and skim. If I find one resource – an article, book, website that speaks especially well to me, I’ll go through the entire piece. I look for the resource that makes the most sense to me with no preference to whether the “piece” is a book, article, website or person. Format doesn’t matter – clarity does.

The only exception to learning in small bites is when I corner someone to talk to me and then I soak up as much information as I can for as long as I can get the person to talk to me. If I know a person whose time is in high demand then I find a day and time where we’re less likely to be interrupted and try to get the longest session I can.

I suppose I feel I’ve had many masters in my grasshopper life. And for reasons that I believe may tie back to my previous newspaper reporting days, I can nearly always get people to talk to me.

My resources are usually pretty diverse. There is no one book; there is no one website, no one book store and no one person. I’m ok with that. I think this goes back to the way I feel about software testing which is that testing makes me a seeker.

I’m working on a project that was wrapping up this week. I could feel the tension and excitement building. While part of me is exhausted, part of me loves the finale.

Our final round of testing was conducted in an offsite test lab with restricted access. I heard the remaining people on the project team (located elsewhere) were asking for updates. (One person on the team was designated to provide outside communication.) Apparently our updates were being listened to like a sports playoff.

The final round of testing; it’s our time.

I hear about final reports, post-mortem meetings, and other project wrap-up activities but I don’t hear people talk directly about the final round from the personal perspective of excitement, tension, exhaustion, and exhilaration. Maybe at the end we’re too tired to talk?

There was one moment in particular this week when I looked up from my work and noticed our test lab. Every person and piece of equipment in the lab was humming; everyone knew what to do and how important the work we had to accomplish was. In many ways it has been a “typical” project in that we’d had changes a long the way – in fact an unexpected curve ball thrown at the team just weeks before. But we’d devised a new plan, adjusted, and kept going. And we’d had moments of agitating each other too but that’s also normal. We are human and at times we all annoy each other.

I’ve worked on enough projects to know that this one will be one of the best experiences I’ve been through. The team work has been impressive. It’s a great feeling to work in a highly functioning team and to be part of a successful project.

(I would talk about how interesting and cool the product is but due to NDA restrictions, I will bypass any product details.)

I often think it you can’t deal with the end of a project and all the intensity that typically comes with the end, then testing isn’t for you. I know this sounds rude but it’s true. Testing is continually part of the intensity at the end. Some of us actually enjoy that intensity – at least enough of the time to keep repeating the cycle.

So I have to laugh because I know the next part of the cycle (after I get some sleep, eat a few hot meals, and catch up with friends). I will find new work. I’ll be learning a new product or searching fervently for information on a technology I have limited or possibly no experience with. Why? Because I avoid project work where I’m not learning something new, there has to be at least one challenge in a project to provide that thrill. I’ll go through the process of learning and move onto becoming knowledgeable and more usable. The project will ramp up, the testing will eventually hit the busy cycle, and the end will come again. And so the cycle goes.