WWW/Internet 2011 - A Framework for Web 2.0 Secure Widgets

495 views
391 views

Published on

Slides presented during the WWW/Internet 2011 in Rio.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
495
On SlideShare
0
From Embeds
0
Number of Embeds
26
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Open Web Application Security Project
  • Open Web Application Security Project
  • Open Web Application Security Project
  • Open Web Application Security Project
  • Open Web Application Security Project
  • WWW/Internet 2011 - A Framework for Web 2.0 Secure Widgets

    1. 1. A Framework for Web 2.0 Secure Widgets Vagner Figueredo de Santana, Prof. Maria Cecília Calani Baranauskas Institute of Computing Prof. Marco Aurélio Amaral HenriquesSchool of Electrical and Computer Engineering
    2. 2. Agenda• Problem and context• Objective• Security and JavaScript• Literature review• Framework proposal• Conclusions2
    3. 3. Problem and context:Web 1.0 vs Web 2.0• Web 1.0 o Focus is content o Active producer to passive consumer o Few produce o Content weakly integrated semantically• Web 2.0 o Focus is end user o Anyone can produce and/or consume o Content is more integrated o Integration agregates value to the content o Term created to represent this paradigm shift3
    4. 4. Problem and context:HTML, CSS, and JavaScript• Usually Web pages count on: o Markup language (e.g., HTML) o Style Sheets (e.g., CSS) o Scripts (e.g., JavaScript)• All of them have characteristics relative to security• But JavaScript has a prominent role o It is a programming language o It allows communication o It is hard to verify if the code is malicious o Let’s see an example4
    5. 5. Problem and context:HTML, CSS, and JavaScript...var url = { toString: function(){ this.toString() = function(){ return “bad” ; } ; return “good” ; }} ;...5
    6. 6. Problem and context:Widget and Mashup• Widget o User Interface (UI) components that add functionalities o May use JavaScript to send/receive data (AJAX) o External scripts are placed in the same scope of others o Example: Twitter component• Mashup o Technique of building applications integrating content o Combines services gracefully for the user o Can be built at the client or at the server o In sum, integrates different widgets o Example: Addict-o-matic6
    7. 7. Problem and context:Widget and Mashup Widget server7
    8. 8. Problem and context:Widget and Mashup8
    9. 9. Problem and context:Widget and Mashup Web page is a point of attack Communication is a point of attack9
    10. 10. Problem and context:Scenario of usage• 74.9% of most popular homepages use JavaScript in a insecure way o Insecure insertion:  <script src=" [external script ] " ... > o Insecure generation:    document.write( [external content] )  eval( [external content] ) • 43.6% use code from 3 or more extermal domains• In average, use code from 5 external domains• 2 of the top 10 vulnerabilities pointed by OWASP (Open Web Application Security Project)10
    11. 11. Objective• Show common attacks related to the JavaScripts• Comment on attack vectors considering JavaScript usage• Propose a framework to securely reuse Web 2.0 widgets• Present how to use it considering current technologies11
    12. 12. Security and Javascript:Common attacks - XSS• Stands for Cross-Site Scripting• 2nd most occurred attack in the OWASP Top 10• Is possible to run script in the main document of a Web page• With the scope access is possible do deface, change forms destination, log events, etc.• Example: Try to search for <script>alert("XSS")</script>• More examples available at: http://ha.ckers.org/xss.html12
    13. 13. Security and Javascript:Common attacks - CSRF• Stands for Cross-Side Request Forgery• 5th most occurred attack in the OWASP Top 10• Browsers insert credentials in requests (e.g., cookie, IP)• If an application uses only these credentials to authenticate, it allows CSRF attacks• The attacker can perform requests on behalf of the user• Example: var image = new Image(); image.src = "http://www.target.com/abuse/1234";13
    14. 14. Security and Javascript:Data exchange• In mashups is desirable to exchange data among different domains (cross-domain)• AJAX was designed to exchange data between the client and the domain that served the Javascript• The restriction that avoids cross-domain connections using XMLHttpRequest is called Same Origin Policy (SOP)• SOP does not apply to cross-domain tags: <script>, <style>, and <img>• Common workaround: insecure JavaScript14
    15. 15. Security and Javascript:Data exchange• If insecure use of Javascript takes place, then the task of verifying whether a script is malicious becomes more difficult• SOP applies when a mashup is built at the client• But mashups built at the server result in overhead• Let’s see an example…15
    16. 16. Security and Javascript:Data exchangeMashup built at the server Web page server Widget server16
    17. 17. Security and Javascript:Data exchangeMashup built at the server17
    18. 18. Security and Javascript:Data exchangeMashup built at the server18
    19. 19. Security and Javascript:Data exchangeMashup built at the server19
    20. 20. Security and Javascript:Data exchangeMashup built at the client Widget server Web page server Widget server20
    21. 21. Security and Javascript:Data exchangeMashup built at the client21
    22. 22. Security and Javascript:Data exchangeMashup built at the client22
    23. 23. Security and Javascript:Data exchangeMashup built at the client23
    24. 24. Literature review:State of the art• Lightweight Self-protecting Javascript o Intercepts requests in order to protect the code o Vulnerable to delete() function• Subspace o Wrap external scripts in nested <iframe> tags o Requires the manipulation of document.domain• Maintenance of code o Guidelines o Do not present a concrete solution24
    25. 25. Literature review:Common practices and proposals• Dynamic Script Tag (unsafe insertion!) o Adding <script src=" [external code] "> to DOM tree• Iframe Proxy (or Fragment Identifier Messaging) o <iframe src="...# [messages] " ... > o Results in usability problems• Other ideas • JSONRequest • <module> tag25
    26. 26. Framework proposal:Assumptions• Web page and the communication are points of attack• The Web page must be free of XSS Holes• The website must be free of insecure use of JavaScript• Message integrity• HTTPS authentication between devices26
    27. 27. Framework proposal:Patterns considered• Model-View-Controller o Inspires the overal architetural organization• GoF (Gang of Four) o Proxy  Mediates cross-domain requests to guarantee proper filtering of the content received at client  It must not run JavaScript received from the widget server• PoEAA (Patterns of Enterprise Application Architecture) o Template View  Embeds proper UI component considerng filtered content27
    28. 28. Framework proposal:Overall architecture28
    29. 29. Framework proposal:Using current technologies29
    30. 30. Framework proposal:Discussion• Use of different technologies can add complexity• Inexistence of XSS Hole is a strong requirement• GoF Patterns… PoEAA… anything new?• The proposed framework addresses a gap identified in the literature• Developers can build solutions to improve security • Considering current technologies • Without requiring any action from users30
    31. 31. Conclusions• Applications are ahead of browsers technology• Disabling JavaScript is not a practical solution• Developers are applying workarounds to policies and restrictions in order to use certain Web 2.0 features• Browsers security model should deal with JavaScript filtering• Client-side programming is not less or more important than server-side programming, it is just another part of Web 2.0 applications31
    32. 32. Thank you! vsantana@ic.unicamp.br Acknowledgments FAPESP (#grant 2009/10186-9)Icons source: http://openiconlibrary.sourceforge.net/

    ×