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

1. Pro-actively Managing Web Application Abuse Al Huizenga Director of Product Management, Mykonos Software 29 June 2010

4. SOME BUSINESS EXAMPLES CARD SERVICES EMAIL SERVICES GAMING Provider allows consumers to top up their credit online “Greenhat” developers abuse app logic to top up cards without paying, and automate the process Costs provider $50/K per month in “free” card credits SAAS-based CMS provider finds client sites are being slowed to a crawl by load induced from badly behaved spiders Query too frequently, ignore robots policy Support calls balloon, customer satisfaction impaired Online gamers write programs that top up their in-game virtual currency by abusing the the site API They avoid buying the currency directly, or clicking on commercial offers from advertising partners to get free currency Hurts the site’s ability to monetize effectively

5. Signatures play here. THE PHASES OF ABUSE Phase 2Attack Vector Establishment Phase 1Silent Introspection Phase 3Attack Implementation Phase 4AttackAutomation Phase 5Maintenance

6. SIGNATURE-BASED DETECTION Can it help? Effective at blocking known, syntax-level attacks: Injection, XSS, CSRF… Smart developers easily tailor attack vector to avoid pattern match Does not address logic abuse Does not address all phases of abuse Answer: Yes, it can filter out obvious bad stuff, but it’s not enough

7. EXAMPLE: PARAMETER MANIPULATION Silent Introspection Phase Abuse goals Manipulate data sent between the browser and the app using cookies, form fields, URL query strings, HTTP headers…. Make the application behave in unintended ways Impersonate users, change prices, bypass checkpoints… App lets user select an account from a drop-down box and debit it. The browser sends the following request: http://www.victim.com/example?accountnumber=12345&debitamount=1 An abusive user could spoof an account number and up the amount: http://www.victim.com/example?accountnumber=67891&creditamount=999999999 Example from “A Guide to Building Secure Web Applications”, OWASP, 2005

8. REMEDIATION OPTIONS Signatures don’t help here, so what can you do? Rewrite the application to be less permissive Ideal, but often not feasible Dev team has moved on, or the app is COTS Implement a fine-grained policy for every parameter that specifies allowable values Typically on a Web Application Firewall Very hard to write and maintain – apps are extremely complicated, IT staff don’t typically have deep enough knowledge Add intrusion detection hooks to flush out parameter tampering In the code itself (e.g. the OWASP AppSensor Project) At serve time (e.g. the Mykonos Security Appliance)

9. EARLY ABUSE DETECTION Pre-empting abuse in the silent introspection phase Malicious activity detected Attack vector established Number of Requests

10. RESPONDING TO ABUSE Block IP addresses An imperfect proxy for users Easy to spoof, easy to switch Not granular enough – good chance of hosing good users along with the bad User-based responses are better Warning: “Hey kid, get off my lawn!” User-level block: “No soup for you!” How do you block individual users? Need infrastructure for persistently re-identifying bad user sessions Emerging approaches: token checking, browser fingerprinting

11. SUMMARY Users (and their code) abuse Web applications To identify and fight back against abuse, you need to engage user behavior See it, analyze it, track it, respond to it in real time It’s not just about protecting the server It’s about understanding and managing how users (and user agents) behave in your application

12. Q&A Al Huizenga ahuizenga@mykonossoftware.com 650-329-9000 ext 1204 Mykonos Software