Slides presented during the WWW/Internet 2011 in Rio.

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 Henriques
School of Electrical and Computer Engineering

2. Agenda
• Problem and context
• Objective
• Security and JavaScript
• Literature review
• Framework proposal
• Conclusions
2

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

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

5. Problem and context:
HTML, CSS, and JavaScript
...
var url = { toString: function(){
this.toString() = function(){
return “bad” ;
} ;
return “good” ;
}
} ;
...
5

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

7. Problem and context:
Widget and Mashup
Widget server
7

8. Problem and context:
Widget and Mashup
8

9. Problem and context:
Widget and Mashup
Web page is a
point of attack
Communication is a
point of attack
9

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

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

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

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. Security and Javascript:
Data exchange
Mashup built at the server
Web page server
Widget server
16

17. Security and Javascript:
Data exchange
Mashup built at the server
17

18. Security and Javascript:
Data exchange
Mashup built at the server
18

19. Security and Javascript:
Data exchange
Mashup built at the server
19

20. Security and Javascript:
Data exchange
Mashup built at the client
Widget server
Web page server
Widget server
20

21. Security and Javascript:
Data exchange
Mashup built at the client
21

22. Security and Javascript:
Data exchange
Mashup built at the client
22

23. Security and Javascript:
Data exchange
Mashup built at the client
23

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

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> tag
25

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

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

28. Framework proposal:
Overall architecture
28

29. Framework proposal:
Using current technologies
29

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 users
30

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 applications
31

32. Thank you!
vsantana@ic.unicamp.br
Acknowledgments
FAPESP (#grant 2009/10186-9)
Icons source: http://openiconlibrary.sourceforge.net/