igor - Fotolia

Problem solve Get help with specific problems with your technologies, process and projects.

Preventing SQL injection attacks when using outsourced developers

SQL injection attacks continue to plague enterprises. However, performing audit code validation when using outsourced developers can be a challenge. Expert Nick Lewis explains how to prevent these attacks.

A recent Ponemon Institute report claims that while 65% of survey respondents have experienced an SQL injection attack in the past year, few organizations make a concerted effort to prevent them. We outsource a lot of development and struggle to get developers to consistently perform audit code validation during quality assurance (QA). With that in mind, is there anything we can do with limited resources to prevent these attacks?

There are widely available tools that script kiddies use to perform mass scanning for SQL injections (SQLi), so it seems if only 65% of survey respondents experienced a SQLi attack, then 35% of the respondents had ineffective monitoring in their environments to identify the attacks. In other words, virtually every organization is indiscriminatingly targeted by SQLi attacks.

There are a number of questions to ask when you outsource development. First off, are there security requirements in the contract with the outsourced developers? Are there standards these outsourced developers need to follow for secure development lifecycle? Have they been trained on the systems development lifecycle and on how to securely code? Can the outsourced developers be held accountable on flaws in their code? If the answer is "no" to any of these questions, the clauses should be added to future contracts, and existing contracts should be amended to include them.

Regardless of the outsourcers and the answers to these questions, enterprises can still add an SQLi scanner or attack tool to identify SQLi vulnerabilities in the software development process quality assurance cycle and to improve security.

The Open Web Application Security Project has a SQLi prevention cheat sheet to help enterprises and developers thwart attacks. Organizations could even just use the same tools that script kiddies use in their attacks to find potentially vulnerable code or applications. A static code analysis could even be done to audit the code for any SQLi attacks. Once the code has gone to production, a Web application firewall could be used to block potential SQLi attacks or, alternately, there may be functionality in an intrusion prevention system or firewall that could block the attack.

Next Steps

Gain insight into preventing blind SQL injection attacks and learn how validating user input is critical to stopping these threats.

This was last published in October 2014

Dig Deeper on Application attacks (buffer overflows, cross-site scripting)

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

If I were outsourcing my code, I would make sure there were some legal actions to be taken if the developer had flawed software that allowed for a SQLi. I know some companies use outsourcing, we use it very little. Only when there is a crunch for development.

We thoroughly test it in-house, by multiple developers and modify the code if we find any flaws or vulnerabilities. 

Sometimes I wonder if the outsourcing of code leads to the data breaches that are in the news lately. They may have been intentional, knowing some businesses won't fully test the code the purchased, and that allows a back door entry.