SQL injection attacks

-against the applicaton
-db allows all access to application- invalidated access control
-lack of strong types
-risk of SQL injection intrusion
-often done thru web apps (vulnerable)
-can steal info from db
-can change db schema and contents
-can go on undetected
-RDB have no mechanisms to protect against it

-most are executed thru an app taking user-supplied input as query parameters
-attacker makes a new query to get different results
-example: attacker puts something like “1 OR 1=1” in the text field-> all info from a table.
-attacker gets access to anything script can access (entire db or multiple db's)

-attacks from any app, web more vulnerable
-undetected with tradition methods since attacks not detectable from expected use

-IDS (intrustion detection system)
-sys noise can cause false positives
-based on anomoly or signature models
-signature-based system
- has to know know about an attack beforehand
- to be effective, needs constant updates
- protection from the most basic attacks.
-anomaly-based system
- builds a profile expected behavior, alerts on anything not in profile.
- can be bi-modal system w/ training mode and detection mode
-networked IDS
- have sensors (at gateways, firewalls, etc)
- packet inspection at network layer
-can exist at app layer as well as network layer (useful there, as well)

-ideally IDS sensor at the database server
- designed to inspect SQL statements of the SQL stream.

-std DBMS access control mechanisms can't stop most SQL injection attacks--WHY?
-some DBMS have role-based authentication, but most have user-based authentication mechanisms
-single db login for all instances of the app-- single w/ all privileges to a db
- SQL injection not protected by database’s internal access control mechanisms
- devolopers don't use the DBMS' mechanism, instead make their own solution
- apps using non-integrated views (security can easily be compromised)
- “god” user by most web apps significant dilemma db security
- ideally: fix apps to use DBMS authentication mechanisms
- plus additional functions at db server level:
- a program to monitor SQL traffic from an app for a given time, then make set of least privileges
- db proxy server would then have a pool of query-based acces control privileges for min priv. access

-security is part of reliability (robustness)
- DBMS robustness = performance, basic security (authentification), access control, flow control
- db will trust authenticated used, need trust management on how much to trust said user
- want a best practice to be enforced automatically

IDS three methods:
signature-based system
-looks for known things to block
-maintains a list of known attacks, part of web app (NOT in front of db server)
-can be reg ex of known string pattern (must be known in advance),
but this can be easily modifed by attacker once signature is discovered
-Signature evasion techniques
- different encodings
- fragmenting input across packets
- changing to equivalent expression
- Creative use of white space chars can fool a simple signature
- since “OR 1=1” is known, the attack can pick “OR ’One’ = N’One’.”

-SQL too big to maintain signature list of possible variations for dbs in all systems

anomaly-based system
-learns what normal behavior looks like over time, detects anomolies
- SPAM detection
- network worm detection
- training mode or incremental learning to learn profile
- detection mode: distance algorithms to compare current data w/ normal model w/in a dist. threshold


honey tokens (flexible, easy for insider attacks)
- some type of digital entity: credit card number, spreadsheet, presentation,db entry, etc
- concept: digital or information system resource whose value lies in the unauthorized use of that resource
- used to help protect many variety of dbs
- used to catch internal information, violations by employees

SQL injection attack
- app exploit taking advanction of DBMS
- goes thru firewall protection
- most cases bypasses any access control of the DBMS

- goal: execute against db SQL statements and/or queries for successsful attack
- four types
- unauthorized data access
- authentication bypass
- database modification
- escape from a database.

challenge to detecting SQL injection attacks at db server
- effective SQL injection is semantically and syntactically valid
- some rules (like SPAM detection) not effective
- SQL is structured programming language, not a natural language, so IDS likely will have
high either a high rate of false positives or false negatives

parameterization attack
-most apps use a template + user supplied text to make a SQL query
-if app doesn't validate, SQL injection attack can occur
- easiest w/ numerical parameters and dangling parameters (at end of query)
-Dangling Parameters
-first-order replacement
-query rewrite w/ app inserting a string into search term at the end of query
- name expected:
clever string is provided to totally rewrite the query:
SELECT *
FROM Directory
WHERE LastName LIKE ’${NAME}’;
can be transformed to:
SELECT *
FROM Directory
WHERE LastName LIKE ’frank' OR 1=1
UNION
SELECT user, password
FROM mysql.user
WHERE ’q’=’q’ OR "

-second order Replacement

SELECT *
FROM Listing
WHERE LastName=’${NAME}’ OR LastName=’${NAME}’
is transformed, by setting ${NAME} = “Bob’ OR 1=1”, to:
SELECT *
FROM Listing
WHERE LastName=’Bob’ OR 1=1 OR LastName=’Bob’ OR 1=1

returns all since constraint always evaluates to true
-more difficult that 1st order

-Unquoted Numerical Parameters
-Danger will robinson, most dangerous
unchecked value in an unquoted parameter template

UPDATE Financial_Records
SET Salary = ${NEW_SALARY}
WHERE Name = ’${NAME}’

-SET value has no quotes (not required by SQL), unless app restricts the input data, this is a point for injection
-not to say this value will be changed, but the query can be modified.

Batch query engines
-multiple queries as single transaction
-batch queries w/ delimiters (i.e. ; )
SELECT *
FROM Directory
WHERE LastName LIKE ’${NAME}’;
transformed to multiple queries, i.e.
SELECT *
FROM Directory
WHERE Last_Name LIKE ’’;
UPDATE Directory SET Phone=’555-1212’
WHERE First_Name=’Frank’;
-even if first fails, updates can occur to change db

-anomalous payload-based network intrusion detection system
data into buckets, rel. frequencies used to determine normal data
-look at network traffic
-look at structure of the queries in SQL traffic
- need to weight constructs, such as
- Sub-queries
- Literals as left-hand-values or right-hand-values
- Previously unused SQL keywords
- Unquoted values when quoted values are expected
- Unexpected character set or encoding
- Stats
- Query length and encoding
- Keyword usage
- Right-hand/Left-hand bias for constraint qualifiers
- Data types used for particular parameters

Query Groups, Anomaly Estimation, and Deviations
-grouping similar statements according to type, lengthy, type of data, tables, fields
- dist computed(Mahalanobis), normal profile compared for each query group, weighted for danger, sum it all up compare to threshold
-flag and screen more ...

RELATED WORK
Static Analysis of Application SQL
-a model-based approach to detect illegal queries prior to execution
-static part: program analysis to automatically build legit queries
-dynamic part: runtime monitoring for dynamically-generated queries checked againt statically-built model
W. Halfond and A. Orso. AMNESIA: Analysis and
Monitoring for NEutralizing SQL-Injection Attacks. In Proceedings of the IEEE and ACM International Conference on Automated Software Engineering (ASE 2005), pages 174–183, Long Beach, CA, USA, Nov 2005.
SQL Randomization
-protection mechanism uses instruction-set randomization
-creates instances of the lang not predictable to attacker

S. Boyd and A. Keromytis. Sqlrand: Preventing sql injection attacks, 2004.