Voice of the DBA

Category: Editorial

  • SQL Injection, Still?

    It seems as though SQL Injection issues are still around. Attacks from SQL Injection are on the uptick as we begin moving through 2015. As noted in that piece, the constraints put on software developers usually mean that testing and security are the first things to let go when time becomes short. That’s sad, and in some sense, I think this means that we aren’t teaching secure coding early enough to developers, and certainly not often enough.

    I ran across a piece from Kevin Kline that asks why this keeps happening. After all, as Kevin shows, much SQL Injection is easy to prevent. The coding patterns and tools we use are simple to write. There are lots of articles out there that show a variety of techniques you can cut and paste into your code. However there are two big problems that prevent us from eradicating SQL Injection: aging code and bad habits.

    There’s no shortage of code that comes from frameworks and application templates, not to mention naive or ignorant developers. Lots of this code is vulnerable to SQL Injection. Since so many of these existing applications work, there is no great pressure to go back and change them to be more secure. Since data theft may not even be noticed, there are plenty of companies (and technologists) that have no idea their systems are vulnerable.

    The other problem is bad habits. Far too many developers and DBAs have spent years writing insecure code. When they prototype, mock, or quickly knock out code, they often rely on their experience to get work done quickly. And they do this poorly if they aren’t writing in a pattern that prevents SQL Injection. They haven’t updated their templates, tools, or their knowledge in a way that ensures all their future code will be secure.

    Ultimately we as an industry need to take SQL Injection seriously and write better code. Whether you use an ORM, a framework, or anything other shortcut to build applications, if you don’t create secure software, you’re part of the problem.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn. feed

  • Salaries and Experience

    This editorial was originally published on Aug 31, 2010. It is being re-run as Steve is on vacation.

    One of the main reasons that I got into IT was the salary. Honestly, there were relatively few places where I thought I had a skill AND could make good money. I graduated with an economics degree, with the idea that I’d go to Wall Street, follow Gordon Gecko, and work 140 hours a week and make a few million.

    That was until I wrecked my shoulder playing rugby my senior year, realized that I wasn’t invincible, and decided there were more important things than my salary. However I still wanted to have a good living, I had some skills in technology, and I moved in that direction. When I heard that our DBA was making $90k a year at a time when I was making $45k, I decided I should learn more about databases.

    Across the last two decades of my career, I think I’ve been fortunate in my career. It’s been a lot of work, , and a lot of fun. I’ve tried to grow my career, learn new things, and find better opportunities over time and in new positions. I’ve had success, and I’ve found the experience has resulted in higher salaries for me. I founda blog about salaries recently that says it’s not only experience, but also location that matters in terms of salary. That’s probably true, though I think industry, the particular company, and other factors are important as well.

    For most of us, we don’t necessarily want to change locations, but we can do something about our experience. I’ve seen it written before that for people that have 10 years of experience, it could be gained two ways. They could have one year of experience ten times, or ten different years of experience (or some combination). The point is that you should be continually expanding on your experiences, not just relying on skills you learned a long time ago.

    You may or may not be able to get a job that pays you more with more experience. I’d like to think, however, that any investment in improving your skills and learning more about your craft, is never wasted.

    Steve Jones

  • Closer to the Heart

    Most of us take whatever jobs we’re offered. We send out resumes, go through interviews, and often accept the first offer for employment. In fact, I bet most of us rarely have more than one employer to choose from at a time. Perhaps two if we’re looking for a job while still working, but I bet in many situations the current employer isn’t one we’re considering working for in the future.

    What’s more, it seems that many people working in technology can work in a variety of industries. A database that stores sales information for a retail company isn’t managed a lot differently from one that captures inventory information for a manufacturer. I know I’ve worked in the power generation, education, finance, software, and other fields. I’ve found that my job as a DBA or developer hasn’t really changed much. I could work in any of these industries.

    However, I’m sure that most of you have interests and attractions in areas. Perhaps some of you have really enjoyed working with certain data, or there are applications you think you’d enjoy. This week I wanted to ask what might be your ideal field.

    In what industry, or with what data, would you like to work if you had the choice?

    Or perhaps, where do you think you’d have a connection with the technology as well as the business. Imagine that you could choose what data you’d work with, and some employer in that field would offer you a job.

    For me, I think if I had the chance I’d like to work with a professional sports team in the US. In Denver, I’d really be interested if the Broncos, Rockies, or Nuggets needed some technical help. These organizations are starting to use more and more data to analyze their players in order to gain some competitive advantage. I find all the numbers published to be interesting and think it would be a fun job helping to find patterns and meaning in the data.

    Let us know this week where you might want to work.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.2MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Starting a New Job

    I’ve had practice here, and was reminded of this when I ran across this thread on starting a new job. In my career, I’ve had far too many employers. I’d like to think it’s not my fault, but after having double digit jobs, I have to take some of the blame. I’ve often been looking for positions that I expected to last for many years, but something always seems to crop up. Even the jobs I’ve loved have ended sooner than I would have liked.

    As a result, I’ve gotten used to starting new jobs, learning a new environment, and quickly getting familiar with people and processes. I thought of this when I ran across a thread that talked asked about the first few things you should do at a new job. There are some good answers, and it’s worth a read.

    For those of you that start new jobs regularly, or are consultants, do you have a routine? Do you have scripts you bring along? When I saw sp_Blitz presented a few years ago, it seemed like exactly the type of thing you would want to have with you and go through on each instance you encounter. Something that gives you a good overview of how things look. While each environment is different and the configuration and settings will vary, it helps to have a view of the situation you’re familiar with. Even if you don’t change anything, at least you understand how the systems are set up.

    There was a time when I had a complete evaluation routine similar to sp_Blitz and an install that would create jobs for backups and maintenance in a consistent way. I had more a few jobs switch to my way of managing things because it was very efficient. These days, I think I’d use tools that are tried and true, using sp_Blitz, Ola’s backup routine, and @SQLFool’s indexing routine. I wonder if the rest of you have similar preferences.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.4MB) podcast or subscribe to the feed at iTunes and LibSyn.