scispace - formally typeset
Search or ask a question
Proceedings ArticleDOI

Diesel: applying privilege separation to database access

TL;DR: A system called Diesel is constructed, which implements data separation by intercepting database queries and applying modules' restrictions to the queries, and is evaluated on three widely-used applications: Drupal, JForum, and WordPress.
Abstract: Database-backed applications typically grant complete database access to every part of the application. In this scenario, a flaw in one module can expose data that the module never uses for legitimate purposes. Drawing parallels to traditional privilege separation, we argue that database data should be subject to limitations such that each section of code receives access to only the data it needs. We call this data separation. Data separation defends against SQL-based errors including buggy queries and SQL injection attacks and facilitates code review, since a module's policy makes the extent of its database access explicit to programmers and code reviewers. We construct a system called Diesel, which implements data separation by intercepting database queries and applying modules' restrictions to the queries. We evaluate Diesel on three widely-used applications: Drupal, JForum, and WordPress.

Content maybe subject to copyright    Report

Citations
More filters
Proceedings ArticleDOI
08 Oct 2012
TL;DR: A new web framework, Hails, is presented that adds mandatory access control and a declarative policy language to the familiar MVC architecture and is demonstrated through GitStar.com, a code-hosting website that enforces robust privacy policies on user data even while allowing untrusted apps to deliver extended features to users.
Abstract: Modern extensible web platforms like Facebook and Yammer depend on third-party software to offer a rich experience to their users. Unfortunately, users running a third-party "app" have little control over what it does with their private data. Today's platforms offer only ad-hoc constraints on app behavior, leaving users an unfortunate trade-off between convenience and privacy. A principled approach to code confinement could allow the integration of untrusted codewhile enforcing flexible, end-to-end policies on data access. This paper presents a new web framework, Hails, that adds mandatory access control and a declarative policy language to the familiar MVC architecture. We demonstrate the flexibility of Hails through GitStar.com, a code-hosting website that enforces robust privacy policies on user data even while allowing untrusted apps to deliver extended features to users.

146 citations


Cites background from "Diesel: applying privilege separati..."

  • ...OKWS [46], Diesel [29], and Radiatus [13] are web frameworks that use...

    [...]

Proceedings Article
08 Aug 2012
TL;DR: A security review of 100 Chrome extensions finds that banning HTTP scripts and inline scripts would prevent 47 of the 50 most severe vulnerabilities with only modest impact on developers.
Abstract: Vulnerabilities in browser extensions put users at risk by providing a way for website and network attackers to gain access to users' private data and credentials. Extensions can also introduce vulnerabilities into the websites that they modify. In 2009, Google Chrome introduced a new extension platform with several features intended to prevent and mitigate extension vulnerabilities: strong isolation between websites and extensions, privilege separation within an extension, and an extension permission system. We performed a security review of 100 Chrome extensions and found 70 vulnerabilities across 40 extensions. Given these vulnerabilities, we evaluate how well each of the security mechanisms defends against extension vulnerabilities. We find that the mechanisms mostly succeed at preventing direct web attacks on extensions, but new security mechanisms are needed to protect users from network attacks on extensions, website metadata attacks on extensions, and vulnerabilities that extensions add to websites. We propose and evaluate additional defenses, and we conclude that banning HTTP scripts and inline scripts would prevent 47 of the 50 most severe vulnerabilities with only modest impact on developers.

92 citations

