Current solutions for securing Web applications at run-time rely heavily on signatures to identify and respond to threats. But signatures have become less effective at detecting threats over time, and aren’t sufficient to address the sophisticated abusive behavior that large, publicly exposed Web applications are subject to, including page scraping, logic abuse, malicious automation, phishing, and malware distribution. The key shortcoming is a lack of application context – without any grounding in actual application and user behavior, signature-based solutions can’t avoid flagging many false positives. This makes the information they provide to administrators practically un-actionable. In response, new approaches are emerging that focus on behavior, not input signatures. One key trend is to enhance the application code itself with detection points that provide more transparency into malicious user behavior. This enables administrators to prevent application abuse before bad users can establish an attack vector. In this presentation, we’ll discuss the merits and challenges of this approach. We’ll focus on specific examples, including the OWASP AppSensor project and the Mykonos Security Appliance. Al Huizenga, Mykonos Software Al Huizenga runs product strategy and management for Mykonos Software, a company focused on new ways to secure Web Applications from abuse. Al has 11 years experience managing, releasing, and marketing Web-based products and technologies in industry leading companies such as Cognos Inc., Platform Computing, and Panorama Software. He is fascinated by how the same technology attributes that drive Web application adoption – openness, transparency, and ubiquity – also represent severe risk to the businesses that use them. Kyle Adams, Architect and Lead Developer Mykonos As architect and lead developer for Mykonos, Kyle Adams has final responsibility for code quality and technical excellence. Mr. Adams is a graduate of the Rochester Institute of Technology, earning a Bachelor Degree in Computer Science with a minor in Criminal Justice. He wrote his first password protection software at age 10, started hacking incessantly, and was writing his own encryption software by age 14. An AJAX expert and enthusiast, Mr. Adams has worked on scores of web application projects as a freelancer and entrepreneur.

1. The Five Phases of Web Application Abuse
Sept 2010
Kyle Adams, Architect, Mykonos
Al Huizenga, Product Manager, Mykonos

2. The Problem
What is Web app abuse?
Manipulating your site (and it’s trust) in
an attempt commit fraud, deface your
brand, and compromise
your users’ privacy
The final attack (Injection, XSS, etc.) is just part of it

3. Examples
What does it look like?
Hogging limited inventory via
shopping cart abuse
Scraping competitive content
Phishing for credentials
Loading nasty 3rd-party content
Could be bad guys…
Could just be
your users…

4. Characteristics
What’s common?
Often automated
Based on a deep understanding of
application behavior
Hard to filter out effectively over time

5. How does it happen?
Over time…
Not a one-time incident
(it just gets reported that way)
The actual attack vector that
works needs to be established first
The abuse needs to be tested and automated
It has it’s own dev lifecycle

6. Phase 1
Silent Introspection
Phase 2
Attack Vector
Establishment
Phase 3
Attack
Implementation
Phase 4
Attack
Automation
Phase 5
Maintenance
Understanding
The 5 phases of Web app abuse

7. Phase 1
Silent Introspection
Footprint: Low
Run a debugger, surf the site, collect data,
analyze offline
What Web server? Database? Network hardware and
software? Programming languages and libraries?

8. Phase 2
Attack Vector Establishment
Footprint: Higher
Cloak yourself
For all dynamic URLs, test inputs for
errors or blind injection to find vulnerabilities
For each vulnerability, start structuring your input to
shape the error into an attack

9. Phase 3
Implementation
Footprint: Highest
Now that you know the vector(s),
what can you do with them?
Extract/edit/delete DB records or tables?
Infect site with a worm that distributes malware?
Launch a complex phishing scam?

10. Phase 4
Automation
Footprint: Low
If the attack makes money, you want to do it
discretely again and again
Write an attack program script
Buy a pre-fab “Command and Control” kit and raise
your own BotNet to attack from

11. Phase 5
Maintenance
Footprint: Low
Let the money roll in, go do something else
Successful automated abuse can exist undetected in
maintenance mode for years
If a patch disrupts the abuse, oh well. Either refine the
vector again, or go hunting elsewhere

12. What can you do?
VM and filtering help, but…
Hard to pre-guess all possible
vulnerabilities and vectors
Hard to filter intelligently
and dynamically enough
Fix
Firewall

13. What else?
New approaches
Get closer to the app context
(and more aware of the client environment)
Analyze app and user behavior to
identify abuse early, esp. automated
Respond adaptively –
beyond blocks and IP blacklists

14. Early Detection
What about all the requests before
an attack is delivered?
Malicious activity
detected
Attack vector
established
Number of Requests

15. OSS Example
OWASP AppSensor Project
A conceptual framework for
implementing intrusion detection
capabilities into existing
applications
http://www.owasp.org/index.php/
Category:OWASP_AppSensor_Project

16. Commercial Example
The Mykonos Security Appliance
A high speed HTTP gateway that
injects code-level honeypots into
application code at serve time, and
provides automated adaptive
responses
http://www.mykonossoftware.com

17. Questions