Identifying Cross-origin Resource Status Using Application Cache 2015 Network and Distributed System Security Symposium ho Lee , Hyungsub Kim, and Jong Kim Sang ngho POSTECH, Korea February 9, 2015
Web, HTML5, and Threats • Web and HTML5 • The most popular distributed application platform • Rich functionality introduced by HTML5 • Security and privacy threats • Popularity attracts a lot of adversaries. • Rich functionality opens security and privacy holes. • Discovering unrevealed threats of the Web and HTML5 is important. NDSS 2015 2
HTML5 Application Cache (AppCache) • Enabling technology to offline web application • Specify resources to be cached in a web browser • Allow fast and offline access to the cached resources • Potential threat of AppCache • Arbitrary cross-origin resources are cacheable. • Neither server- nor client-side control • Error handing can breach user privacy. • Recognize whether a user can cache specific resources NDSS 2015 3
Motivation and Goal • Motivation • In-depth security analysis of new web functionalities is necessary. • Security analysis of AppCache is insufficient despite its wide deployment. • Research goal • Analyze and solve security problems of AppCache • Discover security problems of AppCache • Suggest an effective countermeasure against the security problems NDSS 2015 4
Contents • Introduction • AppC AppCache che De Details • De Declaration • Pr Proce ocedure and Failure • No Non-ca cacheable URLs • URL Status Identification Attack • Discussion • Conclusion NDSS 2015 5
AppCache Declaration CACHE MANIFEST CACHE: /logo.png <html https://example.cdn.com/ manifest=“example.appcache”> external.jpg … NETWORK: </html> * HTML document declaring AppCache FALLBACK: / /offline.html AppCache manifest NDSS 2015 6
AppCache Procedure web browser site1.com site2.com Visit a web page declaring AppCache Fetch and decode the manifest Download the resources listed in the manifest Re-fetch the manifest to check changes NDSS 2015 7
When Does AppCache Fail? web browser site1.com site2.com Any failure rolls back AppCache to maintain Visit a web page declaring AppCache content consistency. Fetch and decode the manifest invalid or r err rroneous manifest Download the resources listed in the manifest No Non-ca cacheable resources Re-fetch the manifest to check changes Ch Changed ma manifest NDSS 2015 8
Non-cacheable URLs • Invalid URL • No content to be cached • Dynamic URL • Caching dynamic content is less meaningful. • Cache-Control: no-store or no Content-Length • URL with redirections • Final URL can be dynamically changed. • Violation of the same-origin policy is possible. • Refer a cached resource with the URL specified in a manifest NDSS 2015 9
Contents • Introduction • AppCache Details • UR URL St Status Identification • Ba Basics a and A Advantages • At Attack Procedure • Concurr rrent At Attack • Application: Determ rmining Login Status • Discussion • Conclusion NDSS 2015 10
URL Status Identification • Basics • Specify a target URL in an AppCache manifest • Check whether AppCache succeeds or fails • Advantages • Deterministic identification: Don’t measure timing • Identification of URL redirections • Scriptless attack NDSS 2015 11
Attack Procedure: Cacheable URL web browser attack.com target.com Visit a web page declaring AppCache Record browser Re Fetch and decode the manifest in info. Download the target resource Su Succeed Re-fetch the manifest to check changes Ide Identif ify su success ss Re-fetch the manifest to check changes Re Refresh (o (optio ional) nal) Pa Page refreshing lets Ap AppCach che ch check ck the ma manifest’s c changes. NDSS 2015 12
Attack Procedure: Non-cacheable URL web browser attack.com target.com Visit a web page declaring AppCache Re Record browser Fetch and decode the manifest in info. A browser r don’t ’t re-fe fetch the manife fest when the ta target URL is non-ca cacheable. Download the target resource Fail Fa Re-fetch the manifest to check changes Identif Ide ify failure fa Visit a web page declaring AppCache Refresh Re (o (optio ional) nal) … Pa Page refreshing initiates an Ap AppCach che pr procedur dure fr from the e beg eginning. NDSS 2015 13
Concurrent Attack Concurrently inspecting multiple target URLs with multiple iframe tags, web pages, & manifests CACHE MANIFEST <html> <html CACHE: <iframe manifest=“manifest.php? http://target1.com src=“attack_each.php? target=http://target1.com”> NETWORK: target=http://target1.com” </html> * </iframe> <iframe <html CACHE MANIFEST src=“attack_each.php? manifest=“manifest.php? CACHE: target=http://target2.com” target=http://target2.com”> http://target2.com </iframe> </html> NETWORK: … * … </html> … attach_each.php manifest.php attach_all.php NDSS 2015 14
Application: Determining Login Status Determine login status by inspecting URLs with conditional re co redire rections or errors amazon.com/gp/yourstore/home → amazon.com/ap/signin?... tumblr.com/dashboard → tumblr.com/login?redirect_to=/dashboard youtube.com/feed/subscriptions → accounts.google.com/ServiceLogin?... URL URLs redirecti cting non on-lo logged-in in browsers to lo login in pag ages bitbucket.org/account/user/<user-id> github.com/<user-id>/<repository-name>/settings <blog-id>.wordpress.com/wp-admin Pri rivate URLs return rning err rrors to unauthori rized browsers NDSS 2015 15
Contents • Introduction • AppCache Details • URL Status Identification Attack • Di Discu cussion • Problematic Counterm rmeasures • Counterm rmeasure: Cache-Ori rigin • Service Work rker • Co Conclusion NDSS 2015 16
Problematic Countermeasures • Ask user permission for AppCache • Vulnerable to careless users • Always/never check changes in manifests • Vulnerable to page refreshing attacks • Content inconsistency problem • Eliminate web pages having conditional behaviors • Detection and modification of all vulnerable web pages are challenging. NDSS 2015 17
Countermeasure: Cache-Origin • Attach a Cache-Origin header when requesting resources during AppCache • Contain the manifest’s origin • Notify a web application of who initiate an AppCache procedure • Resemble the Origin header of CORS • Abort suspicious AppCache procedures by returning no-store or error code • Cache sensitive resources • Be initiated by doubtful servers NDSS 2015 18
Service Worker • Provide scriptable caches as an alternative to AppCache • Intercept and respond to network requests from certain web pages • Have the same policy to handle URL redirections and errors with AppCache • Also vulnerable to our attacks NDSS 2015 19
Conclusion • We introduced a new web privacy attack using HTML5 AppCache. • Identify the status of cross-origin resources • Do not rely on client-side scripts • Can attack major web browsers • We suggested a Cache-Origin request-header field to mitigate our attacks. • Minor variation of the Origin header • Easy deployment NDSS 2015 20
Backup Slides NDSS 2015 21
Script-based Identification NDSS 2015 22
Execution Time of Concurrent Attack 0.95 s 0.27 s 0.11 s for each URL NDSS 2015 23
Scriptless URL Timing web browser attack.com target.com Visit a web page declaring AppCache Record browser Re Fetch and decode the manifest in info. Download the target resource Re-fetch the manifest to check changes Me Measur ure elapsed d ti time NDSS 2015 24
Recommend
More recommend