Proceedings ArticleDOI
03 Nov 2014
TL;DR: MACE is the first tool reported in the literature to identify a new class of web application vulnerabilities called Horizontal Privilege Escalation (HPE) vulnerabilities, and works on large codebases, and discovers serious, previously unknown, vulnerabilities in 5 out of 7 web applications tested.
Abstract: We explore the problem of identifying unauthorized privilege escalation instances in a web application. These vulnerabilities are typically caused by missing or incorrect authorizations in the server side code of a web application. The problem of identifying these vulnerabilities is compounded by the lack of an access control policy specification in a typical web application, where the only supplied documentation is in fact its source code. This makes it challenging to infer missing checks that protect a web application's sensitive resources. To address this challenge, we develop a notion of authorization context consistency, which is satisfied when a web application consistently enforces its authorization checks across the code. We then present an approach based on program analysis to check for authorization state consistency in a web application. Our approach is implemented in a tool called MACE that uncovers vulnerabilities that could be exploited in the form of privilege escalation attacks. In particular, MACE is the first tool reported in the literature to identify a new class of web application vulnerabilities called Horizontal Privilege Escalation (HPE) vulnerabilities. MACE works on large codebases, and discovers serious, previously unknown, vulnerabilities in 5 out of 7 web applications tested. Without MACE, a comparable human-driven security audit would require weeks of effort in code inspection and testing.

42 citations

Proceedings Article
Aastha Mehta1, Eslam Elnikety1, Katura Harvey1, Deepak Garg1, Peter Druschel1 
01 Jan 2017
TL;DR: Qapla provides an alternate approach to policy enforcement that neither depends on application correctness, nor on specialized database support, and is evaluated by enforcing applicable policies in the HotCRP conference management system and a system for managing academic job applications.
Abstract: Many database-backed systems store confidential data that is accessed on behalf of users with different privileges. Policies governing access are often fine-grained, being specific to users, time, accessed columns and rows, values in the database (e.g., user roles), and operators used in queries (e.g., aggregators, group by, and join). Today, applications are often relied upon to issue policy compliant queries or filter the results of non-compliant queries, which is vulnerable to application errors. Qapla provides an alternate approach to policy enforcement that neither depends on application correctness, nor on specialized database support. In Qapla, policies are specific to rows and columns and may additionally refer to the querier’s identity and time, are specified in SQL, and stored in the database itself. We prototype Qapla in a database adapter, and evaluate it by enforcing applicable policies in the HotCRP conference management system and a system for managing academic job applications.

37 citations


Cites background or methods from "Diesel: applying privilege separati..."

  • ...Diesel [24] is a framework for applying the principle of least privilege on relational databases....

    [...]

  • ...To provide guarantees against a malicious application, we can also isolate the reference monitor in a separate process [15, 24], or co-locate it with the DB servers....

    [...]

Journal ArticleDOI
TL;DR: A novel scheme that automatically transforms web applications, rendering them safe against SQL injection attacks, which dynamically analyzes the developer-intended query result size for any input, and detects attacks by comparing this against the result of the actual query.

34 citations

References
More filters
Proceedings ArticleDOI
06 Nov 2006
TL;DR: HiStar as discussed by the authors is a new operating system designed to minimize the amount of code that must be trusted, which allows users to specify precise data security policies without unduly limiting the structure of applications.
Abstract: HiStar is a new operating system designed to minimize the amount of code that must be trusted. HiStar provides strict information flow control, which allows users to specify precise data security policies without unduly limiting the structure of applications. HiStar's security features make it possible to implement a Unix-like environment with acceptable performance almost entirely in an untrusted user-level library. The system has no notion of superuser and no fully trusted code other than the kernel. HiStar's features permit several novel applications, including an entirely untrusted login process, separation of data between virtual private networks, and privacy-preserving, untrusted virus scanners.

489 citations

Proceedings ArticleDOI
14 Oct 2007
TL;DR: Flume is presented, a new DIFC model that applies at the granularity of operating system processes and standard OS abstractions (e.g., pipes and file descriptors), designed for simplicity of mechanism, to ease DIFC's use in existing applications, and to allow safe interaction between conventional and DIFC-aware processes.
Abstract: Decentralized Information Flow Control (DIFC) is an approach to security that allows application writers to control how data flows between the pieces of an application and the outside world. As applied to privacy, DIFC allows untrusted software to compute with private data while trusted security code controls the release of that data. As applied to integrity, DIFC allows trusted code to protect untrusted software from unexpected malicious inputs. In either case, only bugs in the trusted code, which tends to be small and isolated, can lead to security violations.We present Flume, a new DIFC model that applies at the granularity of operating system processes and standard OS abstractions (e.g., pipes and file descriptors). Flume was designed for simplicity of mechanism, to ease DIFC's use in existing applications, and to allow safe interaction between conventional and DIFC-aware processes. Flume runs as a user-level reference monitor onLinux. A process confined by Flume cannot perform most system calls directly; instead, an interposition layer replaces system calls with IPCto the reference monitor, which enforces data flowpolicies and performs safe operations on the process's behalf. We ported a complex web application (MoinMoin Wiki) to Flume, changingonly 2% of the original code. Performance measurements show a 43% slowdown on read workloadsand a 34% slowdown on write workloads, which aremostly due to Flume's user-level implementation.

455 citations


Additional excerpts

  • ...Flume [12] accomplishes similar goals, but it is implemented as a user-level reference monitor in Linux instead of as a completely new operating system....

    [...]

Journal ArticleDOI
20 Oct 2005
TL;DR: A new event process abstraction provides lightweight, isolated contexts within a single process, allowing the same process to act on behalf of multiple users while preventing it from leaking any single user's data to any other user.
Abstract: Asbestos, a new prototype operating system, provides novel labeling and isolation mechanisms that help contain the effects of exploitable software flaws. Applications can express a wide range of policies with Asbestos's kernel-enforced label mechanism, including controls on inter-process communication and system-wide information flow. A new event process abstraction provides lightweight, isolated contexts within a single process, allowing the same process to act on behalf of multiple users while preventing it from leaking any single user's data to any other user. A Web server that uses Asbestos labels to isolate user data requires about 1.5 memory pages per user, demonstrating that additional security can come at an acceptable cost.

415 citations

Proceedings ArticleDOI
05 Sep 2005
TL;DR: A technique to prevent this kind of manipulation and hence eliminate SQL injection vulnerabilities is described, based on comparing, at run time, the parse tree of the SQL statement before inclusion of user input with that resulting after inclusion of input.
Abstract: An SQL injection attack targets interactive web applications that employ database services. Such applications accept user input, such as form fields, and then include this input in database requests, typically SQL statements. In SQL injection, the attacker provides user input that results in a different database request than was intended by the application programmer. That is, the interpretation of the user input as part of a larger SQL statement, results in an SQL statement of a different form than originally intended. We describe a technique to prevent this kind of manipulation and hence eliminate SQL injection vulnerabilities. The technique is based on comparing, at run time, the parse tree of the SQL statement before inclusion of user input with that resulting after inclusion of input. Our solution is efficient, adding about 3 ms overhead to database query costs. In addition, it is easily adopted by application programmers, having the same syntactic structure as current popular record set retrieval methods. For empirical analysis, we provide a case study of our solution in J2EE. We implement our solution in a simple static Java class, and show its effectiveness and scalability.

412 citations

Journal ArticleDOI
P. P. Griffiths1, B. W. Wade1
TL;DR: A multiuser database system must selectively permit users to share data, while retaining the ability to restrict data access, and an algorithm for detecting exactly which of B's grants should be revoked is presented.
Abstract: A multiuser database system must selectively permit users to share data, while retaining the ability to restrict data access. There must be a mechanism to provide protection and security, permitting information to be accessed only by properly authorized users. Further, when tables or restricted views of tables are created and destroyed dynamically, the granting, authentication, and revocation of authorization to use them must also be dynamic. Each of these issues and their solutions in the context of the relational database management system System R are discussed.When a database user creates a table, he is fully and solely authorized to perform upon it actions such as read, insert, update, and delete. He may explicitly grant to any other user any or all of his privileges on the table. In addition he may specify that that user is authorized to further grant these privileges to still other users. The result is a directed graph of granted privileges originating from the table creator.At some later time a user A may revoke some or all of the privileges which he previously granted to another user B. This action usually revokes the entire subgraph of the grants originating from A's grant to B. It may be, however, that B will still possess the revoked privileges by means of a grant from another user C, and therefore some or all of B's grants should not be revoked. This problem is discussed in detail, and an algorithm for detecting exactly which of B's grants should be revoked is presented.

389 citations