1. Rich Web applications in the cloud
Is the model broken?
Danny Lieberman
dannyl@software.co.il
http://www.software.co.il/wordpress/
Copyright Creative Commons Attribution License by Danny Lieberman

2. Agenda
 Preface
 Security issues
 Performance problems
 The future of Web 2.0 applications in the cloud?
 Conclusions

3. 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

4. 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

5. 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.

6. 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.

7. 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.

8. 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

9. 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

10. The Web application model is broken
2-5 languages
Server stack Message passing in the UI
(query strings)
PC Browser Smartphone Device
3-5 languages
Message passing in the UI

11. 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

12. Web app attacker entry points
Look at all
DB Servers
the possible
Interfaces
entry points Server stack PHP, C#, Ruby, J2EE
an attacker
HTML/Javascript/CSS
has at her
Web servers
finger tips
with a
modern
Web
application
HTML
XML
PC CSS
Browser Smartphone Device
Javascript
Java
Flash

13. 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

14. 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

15. 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”.

16. 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

17. Cloud security reference model

18. 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?

19. 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?

20. 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.

21. 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!

22. How do Web servers work?
Browser opens
connection.
Server forks a thread
for each connection,
using blocking IO.
Ajax latency:
200-600ms

23. 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.

24. 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

25. The future of apps in the cloud
The fundamentals of scalable
systems are fast networking and
non-blocking design—the rest is
message passing
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

26. 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

27. 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

28. 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

29. 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.