Preventing Web Application Injections with Complementary Character Coding Raymond Mui Phyllis Frankl...

Preventing Web Application Injections with Complementary

Character Coding

Raymond Mui

Phyllis Frankl

Polytechnic Institute of NYU

Presented at ESORICS 2011Supported by NSF and CATT; Patent Pending

Web Application Injection Attacks

• Malicious user inputs cause unintended executions of commands

• Caused by improper input sanitization• SQL injection and cross-site scripting rank

among top application security threats (OWASP Top 10)

<?PHP $message = $_POST[’message’]; $username = $_POST[’username’]; … //welcome the user if(isset($username)) { echo "Welcome $username <br />"; }

// insert new message if(isset($message)) { $query = “insert into messages values(’$username’, ’$message’)"; mysql_query($query); } … // display all messages except the ones from admin $query = "select * from messages where not (user = ‘admin’)"; $result = mysql_query($query); echo ’<br /><b>Your messages:</b><br/>’; while($row=mysql_fetch_assoc($result)){ if($row[’username’] != $username) echo "you "; else echo " { $row[’username’] } "; echo "wrote: { $row[’message’] }"; } …?>

Example: Vulnerable PHP program

Unsanitized user inputs

Web Server/PHP Interpreter

DBMSAliceHello

insert into messagesvalues(‘Alice’,’hello’);

user message

Alice Hello

select * from messages …

<html>…Alice wrote Hello…

Bonnie

Normal Use


DBMS

Alicehello’); drop table messages; --

insert into messagesvalues(‘Alice’,’hello’); drop table messages; --’);

user message

Alice Hello

SQL Injection


DBMS

Alice<script>…</script> insert into messages

values(‘Alice’,’<script> …’);

user message

Alice <script> …


<html>…Alice wrote <script>…</script> …

Bonnie

Persistent Cross-Site Scripting

Browser/JavascriptExecute script with privilegesOf the origin site

Injection Attack Defenses

• Input sanitization• Blacklist / whitelist• In research

– Dynamic tainting– Static analysis– Model checking– Instruction randomization– Machine learning– …

Weaknesses of Current Approaches to Dynamic Tainting

• Overhead– Code instrumentation– Storage and propagation of taint data– Sink checking

• Requires detailed knowledge of context at taint sinks:– SQL syntax (for particular SQL dialect)

• Taint propagation cannot cross component boundaries– Either the entire database is tainted or it is not– Persistent XSS

Our Approach: Complementary Character Coding

• Main idea– Turn dynamic tainting into a character coding

• Free taint storage• Free taint propagation through execution• Taint propagation across components

– Between application and database– Between client and server over HTTP

• Complement Aware Components– Safe execution of unsanitized code against injection attacks– Backwards compatibility through HTTP content negotiation

Complementary Character Coding

Two versions of every character Each character gets two code points instead of

one Standard characters Complement characters

Two flavors Complementary ASCII Complementary Unicode

Complementary Character Coding: Comparison Functions

Value Comparison A standard character is equal to its

complement Convert to standard character, and then

compare all the bits Full Comparison

Standard and complement versions of same character are not equal

Compare all the bits

Complementary ASCII Standard characters

Values 0 – 127 Same as standard ASCII characters

Complement characters Values 128 – 256

Taint bit

--------------------------------------Data bits----------------------------

0 1 0 0 0 0 1 1

Complementary Unicode Unicode

Current version 6.0 Less than 25% code space used or reserved

Allows possibility of having more than two versions of each character Future work

Dynamic Tainting with Complementary Character Coding• Encode untrusted user inputs with complement

characters– Explicitly converted by the server on entry

• Encode trusted developer code with standard characters

• Value comparison during execution– Functionality remains the same– Automatic taint propagation by execution– Taint propagation over database and HTTP

• Each complement aware component has complete picture of taint status during parsing

Complement Aware Components and Security Policy

• Allowed token set– Specified by each component individually for parsing– Defines tokens allowed to contain untrusted characters

• Default policy– Allowed token set = {numbers, string literals}– Prevents all possible injections

• Maybe too restrictive for web browsers

• More permissive policies– Browsers could allow tainted formatting tags– Allowed token set = {numbers, string literals, <b>, <i>, etc.}

