Identifying Cross-origin Resource Status Using Application Cache - - PowerPoint PPT Presentation

▶
identifying cross origin resource status using
SMART_READER_LITE
LIVE PREVIEW

Identifying Cross-origin Resource Status Using Application Cache - - PowerPoint PPT Presentation

Nov 21, 2023 383 likes •636 views

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

slide-1
SLIDE 1

Identifying Cross-origin Resource Status Using Application Cache

2015 Network and Distributed System Security Symposium Sang ngho ho Lee, Hyungsub Kim, and Jong Kim POSTECH, Korea February 9, 2015

slide-2
SLIDE 2

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

slide-3
SLIDE 3

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

slide-4
SLIDE 4

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

slide-5
SLIDE 5

Contents

  • Introduction
  • AppC

AppCache che De Details

  • De

Declaration

  • Pr

Proce

  • cedure and Failure
  • No

Non-ca cacheable URLs

  • URL Status Identification Attack
  • Discussion
  • Conclusion

NDSS 2015 5

slide-6
SLIDE 6

AppCache Declaration

NDSS 2015 6

<html manifest=“example.appcache”> … </html> CACHE MANIFEST CACHE: /logo.png https://example.cdn.com/ external.jpg NETWORK: * FALLBACK: / /offline.html

HTML document declaring AppCache AppCache manifest

slide-7
SLIDE 7

AppCache Procedure

NDSS 2015 7

Visit a web page declaring AppCache Fetch and decode the manifest Re-fetch the manifest to check changes Download the resources listed in the manifest site1.com site2.com web browser

slide-8
SLIDE 8

When Does AppCache Fail?

NDSS 2015 8

Visit a web page declaring AppCache Fetch and decode the manifest Re-fetch the manifest to check changes Download the resources listed in the manifest site1.com site2.com invalid or r err rroneous manifest No Non-ca cacheable resources Ch Changed ma manifest Any failure rolls back AppCache to maintain content consistency. web browser

slide-9
SLIDE 9

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

slide-10
SLIDE 10

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

slide-11
SLIDE 11

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

slide-12
SLIDE 12

Attack Procedure: Cacheable URL

NDSS 2015 12

Visit a web page declaring AppCache Fetch and decode the manifest Re-fetch the manifest to check changes Download the target resource attack.com target.com web browser

Re Record browser in info. Ide Identif ify su success ss Su Succeed Re Refresh (o (optio ional) nal)

Re-fetch the manifest to check changes Pa Page refreshing lets Ap AppCach che ch check ck the ma manifest’s c changes.

slide-13
SLIDE 13

Attack Procedure: Non-cacheable URL

NDSS 2015 13

Visit a web page declaring AppCache Fetch and decode the manifest Re-fetch the manifest to check changes Download the target resource

Re Record browser in info. Ide Identif ify fa failure Fa Fail Re Refresh (o (optio ional) nal)

Visit a web page declaring AppCache … A browser r don’t ’t re-fe fetch the manife fest when the ta target URL is non-ca cacheable. Pa Page refreshing initiates an Ap AppCach che pr procedur dure fr from the e beg eginning. attack.com target.com web browser

slide-14
SLIDE 14

Concurrent Attack

NDSS 2015 14

Concurrently inspecting multiple target URLs with multiple iframe tags, web pages, & manifests

<html manifest=“manifest.php? target=http://target1.com”> </html> <html> <iframe src=“attack_each.php? target=http://target1.com” </iframe> <iframe src=“attack_each.php? target=http://target2.com” </iframe> … </html> CACHE MANIFEST CACHE: http://target1.com NETWORK: * CACHE MANIFEST CACHE: http://target2.com NETWORK: * <html manifest=“manifest.php? target=http://target2.com”> </html>

attach_all.php attach_each.php manifest.php

… …

slide-15
SLIDE 15

Application: Determining Login Status

NDSS 2015 15

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

  • n-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

Determine login status by inspecting URLs with co conditional re redire rections or errors

slide-16
SLIDE 16

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

slide-17
SLIDE 17

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

slide-18
SLIDE 18

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

slide-19
SLIDE 19

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

slide-20
SLIDE 20

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

slide-21
SLIDE 21

Backup Slides

NDSS 2015 21

slide-22
SLIDE 22

Script-based Identification

NDSS 2015 22

slide-23
SLIDE 23

Execution Time of Concurrent Attack

NDSS 2015 23

0.11 s for each URL 0.27 s 0.95 s

slide-24
SLIDE 24

Scriptless URL Timing

NDSS 2015 24

Visit a web page declaring AppCache Fetch and decode the manifest Re-fetch the manifest to check changes Download the target resource attack.com target.com web browser

Re Record browser in info. Me Measur ure elapsed d ti time