Database Security:

Is your data vulnerable?

Presented by: Mary R.Sweeney

Sammamish Software
sweeneyn14@comcast.net

Sammamish Software Services www.sammamishsoftware.com 2005

 Four major areas of Concern

• Server Security
• Database Architecture
• Database Connections
• Table Access

Sammamish Software Services www.sammamishsoftware.com 2005

Securing your database server

• This is the highest importance; if you can’t get

to the data you can’t harm it.
• The database server should not be made
openly available
• No anonymous connections
• Web server and database server should not
be on the same machine!

Sammamish Software Services www.sammamishsoftware.com 2005

 Securing your database server
• Database server should only respond to known IP
addresses.
– If the database is supplying a web server then the
database server should only respond to the web
server’s IP
– If supplying internally then only internal addresses
should be recognized
• Test case?
– Attempt to attach to the database server using an
unknown IP. Attempt this at various times, including
before and after backups and during planned (and
unplanned) component failures.
Use
Useexample
exampleof
of
banking
banking
software
Sammamish Software Services www.sammamishsoftware.com 2005software
 Database/Web Server
Trusted IP address architecture

DMZ

Database server Web server

Sammamish Software Services www.sammamishsoftware.com 2005

 Preventing database access:
More things to consider
• Many strategies for preventing open access
each database and OS has their own
• Some additional things to consider:
– Server account disabling (3 tries and out does
help)
– Kerberos – ticket based authentication system
(Oracle and Windows)
– Role-based security rather than user based
security
– Authentication servers

Sammamish Software Services www.sammamishsoftware.com 2005

 Caution
• Although network security is the first and
most important level of defense, it doesn’t
stop there
• At some point, data is processed in and out of
the system and it is at this point your data is
vulnerable

Sammamish Software Services www.sammamishsoftware.com 2005

 Database Architecture
• Database architecture should be properly coordinated
with hardware/network architecture
– Doesn’t always get considered with respect to security
– Example: web databases can have secure interfaces to a
main database residing on a different server
– Security is about layers. Provide more layers between your
data
• Employ common sense:
– Internal databases should not be placed on the same server
as customer/client databases e.g.., web databases

Sammamish Software Services www.sammamishsoftware.com 2005

 Consider multiple unpredictable
clients/input
Administrator’s app Cookies
Registry Input
Temp files
Company Intranet Interoperability

Downloads from
Client/Server Database server(s)
other systems

Hidden users
Sammamish Software Services www.sammamishsoftware.com 2005
 Detailed Database Architecture
• Logical design should be modified to support
secure tables for sensitive information
• Stored procedures and views should be used
to limit access to the underlying database
structure
– User permissions for applications can be assigned
to stored procedure and views so that users need
not have access or even knowledge of the
underlying database structure

Sammamish Software Services www.sammamishsoftware.com 2005

 Logical Design Split table

Sammamish Software Services www.sammamishsoftware.com 2005

 Referencing tables with Views and
Stored Procedures

Create Procedure HRProc (EmpID int)

as
Begin
select Employeeid, Firstname, Lastname,
Create View EmpView as basesalary, num_of_deps
Select Firstname, Lastname, PrimaryPhone from Employees e, HR h
From Employees; where e.Employeeid = h.Employeeid and
Employeeid = @EmpID;
Grant Select on Empview to WebUser End;

Grant Select on HRPRoc to HRUser

Sammamish Software Services www.sammamishsoftware.com 2005

 Secure user connections
• Design proper access
– This may seem like a given but is very common to
give too much authority to basic users. Why?
• Developers use full permissions to develop and then if
the system breaks when they limit permissions the
incentive is to complete the project quickly letting full
permissions stand.
• Neophyte developers with not enough training
• Permissions should be effected down to the column
level; users should have read-only permissions to most
data

Sammamish Software Services www.sammamishsoftware.com 2005

 Secure User Connections
Test cases

• Test Cases
– Test application security using all different
available security levels. Attempt activities outside
the range of a normal user
– Even normal update capability; ie., for users to
modify quantities on an order, can allow for the
ability to improperly update other things!

