Rich Web applications in the cloudIs the model broken?

Danny Liebermandannyl@software.co.il

http://www.software.co.il/wordpress/

Copyright Creative Commons Attribution License by Danny Lieberman

Agenda

Preface

Security issues

Performance problems

The future of Web 2.0 applications in the cloud?

Conclusions

Preface

Cloud computing

is fashionable.

The “cloud” is an evolution of hosting, ASP, grid computing, virtualization, commodity multi-core processors and decreasing connectivity costs.

Just like this Ralf Lauren dress, it can be attractive and complex at the same time.But will your wife or girl friend look this good in it?

Ralf Lauren Fall 2010

Preface

But what about

performance & security?

In this talk, we examine a number of fundamental weaknesses in the current Web application execution model.

We will see that the lessons learned over 30 years ago with IBM mainframes for secure, high-performance computing, have been forgotten.

Coco Chanel circa 1920

The Cloud and the “security problem”

There is 1 thing that security practioners

agree on:

Security is hard to sell to an organization.

This is for 3 reasons: Security is really complex

Since security is hard to understand, it is hard to explain to

the management and get them to spend money.

In addition, the economic benefit of security to business is

unclear at best.

The Cloud and the “security problem”

Here is where the cloud computing model

looks sexy.

Cloud computing is a utility like electricity

– It’s Simple

– It’s Easy to measure economic benefit

– The Security is built-in

We don’t generate our own electricity and even if

we have a solar/wind power setup – we outsource

the operation and sell the electricity back to the

power company.

Cloud and the “security problem”

The good news

– The Tier 1 cloud computing providers are

better at security than you or me

The bad news

– You still have to run some application

software, either applications you wrote or

software as a service that someone else

wrote.

– The threat surface for running your app in the

cloud is potentially much bigger than running

it inside the office.

The cloud threat surface

There are 2 reasons why

the threat surface for a

Web app in the cloud is

much bigger than

running it in your office:

1. CIO mistakes

2. The Web application model

is broken

The top 3 mistakes CIOS make

Don’t know how much your assets are worth

asset.val()== undefined

Write a bunch of procedures while attackers

exploit your software

$p != security.software

Confuse compliance with

data security

$c != security.data

The Web application model is broken

Browser Smartphone

Server stack

2-5 languages

Message passing in the UI

(query strings)

3-5 languages

Message passing in the UI

PC Device

Message passing in the UI?

Passing messages in the

UI is a Very Bad Idea.

Imagine that the airlines used

agent reservation terminal

screens to pass all the internal

data they need for a

reservations transaction.

It would never work.

World aviation would stop as

hackers exploited vulnerabilities

in the query strings and stole

everyone’s PNR.Worst dressed at BET Awards 2010

Web app attacker entry points

Browser Smartphone

Server stack

DB Servers

Interfaces

PHP, C#, Ruby, J2EE

HTML/Javascript/CSS

Web servers

HTML

XML

CSS

Javascript

Java

Flash

PC Device

Look at all

the possible

entry points

an attacker

has at her

finger tips

with a

modern

Web

application

Web app threat scenarios

Any kind of code injection

Server or client returns invalid HTML

Pages contain dead links

HTML forms don't match field types expected by controllers

Client side makes bad assumptions about AJAX services

Server may attempt to execute invalid SQL queries

Improper marshaling/un-marshaling

– DB server to Web server

– DB server to application tier

– Web server to browser

Web app vulnerabilities

Heterogeneous stacks

– Too much chewing gum

PHP, Ruby, Python

– Flexibility, no static type guarantees

C#, Java

– Static typed, but only at Web server

– Code complexity increases threat surface

Redundant code on servers and clients

Redundant data on servers and clients

Client-server latency

– Slow HTTP POST attacks

What is the best way to secure Web apps?

If you are bunch of big company guys with someone paying your

salary and time on your hands – you get together and write a

“Security Reference model”

If you are a big security vendor like Symantec, you write marketing

collateral that talks about your

“Integrated Web application security platform”

If you are a Israeli security startup, you develop some

“Breakthrough, game-changing technology”. After 2 years, it

becomes part of the “Integrated Web application security platform”.

Remember

We recall that we started this talk with the

understanding that security is hard to sell

because it’s complex and difficult to cost-

justify.

Writing some security reference models and

developing slide-ware or new technology is

not going to make it simple and cost effective.

Let’s take a look at the Cloud security reference model from the

CSA – Cloud Security Association

Cloud security reference model

Security summary

The Security Control model looks great!

But it doesn't mitigate any of the Web

application core vulnerabilities

Typing issues

Interface issues

Redundant code, data and tiers

Client-server latency

What is going on here? Did these guys forget that we are running

buggy Web apps in the cloud?

Interim conclusions

The current Web application development and

execution model is seriously broken from a

security perspective.

What about performance?

Maybe it’s just a case of fast applications that

are insecure?

Web app performance issues

We will see that the current Web application

execution model is 10x SLOWER than it

should be.

Since you pay the cloud provider for CPU

cycles, this means that you are over-paying

by a factor of 10.

Ouch.

We all know that time is money

Amazon.com

100 ms of latency costs Amazon 1% of sales(http://highscalability.com)

Google.com

500ms delay in delivery is a 20% drop in

traffic (Google VP Marissa Mayer)

Competing stock trading platforms

5ms delay is $4M in losses / ms.

Performance counts!

How do Web servers work?

Browser opens

connection.

Server forks a thread

for each connection,

using blocking IO.

Ajax latency:

200-600ms

What about the hardware?

What about multiple-processor

concurrency?

Threads don't scale well with multi-cores

Processes are necessary to scale to multi-

core computers, not memory-sharing

threads.

Threads are a bad idea

The mixture of threads and modern multi-

core systems add up to some serious race

condition potential.http://blogs.msdn.com/b/david_leblanc/archive/2007/04/19/why-threads-are-a-bad-idea.aspx

Thread-based networking is inefficient and

very difficult to use. http://www.kegel.com/c10k.html and http://bulk.fefe.de/scalable-networking.pdf

The future of apps in the cloud

The fundamentals of scalable systems are fast networking and non-blocking design—the rest is message passing.

I think 3 technologies will play an important part in

fixing the broken Web app model:

Web sockets

Node JS

Couch DB

The fundamentals of scalable

systems are fast networking and

non-blocking design—the rest is

message passing

The future of apps in the cloud

Web sockets

Open a connection to Web

server

It stays open

Pass messages

Eliminates at least 2

processes for every

connection.

(Browser-Server &

Server-Database)

Low Latency:

20-60ms instead of

200-600ms

The future of apps in the cloud

Node.js

Javascript on

client and server

No threads

No blocks or locks

UI is HTML & CSS

Asynchronous

message passing

with Web sockets

The future of apps in the cloud

CouchDB

Application served out of CouchDB

CouchApp lives in the browser.

No middle tier

Javascript on client and server

UI is HTML & CSS

CouchDB uses Ajax to shove

JSON back and forth.

CouchDB replicates on smart phones

Summary

Application vulnerabilities are expensive

100x more expensive to fix after implementation

Potential data loss in the cloud

Security controls don't come cheap

Time is money

High latency applications less responsive

Your cloud provider charges per CPU cycle

Your costs go up, revenue goes down

Promising new technologies

No middle/data tiers, reduced threat surface

10x lower latency

Your costs go down, revenue goes up.