IAIK

SQL Injection
Database Security
Invalid Input Data

Karl Scheibelhofer

IAIK

Contents

SQL Injection

Access control

Stored procedures

Prepared Statements

Views

Input validation

Output, errors and side-channels
Security Aspects 2

IAIK

SQL Statement

For example
SELECT * FROM table WHERE name=<input>

<input> is data which comes from an
external source

Web form

Client application

Cookie

Will this external source provide the
correct input? – Maybe not

Security Aspects 3

1
IAIK

Quoting of Input?

Assembling SQL commands as concatenation of
fixed strings and input can enable attackers to input
SQL code instead of data only

Adding quotes around the input is insufficient

Attacker can still input e.g.
xyz’; DROP TABLE users; --

Also requires scanning input data for characters with
special meaning in SQL

e.g. semi-colon (;), quote (‘), comment (--), ...

Quoting of input is error-prone

There are better alternatives

Security Aspects 4

IAIK

Database User – Access Control

Do not connect with administrator rights

Create and use user and group
accounts with required rights only

Usually separated from system accounts

Grant permission to execute certain
operations on tables, views and columns
GRANT privilege ON object TO
user/group

e.g.
GRANT SELECT ON documents TO alice

Security Aspects 5

IAIK

Stored Procedures

Can increase security

Requires careful design and
implementation

Same as on client side

May not prevent SQL injection in all
cases

e.g. if procedure accepts SQL commands

Can hide application logic and database
structure in case of code compromise
Security Aspects 6

2
IAIK

Prepared Statements

Placeholder in SQL command

e.g.
SELECT balance FROM accounts WHERE name=?

Separate code and data

Provide parameters additionally

Also faster (optimization)

Improved type safety

Better portability than stored procedures

Avoids SQL injection
Security Aspects 7

IAIK

Use Views

Views are like virtual tables

Make only those data visible which
users need to see

Create separate views for users or
groups of users

Write-protect view if there is no need for
the user to modify contents

Security Aspects 8

IAIK

Access

Username/password

In addition on per-host basis

Secure connection, SSL, SSH

Do not allow direct access to the
database from client hosts if possible

e.g. only allow application server to
connect

Security Aspects 9

3
IAIK

Statistical Attacks

Assume we can query a database for statistical
information only

e.g. average number of users from Graz or minimum age of
users

We cannot retrieve information about individuals
directly

But we can combine the results of different statistical
queries

This can reveal information about individuals

There is no general approach to counter such attacks

Thus, do not allow externals to submit arbitrary statistical
queries

Security Aspects 10

IAIK

Sensitive Data

Do not store very sensitive data in plain

Passwords, credit card numbers, keys,...

If possible, do not store them at all

For passwords, hashing may be used

Encryption of data

Some database systems include such
features

Security Aspects 11

IAIK

Input Data vs. Code

Do not mix data and code, e.g.

Input data gets part of SQL code

Data and fixed strings are concatenated to
form a command (executable code)

Always separate data channels and
code channels Data

Function stack violates this principle

Function arguments, local variables
Code

Return addresses, stack frame pointer

Security Aspects 12

4
IAIK

Never Trust Input

Never consider input data trusted

Never rely on certain properties of input

Size, format, ...

Always check input

Even authorized users may input invalid data

Intentionally or unintentionally

Faulty client software

Get more privileges

Compromise system integrity, availability,
confidentiality,...

Security Aspects 13

IAIK

Consider all Interfaces

Have a model of your system

e.g. layer model

Specify the interfaces

To the upper layers

User interface, API, network interface, ...

To the lower layers

Libraries, operating system, database, ...

Security Aspects 14

IAIK

Example: Database Application

Ext Appl Browser

External Interfaces
Net API Web API
Database Application
Internal Interfaces
GNU LibC Database
Operating System

Security Aspects 15

5
IAIK

Validate Input

Validate input from external source at runtime

User, network, upper-level application

You cannot fix these parts during development and testing

Ensure correct operation of lower-level components

During development

Read documentation, specification, ... of libraries, operating
system, ...

Do not use trial and error approach

During testing

Get assurance that libraries, components, operating system, ...
behave as specified and documented

Do some limited validation at runtime

e.g. size

Normally, no costly checks at runtime

Security Aspects 16

IAIK

Consider the User’s View

The user only sees your application

Normally the user does not care what
libraries, components, databases, ... your
application uses internally

In case of errors, from the users point of view,
it is an error of the application

And it is the developer’s problem!

The developer selected the underlying parts

The developer has to ensure that these underlying
libraries, components,... work correctly

The user is not interested to hear that it is not your
fault – a solution is required

Security Aspects 17

IAIK

What about Output?

To ensure confidentiality, ensure not to leak
sensitive information, e.g.

Do not write passwords in logs

Do not provide more information than really
necessary

Do not produce noisy systems

Do not return detailed internal error details to the
user

Do not reveal any internals

System structure, type of database, libraries, ...

Switch off banner fields, e.g. HTTP header field showing
version of web server, or hello messages at login
showing detailed information about system

Security Aspects 18

6
IAIK

A Good System...

It does what it needs to do as defined in
the specification

It works correctly if operated according
to the specification

It fails gracefully in case of incorrect
operation or input

It does not do more than specified

It does not leak any information which is
not required for correct operation
Security Aspects 19

IAIK

Avoid...

Introducing “nice” features which “may” be
useful for some users sometimes

Often results in unused features which lead to
security problems
(e.g. debug features)

Using more complex solutions than required

Often leads to unnecessarily complex systems
(e.g. selection of inappropriate technologies)

Keep it as simple as possible
(but still meet all requirements)

Security Aspects 20

IAIK

Side Channels

Keep an eye on side channels which may leak
information

Timing behavior

There should be no relation between timing and confidential
information (e.g. password, key, ...)

Error behavior

Ensure consistent behavior over different causes of errors

Do not expose internal errors externally

Power consumption, electromagnetic emanation, ...

Try to decouple from such channels

Constant running time

No error details to user, details in the logs (for administrator)

Security Aspects 21

7
IAIK

Summary - Input Data

All (external) input data can be
malformed

Always check for correct

Size

Format

Other critical constraints

Security Aspects 22

IAIK

Summary - Output Data

Do not output more than really required

Avoid presenting detailed error
information to normal users

Keep an eye on side-channels

Security Aspects 23

IAIK

Summary – Implementation

Keep it small and simple

Ensure correct operation

Make is fail-safe
(ensure secure state in case of errors)

Prefer correct operation and security
before performance and features

Follow best practices during
implementation
Security Aspects 24

8
IAIK

Summary

Do not assemble SQL commands with
input strings

Use prepared statements and stored
procedures

Validate all input from external
(unauthenticated) sources

Do not output more than necessary

Neither regular output nor error messages

Make your systems fail-safe
Security Aspects 25