Sammamish Software Services www.sammamishsoftware.com 2005

 SQL Injection
• Difficult to thoroughly check for SQL Injection
vulnerability
– Development teams are notoriously inconsistent;
some areas may not be vulnerable while others
are
– Answer: test every area for data entry.
– Assume if you don’t then the hacker will

Sammamish Software Services www.sammamishsoftware.com 2005

 Example: SQL Injection Attacks
ABC Corp. Login Form:

Username: ‘or 1=1; drop table user; --

Password:

Turns this query:

Select username from user where username = ‘someuser’
and pass = ‘somepass’
Into this query:
Select username from user where username = ‘’ or 1 = 1;
drop table user; -- and pass = ‘’

Sammamish Software Services www.sammamishsoftware.com 2005

 Test cases for SQL Injection

Sammamish Software Services www.sammamishsoftware.com 2005

 Test cases for Data security
• Testers must be familiar with current hacking
techniques
• Use Penetration testing techniques
• Tools are available (AppDetective, etc.)
• Try SQL Injection in all areas
– Create a dummy table and attempt to insert into it,
update it or even delete it
Sweeney:
Sweeney:
Often
OftenI Itell
tellmy
mystudents
studentswe wecan
canonly
onlydodoeffective
effectivefield
fieldlevel
levelintegrity
integritytesting
testingon
onhigh
high
priority
priorityareas
areasbecause
becauseofoftime
timeconstraints.
constraints.However
Howeverthisthisthinking
thinkingisisexactly
exactlythe
thethinking
thinking
that
that the hacker exploits. They look for underused portions of the application forsecurity
the hacker exploits. They look for underused portions of the application for security
holes. Sammamish
Good Software Services
security-focused testers www.sammamishsoftware.com
do this too. 2005
holes. Good security-focused testers do this too.
Why should test professionals know DB
Basics?
• Not all members of a test team need to know it
– Need at least one person on the team who is DBA
level
• Those team members assigned to verify data
transformations within the application MUST
know it!
– Can look for and find more common design problems
– Can speak intelligently about how to address/fix data
issues

Sammamish Software Services www.sammamishsoftware.com 2005

 Why should test professionals know
RDBMS Design basics?
• Inadequate knowledge of Relational db design
fundamentals leads to logic errors and very
common bugs in systems
– Basic normalization principles can and should be tested
but aren’t -- because most testers have no idea what
that is!
• Effective DB testers should be able to uncover
design problems quickly
• Able to recognize neophyte developer errors
easily
– A test pro with DB background can uncover poor design
bugs by adding a number of basic tests
Sammamish Software Services www.sammamishsoftware.com 2005
 Why should test professionals know
SQL Basics?
• SQL statements can be used to:
– Verify SQL statements used within the app
– Insert and remove test data
– Verify existence of data integrity on the DB
– Reveal corrupt data
• Duplicate data
• Orphan records
– Create and run automated tests in the
DB backend
– Create test cases to protect against common DB
hacks; we must be as smart as hackers!
Sammamish Software Services www.sammamishsoftware.com 2005
 Review/Summary
• Server Security
• Database Architecture
• Database Connections
• Table Access

• Many of these things have been around awhile

and yet still are unused! Many systems still
have System Administrator accounts with no
passwords! Don’t let your systems be easily
broken into.

Sammamish Software Services www.sammamishsoftware.com 2005

 Recommendations
• When planning systems testing don’t forget to
target the database, looking at both
– architecture and
– employing focused testing
• Stay abreast of bug track web sites to find
holes in your security testing
– www.securityfocus.com/archive
– www.ntbugtraq.com

Sammamish Software Services www.sammamishsoftware.com 2005

 References

• Database Security -- Common-sense Principles

(Paper) By Blake Wiedman
www.governmentsecurity.org
• Litwin, Paul. www.deeptraining.com
• SQL Injection Attacks DevArticles.com
– www.devarticles.com/art/1/138
• Whitaker/Thompson. How to Break Software
security

Sammamish Software Services www.sammamishsoftware.com 2005