PathCutter: Severing the Self- Propagation Path of XSS JavaScript Worms in Social Web Networks Yinzhi Cao §, Vinod Yegneswaran †, Phillip Porras †, and Yan Chen § § Northwestern Lab for Internet and Security Technology, Northwestern University, Evanston, IL † SRI International, Menlo Park, CA 1

Social web networks – Platforms where people share their perspectives, opinions, thoughts and experiences – OSNs, Blogs, Social bookmarking etc. XSS worm threat is severe. – First worm: MySpace Samy (2005) – More and more prevalent: Renren, Yamanner, etc. – Akin to virus: human need to visit infected pages – Characteristic: Fast spreading In this paper, – Target: Prevent XSS worm propagation – Method: View separation & Request authentication Introduction Number of infected clients after 20 hours (Social Networks’ XSS Worms, Faghani et al.) 2

Roadmap Introduction Background – Attack Steps – XSS Taxonomy Related Work Our Approach Implementation Evaluation 3

Background Step 1 – Enticement and Exploitation Step 2 – Privilege Escalation Step 3 – Replication Step 4 – Propagation Download Modify benign user’s account Get infected Benign User Samy’s page Repeat Process Other Users 4

XSS Attacks Server-side XSS Content Sniffing XSS Stored XSS Reflected XSS Client-side XSS Plugin XSS DOM-based XSS Flash XSS Java XSS MySpace Samy Worm Yamanner Worm Renren Worm SpaceFlash Worm Our Experimental Worm XSS Taxonomy 5

Related Work Group one: Prevent XSS vulnerabilities – Incomplete coverage (BluePrint, Plug-in Patches, Barth et al., and Saxena et al.) Group two: Prevent XSS worms – No early-stage prevention (Spectator and Xu et al.) – Not resistant to polymorphic worm (Sun et al.) Our goal: Prevent all the XSS worms with early-stage prevention and resistance to polymorphic worms 6

Our Approach Two key concepts: (1) request authentication and (2) view separation Download Samy’s page Modify benign user’s account Benign User Access We use request authentication. View separation is always enforced. 7

For example, blog A, blog B, blog C and so on. Or more fine-grained, different pages in the same blog. Isolating contents from the same origin – iframe tag with sandbox properties in HTML5 – Pseudodomain encapsulation (mentioned later) View Separation View OneView Two 8

Request Authentication For example, requests from blog A does not have permissions to modify blog B Identifying which view a client-side request is from. – Secret token – Referer header Check if the view has the permission 9

Our Approach Download View One Modify benign user’s account Benign User Access View one does not have the permission. Isolating views at client side. View Two Identify that it is from View One. If we cannot identify, deny. 10

Roadmap Introduction Background Related Work Our Approach Implementation – Implementation One (Server Modification) – Implementation Two (Proxy) Evaluation – Case Study of Five Real-world Worms and Two Experimental Worms (only two covered in the talk) – Performance 11

Implementation One (Server Modification) Prototype examples: WordPress, Elgg Dividing views: by blogs Permissions for different views: can only modify its own blog. 12

View Isolation for Server Modification Isolating views at client side. – Pseudodomain encapsulation. isolate.x.com content.x.com isolate.x.com content.x.com attacker content.x.com It cannot break isolate.x.com (different origin). Secret token is required. 13

Request Authentication for Server Modification Identifying requests from client-side – Secret token Insertion position: Each request that will modify server- side contents. Checking requests’ permission – Checking position: Database operation. (A narrow interface that each modifying request will go through.) 14

Implementation Two (Proxy) Dividing views: by different client-side URLs. Permissions for different views: – Possible outgoing post URL from those URLs 15

View Isolation for Proxy Isolating views at client side – The same as implementation one. Request content.x.com/y.php isolate.x.com <iframe src = “content.x.com/y.php?t oken = *** isolate.x.com content.x.com Proxy Web Server Redirect to isolate.x.com 16

Request Authentication for Proxy Identifying requests from client-side – Referer header Specified by the browser. Attackers cannot change it. Checking requests’ permissions – Checking position: Proxy. – Method: See if the view has the permission to send the request. 17

Case Study for Real World Worms XSS Worm in Renren (Facebook in China) Flash insert malicious scripts inside the web page Share on the behalf of current user 18

share View One View Two click Request to share 19

Yamanner Worm Click Send s to all your contacts 20

Compose body Different views Send 21

Memory Overhead – Normally, # of frames is not high since comments can be hidden. Rendering Time Overhead. – Less than 3.5% for Elgg Evaluation 22

Conclusions We cut off the propagation path of XSS worms through view separation by psuedodomain encapsulation and request authentication. We implement PathCutter by proxy assistance and server modification. We evaluate PathCutter on 5 real-world worms and 2 proof-of-concept worms. 23

Thanks! Questions? 24

Backup 25

Comparison with Existing Works Spectator Sun et al. Xu et al. BluePrint Plug-in Patches Barth et al. Saxena et al. PathCutter Blocking Step Polymorphic WormYes No Yes Early-Stage PreventionNoYesNo Yes Types of XSS that Can Be DefendedAll Passively Observable Worms Traditional Server-side XSS Worms Plug-in XSS Worms Content Sniffing XSS Worms DOM-Based XSS WormsAll Deployment Server or ProxyClientServer Client Server or Proxy Passive/Active MonitoringActivePassive Active Group One: Mitigating XSSGroup Two: Worm prevention 26

Limitation Need to know the semantics of web application Only prevent worm behavior but not all the damages 27

Existing solutions Spectator … if it reaches a threshold, report it. the same injected tag proxy But it can only detect the worm when it spreads for a while! 28

Existing solutions Esorics 09 Firefox Plugin malicious benign Payload: abcdefg The same payload Deny! But (1) Payload may change. (2) Pure client-side solution. 29

URL graph provided by the server or a third-party blogX/index.php blogX/post-comment.php blogX/options.php blogX/update- options.php blogX/x.php … blogY/index.php 30