Select Content Type
What kind of article do you want to create?
Close Window
Article
Schedule
ArticleID
57836 - Click to preview
Canonical URL
https://www.dbta.com/Columns/SQL-Server-Drill-Down/Security-as-an-Afterthought-57836.aspx
Title
StandOut Url
Author(s)
Kevin Kline
Images
Related Articles
Summary
If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Video
<p>If you've read the IT press at all these days, you know that SQL Injection (SI) attacks are very common and can be devastatingly effective. In fact, SI attacks-equally easy to execute against Oracle, MySQL, IBM DB2, or Microsoft SQL Server-are among the most common hacks on the Internet today. If a web application runs a relational database on the backend, it can be subject to an SI attack, which ironically, is among the easiest web hacks to prevent.</p><p>While plenty of SI attacks hit SQL Server database, Microsoft has done much to strengthen and reinforce SQL Server's attackable surface area. In fact, in the last couple releases, SQL Server has had fewer security holes and critical flaws than the other leading database platforms. After the SQL Slammer virus of the early 2000s, SQL Server made security a huge aspect of its feature set, and, as a database, is ahead of the pack in terms of security features. It is SQL Server <em>users</em>- its DBAs, developers, and IT managers-who bear the blame for security hacks that succeed against their systems.</p><p>So what is SI? An analogy might explain the ease of defending against an SI attack better than a full technical description (For a technical description, visit http://en.wikipedia.org/wiki/Sql_injection). Imagine you're driving home from work and see all the doors and windows open at a neighbor's house. You peek out the window as you lock up for bed that night. All their doors and windows are still wide open. You get ready to leave for work the next morning and see your neighbor driving away with all the doors and windows <em>completely open</em>. A few days later, the house is burglarized. Well, no wonder! They never even shut the door, let alone lock it. They'd probably be safe and secure today if they'd taken that simplest of steps.</p><p>SI is practically the same situation. All it takes to prevent SI is to ensure your web applications test for allowable values in their input fields, and send their own error messages, rather than the default. SI is ridiculously easy to prevent, and if I managed a team where this happened, I'd fire the responsible parties, on both the development and administration teams. We know as much about preventing SI attacks today as we did the very first time they occurred. If it happens to you-just like a burglary in a house where the doors are never shut-you must blame yourself, not the locks on the doors.</p><p>Microsoft has implemented many new and improved security features in the wake of the SQL Slammer virus. Their entire development process for SQL Server includes rigorous security checks. When SQL Server is installed today, most security holes and surface areas have been closed off by default, requiring the DBA to consciously open them up after installation.</p><p>There also are a few best practices to keep in mind. First, as with disaster recovery, you should plan for the inevitable attack ahead of time. To prevent security breaches, ensure that applications and services run with the least possible privileges. Monitor login activity and raise an alarm when too many failed logins occur within a certain time period. Make sure applications run under their own account, not SA, and that guest accounts and the public role are dropped or not available. Finally, disable any system and extended stored procedures on your SQL Servers that aren't explicitly needed to support production operations.</p><p>Remember, SI attacks are common, but they're also very easy to prevent. Don't let it happen to you. You'll have only yourself to blame!</p>
Newsletter Name
Issue Name
Article Type
Article SubType
DBTA E-Edition
November 2009
Columns
SQL Server Drill Down
Please Choose
5 Minute Briefing : Blockchain
5 Minute Briefing: Cloud
5MB: Data Center
5MB: Information Management
5MB: MultiValue
5MB: Oracle
5MB: SAP
Big Data Quarterly Issue
Cloud Strategies
DBTA E-Edition
ExaBriefing
Headlines from AIOUG
IBM LinuxLine
Infrastructure Wisdom
IOUG Storage Systems
Linux Executive Report from IBM
Magazine Issue
Oracle Enterprise Manager
Unisphere Five Minute Briefing
Columns
Editorial
A Wider View
Applications Insight
Big Data Notes
Database Elaborations
DBA Corner
Defining Data
Emerging Technologies
From 30,000 Feet
MongoDB Matters
My View
MySQL Musings
New Directions
Next-Gen Data Management
Notes on NoSQL
Oracle Data Strategies
Oracle Observations
Quest IOUG Database & Technology Insights
SQL Server Drill Down
The Enterprise Environment
The Open DBA
The Philosophy of PL/SQL
Trends and Observations
Categories
Topics
Artificial Intelligence
Big Data
Blockchain
Business Intelligence and Analytics
Cloud Computing
Data Center Management
Data Integration
Data Modeling
Data Quality
Data Warehousing
Database Management
Database Security
Hadoop
Internet of Things
Master Data Management
MultiValue Database Technology
NoSQL Central
Virtualization
×
Authors
×
Search Articles
×
Image Helper
Upload an Image
Name
File
Browse…
Image Resize (width):
90
120
135
250
No resize
Preview (Click image to select)
Select the Image
ID
Image Name