Application Security
6/10/2014
06:06 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
100%
0%

SQL Injection Attacks Haunt Retailers

Only about a third of companies have the ability to detect SQL injection attacks, a new Ponemon report finds.

Retail and other industries that accept payment cards for transactions say the infamous SQL injection attack is either intensifying or remaining status quo.

In a new Ponemon Institute report on SQL injection and the recent massive retail breaches at Target, Michaels, and other big-box stores, some 53% of respondents say they believe SQL injection was one element of these high-profile breaches, where sensitive and confidential customer information was stolen.

Nearly half say SQL injection attacks are occurring at the same rate as always, while 38% say these attacks are increasing. Just 13% of the nearly 600 respondents say SQL injection attacks are decreasing.

"SQL injection still exists and doesn't seem to be" abating, says Larry Ponemon, chairman and founder of the Ponemon Institute, which published the new report today. The report, which was commissioned by DB Networks, follows an April report by Ponemon that found SQL injection attacks take two months or more to clean up, and some 65% of organizations of all types have been hit by a SQL injection attack in the past 12 months.

Verizon's famed Data Breach Investigations Report (DBIR), published in April, showed that SQL injection was used in 80% of the attacks against retailers' Web applications.

"Even though it has been around for awhile and it seems like you'd expect the security world to line up and solve the problem [of SQL injection]... you don't see that happening," Ponemon says.

SQL injection was one of the weapons used in the attack on Target, he says.

"In the case of Target, they [the attackers] got PII that was not on any credit card. That was a database breach," says Michael Sabo, vice president of marketing at DB Networks, which sells behavioral analysis software for database security.

"And in all cases of major retailers [breached recently], all POS terminals in the organizations were breached with the malware. It would be highly unlikely the attacker went to each POS terminal," he says. Once they stole credentials, the Target attackers set up a POS software distribution system of their own and performed a SQL injection attack from inside Target, Sabo says.

About 34% of the organizations surveyed in the report say they have tools or technologies set to detect a SQL injection attack, and only about 12% scan their third-party software for SQL injection flaws. "The general view by many is that they are buying enterprise-grad software," Ponemon says, so scanning isn't needed.

"The nirvana would be continuous scanning" of databases, he says, but only 20% of the organizations in the report do so. "Nearly half don't scan for active databases, or scan irregularly," he says.

That, says Sabo, appears to have been Target's downfall. "In the case of Target, the attackers were able to stand up their own servers inside Target's systems and see the data they were stealing. But Target had no visibility into that," he says.

Some 65% of respondents pointed to continuous monitoring of databases as a way to prevent such retail breaches; 56%, advanced database activity monitoring; 49%, database encryption; 45%, chip and pin payment cards; and 39%, data leakage prevention technology.

Nearly 20% of the respondents in the Ponemon report were from the financial services industry; 12% from the public sector; 10% from retail; 9% from health and pharmaceuticals; 8% from services; 7% from industrial; and 6% from consumer products.

Ponemon's "The SQL Injection Threat & Recent Retail Breaches" report is available here for download. 

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Randy Naramore
100%
0%
Randy Naramore,
User Rank: Ninja
6/11/2014 | 4:38:46 PM
Re: Colleges not teaching security
True statement, secure coding needs to be first and foremost on everyone's mind. 
Christian Bryant
100%
0%
Christian Bryant,
User Rank: Ninja
6/11/2014 | 1:15:11 PM
Re: Colleges not teaching security
@Robert McDougal

Absolutely agree.  Anecdote:  Worked for a company where the developers were old-school C coders.  Started incorporating C++ libraries and a shift was made to code in C++ - not the first language of these guys.  Our test team had a talented hacker on it who tore through every release that had C++ code and punch holed in every possible place, returning the apps back daily with exploit notes.  The coders were dumbfounded but thankful.  They sat with this tester (who was not a programmer, just a great researchers and hacker) and took notes, experimented, and hardened the code.  Bottom line, if you get good at breaking your own code, your own apps, you can identify where you need to adjust your development approach to produce more secure programs.

 
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
6/11/2014 | 10:33:51 AM
Colleges not teaching security
In my experience, it appears that colleges are not teaching secure coding techniques to developers.  Instead it appears the focus is on how to create applications quickly rather than securely.

