Overall, the security expressiveness of the available REST-based web service description lan-guages is still at its beginning. Besides authentication and authorization, there are no further security capabilities expressible by default and even these very basic protections are not provided by all of the analyzed languages (see Table3.2). ReLL in conjunction with ReLL-S is the only approach which consider the integration of all standardized authentication and authorization schemes. Also, the ontology of ReLL-S provides service description elements for all security mechanisms except non-repudiation. The other evaluated service description technologies lack on a native definition of standard protection means or have restrictions in terms of extend-ing and definextend-ing security mechanisms. Moreover, none of the evaluated approach provide a comprehensive description on TLS and the protection of the resource representation.
One reason for this current situation may lie in a lacking overall REST-Security framework [Gor+14a]. As current research activities are enhancing this field [LN15a; NL15; NL16], new REST-Security components may be evolved in the future. Hence, REST-based service description languages need to cope with this by an increased extensibility in respect to security-related expressiveness.
This shows that a bunch of research and development challenges still exist in order to find a service description language and a security policy framework for REST-based systems which can serve as a standard such as WSDL and WS-SecurityPolicy for the SOAP domain. As many service definition technologies have been proposed, further work will therefore focus on enhancing available languages in terms of security expressiveness and extensibility, instead of proposing a new approach. Also, future studies will analyze REST-based service description languages for other REST-based protocols including CoAP and RACS.
Chapter 4
Systematic Analysis of Web Browser Caches
Summary of this publication
Citation H. V. Nguyen, L. Lo Iacono, and H. Federrath. Systematic Analysis of Web Browser Caches. In: 2nd International conference on Web Studies (WS). 2018. URL: https://doi.org/10.
1145/3240431.3240443 Status of Paper Published
Type of Paper Research Paper (Conference) Ranking No ranking available
Aim In this paper, we introduce a tool-based approach for testing web caches. In particular, our approach includes a cache testing tool, a test suite containing 415 test cases as well as a test specification language which allows changing and extending test cases. We use this testing approach to analyze the compliance of the web browser caches in Chrome, Firefox, Safari and, Microsoft Edge.
Methodology To define a comprehensive test suite that covers all facets of web caching, we review the HTTP caching RFC 7234 and available literature on web caching.
Contribution The analysis shows many diversities as well as discrepancies. As our baseline of test cases is specified using a specification language that enables extensibility, developers as well as administrators and researchers can systematically add and empirically explore caching properties of interest even in non-browser scenarios.
Co-authors’ contribution See Paper 3 in Section1.1.1.
4.1 Introduction
The web can be considered as the world’s largest distributed system. Its ability to scale at large has been its formula of success ever since. To obtain high scalability, web caching systems are applied—among others—for optimizing network performance. A web cache is a subsystem for coordinating the transparent storage and retrieval of recyclable HTTP responses. By this, a web caching system potentially reduces three quantities: the number of requests that reach the origin server, the amount of network traffic resulting from document requests, and the latency that an end-user experiences in retrieving a document [Wan99]. Moreover, when serving recurring requests on behalf of an origin server that is not responding for some reasons, caches contribute to an increased availability of web-based services. Web caching systems can occur in various locations between the path from client to server. They can be implemented either as an external middlebox between the client and server application or as middleware which is included as an internal component in the client and server application. For instance, the web browsers Chrome, Firefox, Safari or Edge include a client-internal cache which store and reuses frequently requested web resources such as HTML documents, Javascript files, images or stylesheets.
For web developers and vendors of web browsers, the knowledge of and compliance with caching standards is crucial in many respects. Disobeying the standardized requirements and control directives impairs scalability and performance. Also, ignoring caching policies may induce security and privacy issues, if sensitive information are cached and reused although being prohibited. To prevent issues stemming from inappropriate web caching, one need to have a deep understanding of the current state of play. In Section4.2we therefore briefly recap key aspects of web caching. Based on these foundations, in Section4.3we give insights on web browser caches and the consequences of caching misbehavior. With the aim to detect compliance issues in web browser caches, we mandate for proper test tools that are currently lacking, as the related work review in Section 4.4 manifests. As a first contribution, we introduce a methodology for deriving meaningful test cases for auditing cache systems in Section 4.5. Following the proposed methodology, we were able to define 397 tests, which we compile to a general cache testing suite (see Section4.6). With the purpose to evaluate the proposed approach and obtain a systematic analysis of available web browser caching systems, we conduct an empirical study of client-internal web caches residing in Chrome, Firefox, Safari and Edge. The main results are discussed in Section4.7. Overall, they do affirm the relevance of appropriate cache testing tools supporting developers of caching components as well as developers instrumenting them in their web applications. We conclude this paper in Section7.8with an outlook on challenges in web caching.