Baking It In – Towards Abuse-Resistant Web Applications
17
The Five Phases of Web Application Abuse Sept 2010 Kyle Adams, Architect, Mykonos Al Huizenga, Product Manager, Mykonos
-
Upload
rochester-security-summit -
Category
Technology
-
view
798 -
download
0
description
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.
Transcript of Baking It In – Towards Abuse-Resistant Web Applications
The Five Phases of Web Application AbuseSept 2010
Kyle Adams, Architect, MykonosAl Huizenga, Product Manager, Mykonos
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
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…
Characteristics
What’s common?
Often automated
Based on a deep understanding of application behavior
Hard to filter out effectively over time
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
Phase 1Silent Introspection
Phase 2Attack Vector Establishment
Phase 3Attack Implementation
Phase 4AttackAutomation
Phase 5Maintenance
Understanding
The 5 phases of Web app abuse
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?
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
Phase 3
ImplementationFootprint: 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?
Phase 4
AutomationFootprint: 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
Phase 5
MaintenanceFootprint: 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
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
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
Early Detection
What about all the requests before an attack is delivered?
Malicious activity detected
Attack vector established
Number of Requests
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
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