• Enforcement– Match tokens in allowed token set with value comparison– Everything else (forbidden tokens) are matched with full

comparison

<?PHP … $message = $_POST[’message’]; $username = $_POST[’username’]; … //welcome the user if(isset($username)) { echo "Welcome $username <br />"; } // insert new message if(isset($message)) { $query = “INSERT INTO messages VALUES(’$username’, ’$message’)"; MySQL_query($query); } … // display all messages except the ones from admin $query = "select * from messages where not (user = ‘admin’)”; $result = MySQL_query($query); echo ’<br /><b>Your messages:</b>’; while($row=MySQL_fetch_assoc($result)){ if($row[’username’] != $username) echo "you"; else echo " {$row[’username’]} "; echo "wrote: {$row[’message’]}"; } …?>

Example: Vulnerable PHP program

Value comparisonUsed by DBMSAnd PHP interpreterhere

Untrusted inputs convertedInto complement characters by server


DBMS

Alicehello’); drop table messages; -- …

insert into messages values(‘Alice’,’hello’); drop table messages;--’);

user message

Alice hello’); drop …

SQL Injection with Complement Aware DBMS

‘ does not match ‘; does not match ;) does not match )drop does not match drop, etc. So DBMS stores literalrather than dropping table.

Red denotes complement characters


DBMS

Alice<script>…</script>

insert into messagesvalues(‘Alice’,’<script> …’);

user message

Alice <script> …


<html>…Alice wrote <script>…</script> …

Bonnie

Persistent Cross-site scripting attack

<script> does not match <script>, etc., so browser displaysthe characters rather than executing the script.


DBMS

Browser,Javascript,

…

Alice<b>Hello</b> insert into messages

values(‘Alice’,’<b>Hello</b>’);

user message

Alice <b>Hello<b>


<html>…Alice wrote <b>Hello</b>…

Bonnie

More permissive browser security policy: Allowed token set includes boldface tags

Policy with allowed token set: {<b>, </b>, …}

Boldface tags matched with value comparison, so browser renders Hello in bold.

Backwards Compatibility• Take advantage of HTTP content negotiation

mechanism• Web browsers identify themselves through Accept-

Charset header• Complement aware browser

– Send output in complementary character coding• Non-complement aware browser

– Route output through a filter that acts as a complement aware browser

• Apply security policy (e.g. default policy)• Convert output into format specified by Accept-Charset

header• Extra overhead• Gradually decrease as more people upgrade to

complement aware browser

Prototype Implementation Done in complementary ASCII LAMP (Linux Apache MySQL PHP)

Default policy Backwards compatible with standard browsers

Firefox Customized security policies through defined

allowed token sets Enough to run proof-of-concept

experiments

Experimental Evaluation Evaluation objectives

Effectiveness Possible Defects Overhead

Benchmarks SQL Injection Application Testbed (Halfond et al)

ATTACK set LEGIT set

ARDILLA (Kieyzun et al) Generated using automated technique SQL injection, reflected XSS, and persistent XSS

Benchmarks

Results: Effectiveness

Ran ATTACK set from SQL Injection Application Testbed using a script Checked database logs for SQL injection

Manually executed ARDILLA test cases Found no signs of injections

Results: Possible Defects Set up original and complement aware web

server with identical initial environments Ran LEGIT set from SQL Injection

Application Testbed on both Compared output produced by both

versions Resulting web pages identical by value

comparison

Ran LEGIT set in SQL Injection Application Testbed and compared average over 100 runs

Worse case overhead less than 2%

Overhead Evaluation

0

5

10

15

20

25

30

35

40

45

50

Bookstore Classifieds Empldir Events Portal

Applications

Tim

e (s

eco

nd

s) Original

Without filter

With filter

Conclusion and Future Work Complementary character coding

Low overhead character level taint tracking Taint propagation across component boundaries Complement aware components

Safe execution of unsanitized code against injection attacks

Backwards compatibility with current browsers Future Work

Implement complementary Unicode Explore other applications of complementary

character coding Web standard

Questions?

Preventing Web Application Injections with Complementary Character Coding Raymond Mui Phyllis Frankl...

Documents

Transcript of Preventing Web Application Injections with Complementary Character Coding Raymond Mui Phyllis Frankl...