• Like


Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Baking It In – Towards Abuse-Resistant Web Applications

Uploaded 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 …

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    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

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    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 limitsIt’s hard to pre-guess all possible vulnerabilities and vectorsIt’s hard to filter intelligently and dynamically enoughNew solutions are attempting to hook into the application context, use it to understand abusive behavior, and respond adaptively
  • Examples: Twitter
  • Project LeadMichael CoatesSenior Application Security EngineerAspect Security, Inc.michael.coates@aspectsecurity.com


  • 1. The Five Phases of Web Application Abuse
    Sept 2010
    Kyle Adams, Architect, Mykonos
    Al Huizenga, Product Manager, Mykonos
  • 2. The ProblemWhat 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. ExamplesWhat 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. CharacteristicsWhat’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. UnderstandingThe5 phases of Web app abuse
    Phase 2Attack Vector Establishment
    Phase 1Silent Introspection
    Phase 3Attack Implementation
    Phase 4AttackAutomation
    Phase 5Maintenance
  • 7. Phase 1Silent 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 2Attack 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 3Implementation
    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 4Automation
    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 5Maintenance
    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
  • 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 DetectionWhat about all the requests before an attack is delivered?
    Malicious activity detected
    Attack vector established
    Number of Requests
  • 15. OSS ExampleOWASP AppSensor Project
    A conceptual framework for implementing intrusion detection capabilities into existing applications
  • 16. Commercial ExampleThe 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. Questions