Baking It In – Towards Abuse-Resistant Web Applications


Published on

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

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • Examples: Twitter
  • …but have their limits

    It’s hard to pre-guess all possible vulnerabilities and vectors
    It’s hard to filter intelligently and dynamically enough

    New solutions are attempting to hook into the application context, use it to understand abusive behavior, and respond adaptively
  • Examples: Twitter
  • Project Lead
    Michael Coates
    Senior Application Security Engineer
    Aspect Security, Inc.

  • Baking It In – Towards Abuse-Resistant Web Applications

    1. 1. The Five Phases of Web Application Abuse Sept 2010 Kyle Adams, Architect, Mykonos Al Huizenga, Product Manager, Mykonos
    2. 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. 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. 4. Characteristics What’s common? Often automated Based on a deep understanding of application behavior Hard to filter out effectively over time
    5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 14. Early Detection What about all the requests before an attack is delivered? Malicious activity detected Attack vector established Number of Requests
    15. 15. OSS Example OWASP AppSensor Project A conceptual framework for implementing intrusion detection capabilities into existing applications Category:OWASP_AppSensor_Project
    16. 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
    17. 17. Questions