Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Web application security in the cloud


Published on

Published in: Technology, Business
  • Be the first to comment

Web application security in the cloud

  1. 1. Rich Web applications in the cloud Is the model broken? Danny Lieberman Copyright Creative Commons Attribution License by Danny Lieberman
  2. 2. Agenda Preface Security issues Performance problems The future of Web 2.0 applications in the cloud? Conclusions
  3. 3. PrefaceCloud 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. 4. PrefaceBut 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. 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. 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. 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. 8. The cloud threat surfaceThere 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 mistakes2. The Web application model is broken
  9. 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 != Confuse compliance with data security  $c !=
  10. 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. 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. 12. Web app attacker entry pointsLook at all DB Serversthe possible Interfacesentry points Server stack PHP, C#, Ruby, J2EEan attacker HTML/Javascript/CSShas at her Web serversfinger tipswith amodernWebapplication HTML XML PC CSS Browser Smartphone Device Javascript Java Flash
  13. 13. Web app threat scenarios Any kind of code injection Server or client returns invalid HTML Pages contain dead links HTML forms dont 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. 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. 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. 16. RememberWe 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. 17. Cloud security reference model
  18. 18. Security summaryThe Security Control model looks great! But it doesnt 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. 19. Interim conclusionsThe 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. 20. Web app performance issuesWe 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. 21. We all know that time is money  100 ms of latency costs Amazon 1% of sales (  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. 22. How do Web servers work?Browser opens connection.Server forks a thread for each connection, using blocking IO.Ajax latency: 200-600ms
  23. 23. What about the hardware? What about multiple-processor concurrency?  Threads dont scale well with multi-cores  Processes are necessary to scale to multi- core computers, not memory-sharing threads.
  24. 24. Threads are a bad idea The mixture of threads and modern multi- core systems add up to some serious race condition potential. Thread-based networking is inefficient and very difficult to use. and
  25. 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. 26. The future of apps in the cloudWeb 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. 27. The future of apps in the cloudNode.js Javascript on client and server No threads No blocks or locks UI is HTML & CSS Asynchronous message passing with Web sockets
  28. 28. The future of apps in the cloudCouchDB 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. 29. Summary Application vulnerabilities are expensive  100x more expensive to fix after implementation  Potential data loss in the cloud  Security controls dont 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.