Pro-actively Managing Web Application Abuse - Mykonos Software

1,476 views

Published on

A presentation to IT Security Professionals at the Cornerstones of Trust Event in Silicon Valley.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Pro-actively Managing Web Application Abuse - Mykonos Software

  1. 1. Pro-actively Managing Web Application Abuse<br />Al Huizenga<br />Director of Product Management, Mykonos Software<br />29 June 2010<br />
  2. 2. AGENDA<br /> Defining Web App Abuse<br /> Business Examples<br /> Phases of Web App Abuse<br /> E.g. Parameter Manipulation<br /><ul><li>Al Huizenga, Director of Product Management for Mykonos Software
  3. 3. 11 years experience releasing and marketing Web technology</li></li></ul><li>WEB APPLICATION ABUSE<br />What is it and why do we care?<br />Online businesses suffer from ‘grey market’ economies that form to exploit them<br />Lost revenues, increased costs, angry users, brand damage <br />Not just an IT security headache – a costly, ongoing business problem<br />“This robot has tank rolling wheels for feet and it eats people. It is ready to destroy the world! But there is an army of friendly robots with claw hands that have come to stop the destruction and save the day.”<br />Eric Sleen’s niece , Feb 2009, http://beerandscifi.com <br />
  4. 4. SOME BUSINESS EXAMPLES<br />CARD SERVICES<br />EMAIL SERVICES<br />GAMING<br />Provider allows consumers to top up their credit online<br />“Greenhat” developers abuse app logic to top up cards without paying, and automate the process<br />Costs provider $50/K per month in “free” card credits <br />SAAS-based CMS provider finds client sites are being slowed to a crawl by load induced from badly behaved spiders<br />Query too frequently, ignore robots policy<br />Support calls balloon, customer satisfaction impaired<br />Online gamers write programs that top up their in-game virtual currency by abusing the the site API<br />They avoid buying the currency directly, or clicking on commercial offers from advertising partners to get free currency<br />Hurts the site’s ability to monetize effectively<br />
  5. 5. Signatures play here.<br />THE PHASES OF ABUSE<br />Phase 2Attack Vector Establishment<br />Phase 1Silent Introspection<br />Phase 3Attack Implementation<br />Phase 4AttackAutomation<br />Phase 5Maintenance<br />
  6. 6. SIGNATURE-BASED DETECTION<br />Can it help?<br />Effective at blocking known, syntax-level attacks: Injection, XSS, CSRF…<br />Smart developers easily tailor attack vector to avoid pattern match<br />Does not address logic abuse<br />Does not address all phases of abuse<br />Answer: Yes, it can filter out obvious bad stuff, but it’s not enough<br />
  7. 7. EXAMPLE: PARAMETER MANIPULATION<br />Silent Introspection Phase<br />Abuse goals<br />Manipulate data sent between the browser and the app using cookies, form fields, URL query strings, HTTP headers….<br />Make the application behave in unintended ways<br />Impersonate users, change prices, bypass checkpoints…<br /> App lets user select an account from a drop-down box and debit it. The browser sends the following request:<br />http://www.victim.com/example?accountnumber=12345&debitamount=1 <br /> An abusive user could spoof an account number and up the amount: <br />http://www.victim.com/example?accountnumber=67891&creditamount=999999999<br />Example from “A Guide to Building Secure Web Applications”, OWASP, 2005<br />
  8. 8. REMEDIATION OPTIONS<br />Signatures don’t help here, so what can you do?<br />Rewrite the application to be less permissive<br />Ideal, but often not feasible<br />Dev team has moved on, or the app is COTS<br />Implement a fine-grained policy for every parameter that specifies allowable values<br />Typically on a Web Application Firewall<br />Very hard to write and maintain – apps are extremely complicated, IT staff don’t typically have deep enough knowledge<br />Add intrusion detection hooks to flush out parameter tampering<br />In the code itself (e.g. the OWASP AppSensor Project)<br />At serve time (e.g. the Mykonos Security Appliance)<br />
  9. 9. EARLY ABUSE DETECTION<br />Pre-empting abuse in the silent introspection phase<br />Malicious activity detected<br />Attack vector established<br />Number of Requests<br />
  10. 10. RESPONDING TO ABUSE<br />Block IP addresses<br />An imperfect proxy for users<br />Easy to spoof, easy to switch<br />Not granular enough – good chance of hosing good users along with the bad<br />User-based responses are better<br />Warning: “Hey kid, get off my lawn!”<br />User-level block: “No soup for you!”<br />How do you block individual users?<br />Need infrastructure for persistently re-identifying bad user sessions<br />Emerging approaches: token checking, browser fingerprinting<br />
  11. 11. SUMMARY<br />Users (and their code) abuse Web applications<br />To identify and fight back against abuse, you need to engage user behavior<br />See it, analyze it, track it, respond to it in real time<br />It’s not just about protecting the server<br />It’s about understanding and managing how users (and user agents) behave in your application<br />
  12. 12. Q&A<br />Al Huizenga<br />ahuizenga@mykonossoftware.com<br />650-329-9000 ext 1204<br />Mykonos Software<br />

×