|dc.description.abstract||Today's systems abstract the implementation details of common services such as secure client-server communication, access to native device resources (e.g. camera), access to cloud-stored files and folders, etc. by exposing a set of application programming interfaces (service APIs) to applications and software packages.
In this dissertation, we analyze service APIs exposed by modern systems across all layers of the software stack and demonstrate that they are too complex for developers to understand and use correctly. Instead of providing high-level abstractions such as authorization and authentication, they provide low-level details such as callbacks, options and flags. As a result, service APIs used in security-critical software often end up being misconfigured and exposing sensitive users' data to botnet, Web and network attackers.
To demonstrate the pervasiveness of the problem, we perform the first systematic analysis of insecure usage of service APIs in modern software developed and maintained by both individual developers and large software companies.
First, we analyze the perils and pitfalls of low-level service APIs for establishing secure network channels. SSL/TLS (Secure Sockets Layer/Transport Layer Security) is currently the de facto standard for secure Internet communication; its security against active network attackers depends on properly validating server certificates at connection establishment. Unfortunately, our analysis shows that SSL/TLS APIs are often poorly understood and used. As a consequence, server certificate validation is completely broken in many security-critical applications and libraries, and thus exposes users' data to network attackers.
Third, we analyze service APIs exposed by today's Web-based application platforms. This new class of platforms provide browser-like runtime environments to support Web-based applications. Such apps run outside the traditional Web browser and enjoy direct access to native objects such as files and GPS. However, unlike the service APIs exposed by hybrid frameworks, this category of service APIs is exposed by the platforms themselves, effectively eroding the distinction between desktop, mobile, and Web-based software. Unfortunately, we demonstrate that the access-control models used by Web-based application platforms are inadequate. As a result, when applications request access to sensitive resources for their own code, they unintentionally enable it for untrusted third-party code, too.
Fourth, we study server-side service APIs exposed by some of today's cloud services and demonstrate that many of them are vulnerable to scanning and thus leak users' data. For example, we show that cloud storage providers that allow users to share files and folders via short URLs and support APIs for easy account traversal end up exposing their users to large-scale privacy and security breaches.
To address the vulnerabilities plaguing today's service APIs, we suggest that new principled service APIs be designed, implemented and deployed at all levels of the software stack. Unlike the old APIs, the new service APIs must provide simple interfaces through which developers can easily specify their high-level security objectives such as confidentiality and authentication.
In this dissertation, we implement two new principled mechanisms for enforcing security in service APIs used by Web code of modern hybrid and Web-based apps. We also provide recommendations for improving the security of SSL/TLS APIs and APIs for managing cloud-stored files.
Our first prototype system is called NoFrak. It introduces a new technique for protecting native access APIs in hybrid apps from "fracking" attacks. NoFrak is platform-independent and requires no changes to the code of existing apps.
Our second system is PowerGate. In its core, PowerGate is a new access-control mechanism for protecting APIs to native objects in Web-based applications from unauthorized access. PowerGate enables application developers to write well-defined access-control policies with explicit principals such as "application's own local code" and "third-party Web code".||en