2014/01/28: LA OWASP

by Gene Kim on


LA OWASP Conference

Running at 99%: Surviving an Application DDoS Attack: Ryan Huber, Engineer, Risk I/O

Application-Level Denial of Service (DoS) attacks are a threat to nearly everyone hosting content on the Internet. DoS attacks are simple to launch, but can be difficult to defend against. Modern websites are a diverse set of moving parts, and a malicious actor only needs to find the point at which any one of these systems is overwhelmed to bring your website to a halt.

Organizations may approach this problem by increasing capacity, perhaps leveraging the cloud to expand horizontally. This can be a successful short term mitigation strategy, but a combined historic and real-time view of who is accessing your website (and why) gives you the chance to actively defend as opposed to simply absorbing the traffic. Trending this data over time allows your response time to decrease while keeping your front door open. In this talk I will present a new open source project, written primarily in Node.js, that can be used as a defense framework for mitigating these attacks.

  • Having fun watching Ryan Huber bring down HTTP servers in a gazillion ways. "Running at 99%: Surviving App DDoS Attack"
  • Huber: methods so far: slow reads, slow posts, slow form fills; all quickly hit MaxSession limit, run out of sockets, ... haha
  • Huber: "Bouncer written in node.js; inspired by netflow; why node.js? aysnc, fast when not CPU bound, great lib node-http-proxy
  • Huber: "Node.js is cool because @hipsterhacker likes it; although, he's probably moved to Go by now..." haha
  • @edward_bonver: "CSRF: not all defenses are created equal" @angelofsecurity #AppSecCali #OWASP
  • @cktricky: RT @presidentbeef: I will have more @brakeman stickers today at #AppSecCali if you didn't get one yesterday!
  • Kickass logos & stickers are one of the many Twitter engineering core competencies. :) @ndm @presidentbeef
  • Huber: "Bouncer: proxy.js does blacklist, greylist, blocks URLs, closes blacklisted sockets, block slow TCP attacks
  • Huber talk: Ha. Loving the slow read/write attacks; emulates slow modem, uploading 2GB of data to form, tying up http socket
  • Huber: "Combining Bouncer w/redis sorted sets is cool; use union/join to get total time per IP addr to find bad actors
  • Huber: "AWS c1.medium instance can generate 62K http reqs/sec; saturates network before CPU"
  • Huber: "Our site got hit by a bunch of scraper bots from AWS; easy to spot: claimed to be running IE8, had ssh port 22 open
  • Huber: "All our Bouncer code is at https://github.com/rawdigits/Bouncer; rhuber at gmail dot com"

  • .@cwebber sharing amazing story of how on Black Fri, Walmart used node.js to buffer slow backend from overwhelmed front-end

Up: "Anatomy of a WebShell Attack", D0n Quixote

WebShells are an often misunderstood and overlooked form of malware. Yet they continue to be a popular and powerful attacker tool. WebShells can range from extremely simple to elegant and complex. And they are often a favorite tool used by intruders to establish a long term, stealthy presence in a compromised network. Webshells fall into a few distinct categories, and most follow the same common concepts in their design and purpose.

This talk will outline the common parts of a WebShell, why they are designed the way they are, and their typical usage. After covering the internal workings of WebShells, we will cover ways to detect them - even when they are dormant, and not being actively used by the intruder.

  • Quixote: "Three versions: eval, admin backdoor, proxy"

Up: "Content Security Policy: Why You Should Be Using It", Google

It’s 2013, and cross-site scripting is still on the OWASP top 10, ten years after it was in the number four slot on the same list. Cross-site scripting, although seemingly easy to remediate, continues to be problematic for developers, as edge cases crop up where the typical mitigation strategies are confusing. However advances in modern browser security provide developers the opportunity to become far more proactive in addressing this vulnerability class using a technology known as content-security policy (CSP).

When configured and implemented correctly, CSP can severely cripple cross-site scripting attacks. Big technology companies such as Twitter, Facebook, Etsy, and Github are using this to transparently protect their end users from this common vulnerability class.

This session is a combination of short micro talks and a panel discussion geared at getting you the tools needed to understand and implement CSP.

The first microtalk will be a primer to CSP. We will break down what CSP is and provide you the tools to get started with it. The next microtalk is centered around how to sell CSP to management, and techniques to increase adoption in your organization. The final microtalk is around what the web may look like in 5 years, and how content-security policy will play a key role in mitigating increasingly potent client-side attacks.

  • Google: 'Best line to add to ur site to prevent XSS! 'Content-Security-Policy: script-src 'self' https //apis google com
  • Google: "CSP benefits: prevents most XSS vectors; enforces intended content (imgs, form, style, etc.)"
  • Google: "CSP does reporting! 'Content-Security-Policy: default-src 'self'; report-uri /collect" (no excuse not to turn it on)
  • Google: "We're working on extending it, to ensure content integrity"
  • Up: @imelvin: "How To Sell CSP To Your Boss" from @newrelic, formerly of Mozilla (Fellow Portlander! :) (hi, @plightbo!)
  • .@imelvin: "1) CSP is most thorough way to stop XSS; 2) transparent to user; 3) CSP is awesome; if u use it, u're awesome too
  • .@imelvin: "We hope one day that IE will implement CSP... someday..."
  • .@imelvin: "To start, even with gnarly enterprise apps; start w/Report-Only and 'unsafe-inline' mode; fix incrementally
  • .@imelvin: "Difficulties: inline