NoTamper: Automatic Blackbox Detection
of Parameter Tampering Opportunities
In Web Applications
Prithvi Bisht (http://cs.uic.edu/~pbisht)+
Timothy Hinrichs*, Nazari Skrupsky+,
Radoslaw Bobrowicz+, V.N. Venkatakrishnan+
+: University of Illinois, Chicago
* : University of Chicago, Chicago
Background: User Input Validation
• Web applications need to
• Validate user supplied input
• Reject invalid input
Examples:
• “Credit card number is exactly16 digits”
• “Expiration date of Jan 2009 is not valid”
• Validation traditionally done at server: round-trip, load
• Popular trend: Client-side validation through JavaScript
Client Side Validation using JavaScript
onSubmit=
validateCard();
validateQuantities();
Validation Pass?
Yes
send inputs
to
server
No
reject
inputs
Problem: Client is Untrusted Environment
• Validation can be
bypassed
• Previously rejected
values, sent to server
• Invalid quantity: -4
• Ideally: Re-validate
at server-side and
reject
• If not, security risks
Example: Bypassed Validation Security Risks

Client validation:



Field: quantity
“reject negative values”
Server-side code:
cost = cost + price * quantity

quantity = 1, price = 100
cost = cost + 100

quantity= -1, price = 100
cost = cost - 100
How to automatically find such inputs in a
blackbox fashion?
Intuition

Automatically generate two sets of inputs




Valid inputs
Invalid inputs
quantity = 1
quantity = -1
Done through client code analysis
If ( quantity ≥ 0 )
quantity = 1
submit to application
(valid input)
else
quantity= -1
reject, ask to re-enter
(invalid input)
How does the server-side code respond


Heuristically determine if server rejects invalid inputs
Server rejects: quantity = -1
NoTamper Architecture and Outline
hints
Formula
Extractor
Input
Generator
Opportunity
Detector
Web
Page
opportunities
External
analysis
Solve constraints
Logical formula for
client side validation
Benign inputs
e.g., quantity = 0
Fclient: quantity ≥ 0
exploits
Compare responses for
benign and hostile inputs
Hostile inputs
e.g., quantity = -1
Outline
1. Formula extraction from client code
2. Input generation
3. Opportunity detection
4. Evaluation
5. Conclusion
Formula Extraction from Client Code

HTML and JavaScript both restrict inputs
Drop down menu: select one of these
card == 1234…
OR
card == 7890…

HTML form controls





Drop down menu:
Radio/Checkboxes:
Hidden attribute:
Readonly attribute:
Maxlength attribute:
Constraint
value IN (value_1, …, value_n)
tags
value IN (value_1,…, value_n)
value = constant
value = constant
attributes
length(value) ≤ constant
Formula Extraction from Client Code (cont…)

Event driven JavaScript validation
f2
onChange
f1
fn
Valid: all
Invalid: none
onSubmit
Valid: none
Invalid: all fk
Valid: field1
Invalid: rest

(form submitted)
State machine




fm
Start: no fields validated, end: all validation passed
Transitions w/ validation functions: f1, f2, … fn
Over-approximation: All function executed: f1
f2
Execute functions symbolically

conditions when all functions accept inputs
…fn
Formula Extraction from Client Code (cont…)

Program condition when validation succeeds
if (quantity ≥ 0)
return true;
else
return false;

JavaScript interaction w/ Document Object Model



constraint: quantity ≥ 0
Reading form fields (e.g., getElementById)
Enable/disable form fields (e.g., disabled property)
At the end of symbolic execution
Fclient = (path conditions) AND (constraints of enabled fields)
Outline
1. Formula extraction from client code
2. Input generation
3. Opportunity detection
4. Evaluation
5. Conclusion
Input Generation

Benign inputs


Pass client side validation
Satisfy Fclient
Example: Fclient: quantity ≥ 0
Constraint solving
quantity = 1

Satisfying values determined with type information


Collected while analyzing HTML/JavaScript
quantity:
-? [0-9]*
Input Generation (cont…)

Hostile inputs

Bypass client side validation
 Satisfy NOT (Fclient)
Example: NOT ( quantity ≥ 0 )

quantity = -1
Supplying required variables

Example:
NOT (quantity ≥ 0)
quantity = -1
gift-note = “abc”


U
NOT (gift-note in [a-z]*)
gift-note = “-”
Field value mandated by JavaScript
Heuristics: special markers like * in the field description
Outline
1. Formula extraction from client code
2. Input generation
3. Opportunity detection
4. Evaluation
5. Conclusion
Opportunity Detection
Rejected
inputs
Response
for hostile inputs
Different
structures
Response
for hostile inputs
Accepted
inputs
Similar
structures
Response
for Benign inputs
Exploit
opportunity
Opportunity Detection (contd…)

Compare responses to benign and hostile inputs

a1
a2
B1 a3
B2 b1
a2
a3
But noise: user name, address, time, online users, …
Remove
differences
h1
H1 a2
a3
B1 a1
a2
a3
--a2
a3
C1
Difference rank =
Edit Distance (C1,C2)
--a2
a3
C2
Low rank  opportunity
Outline
1. Formula extraction from client code
2. Input generation
3. Opportunity detection
4. Evaluation
5. Conclusion
Applications
8
open
source
5
live
sites
Application
LOC
Constraints source
Use
SMF
97K
HTML+JavaScript
Forum
Ezybiz
186K
HTML+JavaScript
Busn Mgt
OpenDB
92K
HTML+JavaScript
Inventory
MyBloggie
9K
HTML+JavaScript
Blog
B2evolution
167K
HTML
Blog
PhpNuke
228K
HTML+JavaScript
Content Mgt
OpenIT
114K
HTML+JavaScript
Support
LegalCase
58K
HTML
Inventory
smi-online.co.uk
---
HTML
Conference
wiley.com
---
HTML+JavaScript
Library
garena.com
---
HTML
Gaming
selfreliance.com
---
HTML
Banking
codemicro.com
---
HTML+JavaScript
Shopping
Applications (cont…)
Application
For
ms
Hostile
Inputs
Opport
unities
Confi
rmed
SMF
5
56
42
√
Ezybiz
3
37
35
√
OpenDB
1
10
8
√
MyBloggie
1
8
8
√
B2evolution
1
25
21
PhpNuke
1
6
5
√
OpenIT
3
28
27
√
LegalCase
2
13
9
√
smi-online.co.uk
1
23
4
wiley.com
1
15
4
garena.com
1
4
4
selfreliance.com
1
5
1
√
codemicro.com
1
6
1
√
Hostile and benign
responses separated by an
order of magnitude
Opportunities: 169
Examined: 50
Confirmed exploits: 9/13
applications
SelfReliance.com: Online banking
Client-side constraints:
1. from IN (Accnt1, Accnt2)
2. to IN (Accnt1, Accnt2)
Server-side code:
transfer money from  to


Vulnerability: from/to – arbitrary accounts
Exploit: Unauthorized money transfers



Transfer money from unrelated accounts
Account number hardly a secret e.g., checks contain them
Status: fixed within 24 hours

ESP solution (espsolution.net) s/w provider patched s/w for other clients
CodeMicro.com : Shopping
Client-side constraints:
1. quantity1 ≥ 0
2. quantity2 ≥ 0
Server-side code:
total = quantity1 * price1 + quantity2 * price2


Vulnerability: quantities can be negative
Exploit: Unlimited shopping rebates



Two items in cart: price1 = 100$, price2 = 500$
quantity1 = -4, quantity2 = 1, total = 100$ (rebate of 400$ on price2)
Status: fixed within 24 hours
OpenIT: Support
Client-side constraints:
1. userId == 1 (hidden field)
Hidden
Field
Server-side code:
Update profile with id 1, with new details


Vulnerability: update arbitrary account
Exploit: Privilege escalation



Inject a Cross-site scripting (XSS) payload in admin account
Cookies stolen every time admin logged in.
Status: open
Outline
1. Formula extraction from client code
2. Input generation
3. Opportunity detection
4. Evaluation
5. Conclusion
Conclusion

Framework to identify parameter tampering
opportunities



Used client-side restrictions to aid hostile input generation
Several serious problems in open source / commercial
applications
Significant gap:
validation that should happen and that does happen
Thanks and Questions
Backup
False positives
• maxlength constraints
• Mutated inputs
: 31
: 12
Split of HTML, JavaScript and Hidden Field
Constraints
• HTML constraints
: 110/169
• JavaScript constraints : 20/169
• Hidden fields constraints : 39/169
(65%)
(12%)
(23%)
Manual intervention
• Unique variables
: 3
• (SMF: 2, phpNuke: 1)
• Session id/cookies
: all except phpNuke
• Required variables
: 12
• (SMF: 5, phpNuke: 4, B2Evolution: 1, Garena.com: 2)
• Typically 5 minutes per form
• Bounded by the number of fields
Limitations

Unsound

False positive: application mutates invalid inputs e.g., truncate



12 such instances in our experiments
False positive: similar responses for failure/success
Incomplete

JavaScript over-approximation


JavaScript unhandled features


Mutually exclusive events may cause Fclient – false
document.write/eval
constraints not checked at client

Fclient = true
Some related work


Input validation

Prevent affect of invalid inputs: Su et al. POPL’06, Bandhakavi et al. CCS’07,

Find insufficient validation: Livshits et al. Usenix’05, Balzarotti et al. CCS’07,
JavaScript analysis based client side attacks: Saxena et al. Oakland’10
Fuzzing/directed testing


Balzarotti et al. Oakland’08, …
Vulnerability analysis


Saxena et al.NDSS’09, Van Gundy M et al. Oakland’09, Ter-louw et al. Oakland’09
Benign/Hostile input generation:
NDSS’08, Saxena et al. NDSS’10, …
Godefroid et al. SIGPLAN’05, Godefroid et al.
Prevention techniques

Sandbox/restrict client code: Grier et al. Oakland’08, Reis et al. EuroSys’09, Wang
et al. Usenix’09, Vikram et al. Oakland’09, Chong et al. CCS’09, …