ScriptChecker: to Tame Third-party Script Execution with Task Capabilities.

We present ScriptChecker, a novel browser-based framework to effectively and efficiently restrict third-party script execution according to the host web page's directives.Different from all existing schemes functioning at the JavaScript layer, ScriptChecker holistically harnesses context separation and the browser's security monitors to enforce on-demand access controls upon tasks executing untrusted code.The host page can flexibly assign resource-access capabilities to tasks upon their creation.Reaping the benefits of the task capability approach, ScriptChecker outperforms existing techniques in security, usability and performance.We have implemented a prototype of ScriptChecker on Chrome and rigorously evaluated its security against 1373 malicious scripts and its usability with empirical studies upon top-1000 sites.The experimental results show that its strong security strength and ease-of-use are attained at the cost of unnoticeable performance loss.It incurs about 0.2 microseconds overhead to mediate a DOM access, and 5% delay when loading popular JS graphics and utility libraries. I. INTRODUCTIONThird-party scripts provide ready-to-use functions for specialized utilities (e.g., jQuery [15] and CryptoJS [13]) and Web feature enrichment (e.g., Yahoo Partner Ads [19] for advertisement and userreport [18] for user tracking).According to Nikiforakis et al. [44], 88.45% of web sites include at least one third-party script.They are greatly attractive to web page developers thanks to the remarkable saving in implementation.However, it has been known for years that invoking a third-party script function potentially invites unintended or even malicious code execution with the full privileges to access all resources [44], [37], [36], [33], [53].The third-party script security problem is challenging for two reasons.First, a host script and a third-party script are colocated in the same host frame and therefore have the same origin and frame identity.Thus, frame oriented or origin oriented policies and mechanisms, e.g., the same-origin policy [16], iframe isolation [6], the feature-policy header [20], and CSP [11], are unable to differentiate and handle them separately.It is hence necessary for a solution to draw the boundary