Many developers do not fully understand the full nature of SQL injection attacks.  Perfect example that I see often is that after I discover a SQL injection vulnerability I am told that I must be mistaken because they use input validation.  What they are missing is that a black list is not true input validation.  Why?  For example, If a program black lists the tick character (') that doesn't mean I can't still use it.  Sure this statement wouldn't work (' or '1'='1' --) but if I encoded the tick like this it would work just fine (%27%20%6F%72%20%27%31%27%3D%27%31%27%20%2D%2D).  In this case a better way to handle input validation is to use a white list, meaning only accept characters on the list rather than having to specify every character not allowed.

This is only one small example of SQL injection developer shortcomings, I have seen dozens of other trends.  Bottom line is that we need our colleges to put a priority on teaching secure coding practices.
Register for Dark Reading Newsletters
Partner Perspectives
What's This?
In a digital world inundated with advanced security threats, Intel Security seeks to transform how we live and work to keep our information secure. Through hardware and software development, Intel Security delivers robust solutions that integrate security into every layer of every digital device. In combining the security expertise of McAfee with the innovation, performance, and trust of Intel, this vision becomes a reality.

As we rely on technology to enhance our everyday and business life, we must too consider the security of the intellectual property and confidential data that is housed on these devices. As we increase the number of devices we use, we increase the number of gateways and opportunity for security threats. Intel Security takes the “security connected” approach to ensure that every device is secure, and that all security solutions are seamlessly integrated.
Featured Writers
White Papers
Cartoon
Current Issue
Dark Reading's October Tech Digest
Fast data analysis can stymie attacks and strengthen enterprise security. Does your team have the data smarts?
Flash Poll
DevOps’ Impact on Application Security
DevOps’ Impact on Application Security
Managing the interdependency between software and infrastructure is a thorny challenge. Often, it’s a “developers are from Mars, systems engineers are from Venus” situation.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-0619
Published: 2014-10-23
Untrusted search path vulnerability in Hamster Free ZIP Archiver 2.0.1.7 allows local users to execute arbitrary code and conduct DLL hijacking attacks via a Trojan horse dwmapi.dll that is located in the current working directory.

CVE-2014-2230
Published: 2014-10-23
Open redirect vulnerability in the header function in adclick.php in OpenX 2.8.10 and earlier allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the (1) dest parameter to adclick.php or (2) _maxdest parameter to ck.php.

CVE-2014-7281
Published: 2014-10-23
Cross-site request forgery (CSRF) vulnerability in Shenzhen Tenda Technology Tenda A32 Router with firmware 5.07.53_CN allows remote attackers to hijack the authentication of administrators for requests that reboot the device via a request to goform/SysToolReboot.

CVE-2014-7292
Published: 2014-10-23
Open redirect vulnerability in the Click-Through feature in Newtelligence dasBlog 2.1 (2.1.8102.813), 2.2 (2.2.8279.16125), and 2.3 (2.3.9074.18820) allows remote attackers to redirect users to arbitrary web sites and conduct phishing attacks via a URL in the url parameter to ct.ashx.

CVE-2014-8071
Published: 2014-10-23
Multiple cross-site scripting (XSS) vulnerabilities in OpenMRS 2.1 Standalone Edition allow remote attackers to inject arbitrary web script or HTML via the (1) givenName, (2) familyName, (3) address1, or (4) address2 parameter to registrationapp/registerPatient.page; the (5) comment parameter to all...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Follow Dark Reading editors into the field as they talk with noted experts from the security world.