Application Security // Database Security
11/15/2012
00:32 AM
Connect Directly
RSS
E-Mail
50%
50%

The Root Of All Database Security Evils = Input

Input validation and prepared SQL statements crucial to preventing SQL injection attacks

Some of the most embarrassing database breaches of the past few years boil down to one big root cause: poor input validation and sanitization imposed by developers who create Web applications that tap into these data stores. In the rush to get code compiled and out the door, developers create input fields that allow users to type in anything they want. That's fine for most users who just need to type in their usernames, a search term, or an address and phone number. But when the bad guys get their hooks into these unchecked input fields, they're one step closer to hacking the database.

"User input is the root of all evil," says Trevor Hawthorn, CTO for security consultancy Stratum Security. "Ultimately, user input in some way, shape, or form makes its way to the database, and so where that could spell trouble is if a user submits input to a Web application that is then interpreted by the database as database commands rather than what it is -- user input."

[Hackers fixate on SQL injections--CSOs, not so much. See The SQL Injection Disconnection.]

According to Hawthorn, SQL injection is the "800-pound gorilla" when it comes to input-related problems.

As Bill Karwin, principal consultant for Percona, explains, this most-widespread security risk on the Internet is essentially a coding gaffe where the developer "interpolates untested content into SQL queries," giving malicious users the tools to type SQL queries into input fields to directly interact with the database without the application ever acting as a filter.

"Developers should make sure their code never executes user input as code," Karwin warns.

Here's why: With that kind of power in the hands of a knowledgeable attacker or even an unknowledgeable one using an automated SQL injection attack tool like Havij, any outside user can input commands that will allow them to retrieve data from the database or add content to a database. This opens up the possibility not only of theft, but also adding malware into a database that powers a website so that it is serving up malicious content to users, or even adding content to something like a story on a news website, Hawthorn says.

For example, one client that his company serviced ran into a situation where a public policy organization had messaging on its site that was diametrically opposed to its policy positions.

"They were essentially lobbying against themselves, and nobody noticed it for quite a while," he says. "That was a case where it was a SQL injection vulnerability that allowed someone to make just a couple of crucial changes."

Experts agree that a big reason why so many SQL injection vulnerabilities remain out there in the wild is because developers only assume their users will type inputs with good intentions.

"From a security professional's perspective, a good programmer will sanitize all data sent to the server, aggressively fuzz their input fields, and constantly patch their components," says Dylan Evans, vice president of operations for Reveal Digital Forensics and Security. "However, from the programmer's perspective, these concerns may not reach a high priority. The vast majority of Web programmers are familiar with SQL injection -- and its sibling, cross-site scripting -- on a conceptual level. However, understanding why something is dangerous and actively preparing for that danger are two different issues."

Part of that preparation is to not only test and plan for typical use cases, but also those atypical abuse cases. It's the only way that organizations will be able to effectively stamp out SQLi attacks like the one that hit Adobe this week, experts say.

"If you filter user inputs to only respond to known queries, you are golden, but too many Web applications trust the unknown user's input," says Mark Goudie, managing principal for the RISK Team at Verizon Enterprise Solutions. "Bad people do bad things with user input and [then] they can access all of your database."

First and foremost, Hawthorn says, developers need to be aware of how data comes into their application.

"Understand where your inputs are, how people could abuse them, and what would happen if things were to go seriously wrong," he says, explaining that one of the biggest best practices developers should strive to implement is whitelisting input as much as possible.

"Whitelist the types of content you are expecting for a given input," he says.

So, for example, a phone number input box shouldn't accept letters or apostrophes. Hawthorn says he understands that, in many cases, this may not always be feasible, particularly as more sites are built with social features that allow for greater freeform user input functionality. In these cases, developers should seek to use prepared SQL statements so that user input is never entered into the database as code.

"So if I enter my username as ' or 1=1, what the application should do is reach back into the database and say, 'Do I have a user name ' or 1=1 ?' So what it should do is look in the database for literally the characters that were put in," he says. "That's a good way to solve most of your input validation-based database challenges."

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
matcohen
50%
50%
matcohen,
User Rank: Apprentice
11/21/2012 | 12:15:45 AM
re: The Root Of All Database Security Evils = Input
It's sad that years after the SQL and
Blind SQL Injection attacks were crated, so many web applciations are
still vulnerable.

Best,

Matthew Cohen

www.ntobjectives.com
-
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-2963
Published: 2014-07-10
Multiple cross-site scripting (XSS) vulnerabilities in group/control_panel/manage in Liferay Portal 6.1.2 CE GA3, 6.1.X EE, and 6.2.X EE allow remote attackers to inject arbitrary web script or HTML via the (1) _2_firstName, (2) _2_lastName, or (3) _2_middleName parameter.

CVE-2014-3310
Published: 2014-07-10
The File Transfer feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center does not verify that a requested file was an offered file, which allows remote attackers to read arbitrary files via a modified request, aka Bug IDs CSCup62442 and CSCup58463.

CVE-2014-3311
Published: 2014-07-10
Heap-based buffer overflow in the file-sharing feature in WebEx Meetings Client in Cisco WebEx Meetings Server and WebEx Meeting Center allows remote attackers to execute arbitrary code via crafted data, aka Bug IDs CSCup62463 and CSCup58467.

CVE-2014-3315
Published: 2014-07-10
Cross-site scripting (XSS) vulnerability in viewfilecontents.do in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote attackers to inject arbitrary web script or HTML via an unspecified parameter, aka Bug ID CSCup76308.

CVE-2014-3316
Published: 2014-07-10
The Multiple Analyzer in the Dialed Number Analyzer (DNA) component in Cisco Unified Communications Manager allows remote authenticated users to bypass intended upload restrictions via a crafted parameter, aka Bug ID CSCup76297.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Marilyn Cohodas and her guests look at the evolving nature of the relationship between CIO and CSO.