StartPad Countdown 2 - Startup Security: Hacking and Compliance in a Web 2.0 World

Loading...

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.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite

    StartPad Countdown 2 - Startup Security: Hacking and Compliance in a Web 2.0 World - Presentation Transcript

    1. Hacking and Compliance in a Web 2.0 World
      • Damon P. Cortesi, CISSP
      • Director @ Alchemy Security
      • Stats Nut | Security Geek | Builder of Tools
    2. $ whoami
      • Connecticut >> Chicago >> Seattle (2006)
      • @dacort on Twitter ( http://tweetstats.com )
      • Security Consultant, recently self-employed
      • Destroyer of Web Apps and Dual-Cores
    3. $ cat ~/.plan
      • Web 2.0 Security
        • Things you still need to watch out for.
      • E-commerce Startups and Compliance
        • What is this PCI thing you speak of?
        • Privacy Policy and Data Breach Notification Laws.
      • And maybe if we’re lucky...demo time.
    4. Web 2.0 Frameworks
      • Rails, Django, CakePHP
      • Rapid Development, Data abstraction
      • Alleviates common security pain points
        • SQL Injection
        • Cross-Site Scripting (kind of ...)
        • Typical challenges still present
    5. The “kind of” - XSS
      • As of Django 1.0 (Sep 2008), HTML is auto-escaped
        • YAYYYYYYYYYYYY!
      • Does Rails? ------------------------- No
      • Does Google App Engine? -------- No
        • Really? Yup, really. (No domain-wide cookies, phew!)
      • Does ASP.NET ---------------------- On built-in controls
        • Also has built-in request validation
    6. Define Briefly
      • SQL Injection - Unsanitized data being passed to a database, potentially executing arbitrary code.
        • dpc’ OR ‘a’=’a
        • xp_cmdshell
      • XSS - Unsanitized data being re-displayed and interpreted in the browser.
        • <script>alert(document.cookie);</script>
    7. XSS - The Bad, The Ugly
      • XSS 101 - Executes user input in browser context
        • Typical test: “><script>alert(‘dcash’)</script>
      • “site:appspot.com search” on Google
        • 156,000 Results
        • First 30 results, at least 4 XSS-vulnerable apps
        • So...why is this bad?
      “ ><script>alert(‘dcash’)</script>
    8. XSS Scenarios
      • Arbitrary JavaScript Execution
      • Page/HTML inserts, deletes
      • Browser control, exploit download
      • Cookie monsters
    9. Fixing XSS
      • Primarily - HTML/URL Encoding, Proper Escaping
        • <%= h “<b>dacort</b>” %> &lt;b&gt;dacort&lt;/b&gt;
      • Validation && Sanitization - Regexes
        • Rails Routes
          • ‘ :controller/show/:id’, :id => /d+/, :action ...
        • ActiveRecord validates_format_of
    10. More XSS Prevention
      • Secure Cookie Flag (GMail, again...)
        • https://site.com
        • (Inject link to image on http ://site.com )
        • Uses HTTPS cookie if “secure” flag not set
      • HTTPOnly Cookie Flag
        • Can’t be accessed using <script>
        • Use innerText , not innerHTML
    11. Cross-Site Request Forgery
      • Browsing circa 1998
        • One window. One site.
      • Browsing circa 2008
    12. CSRF++
      • Daily browsing - authenticated to many sites at once
      • GET style attacks
        • <img src=” http://x.com/message/123/delete ”/>
          • Cookies sent with this request
      • POST style attacks
        • Generally combined with JavaScript
        • Due to lack of form tokens
      • GMail Hack (There’s a new one!!)
    13. CSRF GET
      • <img src=” http://x.com/message/123/delete ”/> <img src=” http://x.com/message/124/delete ”/> <img src=” http://x.com/message/125/delete ”/> <img src=” http://x.com/message/126/delete ”/> <img src=” http://x.com/message/.../delete ”/>
      • No tokens? Logged in? Valid message?
        • “Pwned”
      • POST requests not the solution
    14. CSRF POST
    15. GMail Analysis
      • GMail Create Filter (GET URL)
        • “at” variable == “GMAIL_AT” cookie value
        • Using CSRF (or XSS?) on malicious page
        • Steal GMAIL_AT, submit GET request above
    16. Third-Party Components
      • You installed what??
      • Drupal Plugins
      • Wordpress Plugins
        • Themes, too!
      • ASP.NET Components
      • Is that code secure?
      • Does it execute commands?
      • Does it utilize network?
      • Funky encoding...
    17. What to Look For?
      • Find input vectors
        • Request.[Cookies|Form|QueryString]
        • $_GET, $_POST, $_REQUEST (<-- careful)
        • params[:id]
      • Make sure output is protected
        • Encoding to browser, Escaping to database, etc
    18. Poor Design = Poor Security
      • Example Startup FreeMail (names changed ... )
      • RSS feed for your Inbox
        • Google does it, why can’t we?
      • No authentication
      • No SSL
      • No security
    19. Flash Security
      • Flash - Fantastic base on which to build dynamic sites
      • crossdomain.xml - Allows Flash to access data on different domains
      • BAD : <allow-access-from domain=&quot;*&quot;/>
      • Can ultimately allow for compromise of user data (cookies) if trusted domain is vulnerable to XSS, etc
    20. Some Other Things...
      • Keeping systems/software up-to-date
        • Rails < 2.1.1? -- SQL Injection bug
          • JumpBox (Server Provisioning) uses Rails 2.1.0
        • Curious - How do you manage security updates?
      • Infrastructure Security
        • Do _you_ know your external network presence?
        • Have all _your_ default passwords been changed?
    21. And a few more...
      • Multiple layers of restriction
        • Have a phpMyAdmin Internet-accessible?
        • Do you ...
          • Restrict access by IP address?
          • Rename the default location?
          • Have authentication enabled?
      • Process . Process . Process .
    22. One last thing ...
      • Not always some über-technical buffer overflow sploit...
      • Access database on unprotected share
      • demo/demo password
      • Email on confirmation page
      • Are people thinking securely?
    23. Password Security 250 passwords later... 5 Minutes Later
    24. Switching Gears
      • Compliance
    25. We <3 Our Data
      • Some of that data is restricted, though!
      • Personally Identifiable Information (PII)
      • Data Breach Notification Laws
      • Payment Card Industry (Credit Cards, PCI)
      • So you’re building a web service...
        • ...what do you need to know?
    26. Planning and Process
      • 44 states have data breach notification laws
        • Name, address, email
        • Social Security Number
        • Passport ID, License Number
      • If you are compromised and the above is unencrypted and compromised - you must notify data owners.
    27. Data Breach/Privacy Policy
      • Data Breach Laws are why services such as Twitter and Evernote have this in their Privacy Policy.
        • If Evernote learns of a security system breach we may attempt to notify you and provide information on protective steps, if available, through the e-mail address that you supplied during registration or posting a notice on our web site. Depending on where you live, you may have a legal right to receive such notices in writing. -- http://evernote.com/about/privacy/
        • We will make any legally-required disclosures of any breach of the security, confidentiality, or integrity of your unencrypted electronically stored personal data to you via email or conspicuous posting on this Site in the most expedient time possible and without unreasonable delay. -- http://twitter.com/privacy
    28. PCI
      • PCI only applies to you if you “store, process, or transmit cardholder data.”
      • Want the PCI compliance monkey off your back?
      • “ It’s simple, just don’t ever store, process, or transmit cardholder data - let someone else do it for you.”
      • And if you must store, process, or transmit ... call us.
    29. PCI If You Have To
      • Cardholder data is defined as the primary account number (“PAN,” or credit card number) and other data obtained as part of a payment transaction, including the following data elements:
        • PAN
        • Cardholder Name
        • Expiration Date
        • Service Code
        • Sensitive Authentication Data: (1) full magnetic stripe data, (2) CAV2/CVC2/CVV2/CID, and (3) PINs/PIN blocks
    30. Thanks
      • [email_address]
      http://xkcd.com/327/

    + Start PadStart Pad, 11 months ago

    custom

    1206 views, 1 favs, 4 embeds more stats

    Damon Cortesi of Alchemy Security presents the most more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 1206
      • 1160 on SlideShare
      • 46 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 49
    Most viewed embeds
    • 21 views on http://startpad.org
    • 17 views on http://startupsecurity.info
    • 7 views on http://atenlabs.com
    • 1 views on http://www.startpad.org

    more

    All embeds
    • 21 views on http://startpad.org
    • 17 views on http://startupsecurity.info
    • 7 views on http://atenlabs.com
    • 1 views on http://www.startpad.org

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories