using positive tainting and syntax-aware evaluation to...

Using Positive Tainting andSyntax-Aware Evaluation to

Counter SQL Injection Attacks

Alex Orsowith William Halfond and Pete Manolios

Georgia Institute of Technology{orso|whalfond|manolios}@cc.gatech.edu

Supported by NSF awards CCR- 0205422 and CCR-0306372 to GA Techand by DHS and US Air Force under Contract No. FA8750-05-C-0179.

Alessandro Orso – CERCS Industry Workshop – 2006

SQL Injection

String queryString = "SELECT info FROM userTable WHERE ";if ((! login.equals("")) && (! password.equals(""))) { queryString += "login='" + login + "' AND pass='" + password + "'";} else { queryString+="login='guest'";}ResultSet tempSet = stmt.executeQuery(queryString);


Normal UsageUser submits login “doe” and password “xyz”

SELECT info FROM users WHERE login=’doe’ AND pass=’xyz’

Attack Scenario



Malicious UsageAttacker submits “admin’ -- ” and password of “”

SELECT info FROM users WHERE login=’admin’ -- ’ AND pass=’’

Attack Scenario



Overall Goal of The Project

• Protecting existing (insecure) Webapplications by automatically detectingand preventing SQLIAs

• Highly automated — Little/no human effort

• Conservative — No false negatives

• Precise — Few/no false positives


WASP(Web Application SQL-injection Preventer)

Basic idea => Allow only developer-trusted strings to form sensitiveparts of a query

Solution:1. Positive tainting

2. Syntax-Aware Evaluation


Positive VS Negative Tainting

public Login(request, response) {

String login = request.getParameter(“login”);

String pin = request.getParameter(“pin”);

Statement stmt = connection.createStatement();

String queryString = "SELECT info FROM userTable WHERE ";

if ((! login.equals("")) && (! password.equals(""))) {

queryString += "login='" + login +

"' AND pass='" + password + "'";

} else {

queryString+="login='guest'";

}

ResultSet tempSet = stmt.executeQuery(queryString);

}


Positive Tainting

=> Increased automation: Trusted data readilyidentifiable in Web applications

=> Increased safety: Incompleteness leads to easy-to-eliminate false positives(normal in-house testing causes set of trusted datato converge to complete set)

In general, it implements the security principle of“fail-safe defaults”

Identify and mark trusted data instead of untrusted data


Syntax-aware Evaluation

• Cannot simply forbid the use ofuntrusted data in queries

• Dependence on filtering rules requiresunsafe assumptions

=> Syntax-aware evaluation• Performed right before the query is sent to

the database• Consider the context in which trusted and

untrusted data is used: permit untrusteddata to be only in string and numeric literals


Example1. String queryString = "SELECT info FROM userTable WHERE ";2. if ((! login.equals("")) && (! password.equals(""))) {3. queryString += "login='" + login + "' AND pass='" + password + "'"; } else {4. queryString+="login='guest'"; }5. ResultSet tempSet = stmt.executeQuery(queryString);

MetaString: queryString

[S][E][L][E][C][T] … [W][H][E][R][E][]

login -> “doe”, password -> “xyz”

SELECT info FROM userTable WHERE login = ‘ ‘doe AND pass = ‘ ‘xyz !


… [W][H][E][R][E][][l][o][g][i][n][=][‘][d][o][e][‘][A][N][D][][p][a][s][s][=][‘][x][y][z][‘]

•[W]

[ ] == trusted


Example1. String queryString = "SELECT info FROM userTable WHERE ";2. if ((! login.equals("")) && (! password.equals(""))) {3. queryString += "login='" + login + "' AND pass='" + password + "'"; } else {4. queryString+="login='guest'"; }5. ResultSet tempSet = stmt.executeQuery(queryString);

login -> “admin’ -- ”, password -> “”


… [E][R][E][][l][o][g][i][n][=][‘][a][d][m][i][n][‘][][-][-][][‘][A][N][D][][p][a][s][s][=][‘][‘]

SELECT info FROM userTable WHERE login = ‘ ‘admin AND pass = ‘ ‘‘ -- "

[ ] == trusted


Tool Implementation (Java + Tomcat)


Tool Implementation (Java + Tomcat)

Minimal deployment requirements

• No need for a customized runtime system(based on on-line instrumentation)

• Highly automated

• Transparent for the system administrator


Evaluation

1. Effectiveness and accuracy1. False negatives: How many attacks go

undetected?

2. False positives: How many legitimateaccesses are blocked as attacks?

2. Overhead: What is the runtime cost ofusing WASP?


Experiment Setup

6716,453Portal

3410,949Classifieds

317,242Events

7116,959Bookstore

235,658Employee Directory

404,543Office Talk

55,421Checkers

DatabaseInteraction Points

LOCSubject

• Applications are a mix of commercial (5) andstudent projects (2)

• Attacks and legitimate inputs developedindependently

• Attack inputs represent broad range of exploits


Evaluation Results: Effectiveness/Accuracy

03,0166,40301,080Portal

01,9735,9680574Classifieds

02,1416,2070900Events

01,9996,1540607Bookstore

02,0666,3980658Empl. Dir

04995,8880424Office Talk

09224,43101,359Checkers

WASPProtectedWeb Apps

OriginalWeb Apps

Total #Attacks

FalsePositives

# Legit.Accesses

Subject

Successful Attacks

No false positives or false negatives in our evaluation.


Evaluation Results: Overhead

19%16831,080Portal

5%370574Classifieds

1%170900Events

6%470607Bookstore

5%363658Empl. Dir

2%156424Office Talk

5%51221,359Checkers

% OverheadAvg. AccessOverhead (ms)

Avg. AccessTime (ms)

# InputsSubject

Overhead is dominated by network and database access time


Conclusions and Future Work

WASP: Technique for securing applicationsagainst SQL injection attacks

Advantages• Highly/fully automated• Effective and accurate• Minimal deployment requirements

Evaluation involving over 47,000 accesses showedno false positives or false negatives

Future work• Static analysis to optimize dynamic instrumentation• Apply general principle to other forms of attacks• Commercialization


Thanks!

Questions?

using positive tainting and syntax-aware evaluation to...

Documents