DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
View Events Video Library
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Integrating PostgreSQL Databases with ANF: Join this workshop to learn how to create a PostgreSQL server using Instaclustr’s managed service

Mobile Database Essentials: Assess data needs, storage requirements, and more when leveraging databases for cloud and edge applications.

Monitoring and Observability for LLMs: Datadog and Google Cloud discuss how to achieve optimal AI model performance.

Automated Testing: The latest on architecture, TDD, and the benefits of AI and low-code tools.

Related

  • Connecting Red Hat Single Sign-on on Openshift to an External Database
  • Row-Level Security: SQL Server vs Gallium Data
  • Reference Architecture: Deploying WSO2 API Manager on Microsoft Azure
  • Database synchronisation techniques - The Good, the Bad, and the Ugly

Trending

  • Architecting a Completely Private VPC Network and Automating the Deployment
  • The Promise of Personal Data for Better Living
  • The Emergence of Cloud-Native Integration Patterns in Modern Enterprises
  • Development of Custom Web Applications Within SAP Business Technology Platform
  1. DZone
  2. Data Engineering
  3. Databases
  4. Demystifying Secure Database Development Myths

Demystifying Secure Database Development Myths

If you work with SQL databases, read on to find out how your favorite security technique could still leave your system vulnerable to SQLi attacks.

Jason Taylor user avatar by
Jason Taylor
·
Jul. 15, 17 · Analysis
Like (1)
Save
Tweet
Share
2.52K Views

Join the DZone community and get the full member experience.

Join For Free

There are a set of best practices that can be used to build security into applications that use databases to send, retrieve, and store data including appropriate input validation and the use of prepared statements. You can also increase database security by suppressing database error messages, reducing the attack surface of the database application, using the least privilege principle to deploy databases, and employing defense in depth – not to mention keeping the database system up‐to‐date with software patches.

However, there a number of common assumptions or mistaken practices that should be debunked because they promote a false sense of security and leave database systems open to attacks. These include:

  • Escaping quotes prevent SQL injection.
  • Database developer security is only required for Microsoft SQL Server.
  • Malicious users must know table names to conduct SQL injection attacks.
  • Functions that require authentication do not require protection.

Myth 1: Quoting Quotes Prevents SQL Injection

The technique of “quoting quotes” (also called “escaping quotes”) is commonly used by developers to prevent SQL injection attacks. This technique works by replacing each single quote with two single quotes. The resulting SQL statement has an imbalance of single quote characters and is rejected by the database engine, thereby preventing SQL injection attacks. This works most of the time, as long as the un-trusted input uses single quotes.

When/if you use this technique, be sure to understand its limitations and that it is not a cure-all for SQL injection attacks. It uses the error-prone blacklist input approach, which checks inputs against a set of known attack inputs or patterns. With this approach, you need to list all possible ‘bad’ inputs—however, the set of all bad inputs is infinite, so it is impossible to block them all. This is why I always recommend using the whitelisting approach – checking inputs against a finite set of expected data formats and patterns.

Using more comprehensive techniques, such as white list input validation and using prepared statements, can effectively reduce the risk of SQL injection attacks.

Myth 2: Database Attacks Only Apply to Microsoft SQL Server

Although Microsoft is not exempt from security problems, this is simply not true. SQL injection is a threat to any database that uses SQL, including non-Microsoft databases such as MySQL, Oracle, and SQLite. For evidence that “database attacks only apply to Microsoft SQL Server” is a myth, open a browser to www.osvdb.org. The Open Source Vulnerability Database (OSVDB) website provides an online searchable record of known vulnerabilities. A quick search for vulnerabilities associated with Oracle, for example, shows that security should be a concern for all database developers, regardless of the platform they are using.

Myth 3: You Need to Know Table Names for SQL Injection

Here is an example of a SQL injection attack that does not require knowledge of the table name. In this example, the malicious user inserts a shutdown command, which on certain databases causes the entire database service to shut down.

Example:

  • SELECT * FROM UsedCars WHERE Year = <Year>
  • Malicious Input #1: 2009; shutdown;
  • Resulting SQL Statement Executed By Database: SELECT * FROM UsedCars WHERE Year= 2009; shutdown;

Myth 4: Functions That Require Authentication Do Not Require Protection

A common myth is that if a database function requires authentication and can be accessed only by trusted users, you need not worry about protecting it. However, this does not take into account that an attacker may gain access to valid user credentials or take over a valid user session; or that a flaw in the application may allow an untrusted third party to interact with the database.

Database security MySQL Microsoft SQL Server Injection

Published at DZone with permission of Jason Taylor, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Connecting Red Hat Single Sign-on on Openshift to an External Database
  • Row-Level Security: SQL Server vs Gallium Data
  • Reference Architecture: Deploying WSO2 API Manager on Microsoft Azure
  • Database synchronisation techniques - The Good, the Bad, and the Ugly

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends: