DATS — Programmability and Security by Design for Web Applications
Casen Hunger1 Llu´ıs Vilanova1 Charalampos Papamanthou University of Texas at Austin Technion — Israel Institute of Tech. University of Maryland (UMD) [email protected] [email protected] [email protected]
Yoav Etsion Mohit Tiwari Technion – Israel Institute of Technology University of Texas at Austin [email protected] [email protected]
Abstract 1. Introduction Using data-centric containers for isolation is a very effective Web applications have to implement a wide array of security way to give users control of their data and avoid information features, such as input sanitizing, authorization, and access leaks from untrusted applications. However, they are hard control checks [13]. However, developers often implement to program for and lead to inefficiencies, since they require these features incorrectly [8, 18] and do not update all li- replicating an application inside each container. braries promptly [19]. Web applications are vulnerable to We propose DATS — a system to run web applications “zero-day” vulnerabilities [5]. A compromised web applica- that retains application usability and efficiency through a tion can then exfiltrate data to unauthorized users and cause mix of hardware capability enhanced containers and the large data breaches. Worse, the threat of exploits forces con- introduction of two new primitives modeled after the popular siderable penetration-testing and compliance-certification model-view-controller (MVC) pattern. (1) DATS introduces work that slows down application development. a templating language to create views that compose data Ideally, users and enterprises would store their data on across data containers. (2) DATS uses authenticated storage storage platforms (e.g., Google Drive or electronic medical and confinement to enable an untrusted storage service such record (EMR) systems), use untrusted web applications that as memcached and deduplication to operate on plain-text integrate with these storage platforms, and yet protect their data across containers. These two primitives act as robust data from being breached — i.e., enforcing mandatory ac- declassifiers that allow DATS to enforce non-interference cess control (MAC) over the untrusted applications. Figure 1 across containers, taking large applications out of the trusted shows a simplified setting where a doctor (Dave) shares fold- computing base (TCB). ers with patients Alice, Bob, and Eve, and uses untrusted We showcase various web applications including gitlab applications for messaging and scheduling. and a Slack-like chat (eight in total), significantly improve A natural strategy is to use data containers: run an entire the worst-case overheads due to application replication, and application instance within the context of each data object, demonstrate usable performance for common-case usage. with each instance isolated into a separate container[35, 44, 69, 77]. The access control rules will hold by definition even CCS Concepts Security and privacy Authentica- if an application instance is compromised or malicious (no tion; Access control• ; Authorization; Web→ application se- information can be transferred across containers for different curity; Operating systems security; Information flow control data objects). One could use language-level information flow 1 Equal contributors. control (IFC) to achieve the same goals (e.g., Hails [39] provides a Haskell framework that attaches labels to data in database models), but this compromises programmability. Developers rely on a large body of existing frameworks Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and languages, and we cannot therefore limit them to only and the full citation on the first page. Copyrights for components of this work owned by others than the author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to using vetted options. The advantage of most OS container lists, requires prior specific permission and/or a fee. Request permissions from [email protected]. ASPLOS ’18, March 24–28, 2018, Williamsburg, VA, USA technologies is that they can isolate unmodified code. c 2018 Copyright held by the owner/author(s). Publication rights licensed to ACM. Data containers thus raise two new challenges. Usability: ISBN 978-1-4503-4911-6/18/03. . . $15.00 DOI: https://doi.org/10.1145/3173162.3173213 for example, a calendar application cannot aggregate into a Application-centric (i.e., “get(keyx)”) to ensure that it only returns the value from the most recent “put(keyx, val)” operation on the Users Dave Alice Bob Eve same data object – interestingly, we use this to ensure that storage does not leak information across data objects. Labels / folders Fracture'13 Fever'14 Flu'15 Container technologies are available in production sys- tems, but replicating an application instance on each of them has intrinsic inefficiencies known as multi-execution [26]. Apps Messaging Scheduling Performance is largely secondary for enterprises (they have far fewer users than internet-scale services), but multi-
Msg@ Msg@ Msg@ Event@ Event@ Event@ execution can become a problem when operating across a Storage Fracture'13 Fever'14 Flu'15 Fracture'13 Fever'14 Flu'15 large number of data objects (e.g., search). We therefore Data-centric also explored using harwdare-assisted thread containers to
Users avoid multi-execution. Dave Alice Bob Eve DATS and the client browser are the only components that reside in the trusted computing base (TCB), while ensur- Labels / Fracture'13 Fever'14 Flu'15 ing applications remain programmable, usable and efficient. folders IFC efforts like Hails [39] and Jeeves [74] are instead a great Messaging Messaging Messaging fit to the trusted developers of DATS’s TCB. Enterprises can Apps+ Scheduling Scheduling Scheduling Msg@ Msg@ Msg@ Event@ Event@ Event@ Storage Fracture'13 Fever'14 Flu'15 then leverage the vast space of existing and untrusted web Fracture'13 Fever'14 Flu'15 applications, frameworks, languages and developers, and at Figure 1: Current systems have application-centric access the same time avoid costly application code audits. We make controls (top) and cannot prevent data leaks; e.g., a compro- the following contributions: mised or malicious “Scheduling” application can leak Al- • We design and implement the DATS system ( 3 and4). ice’s events to Eve (from “Fracture’13 ” to “Flu’15 ”). §§ Data-centric access controls (bottom) enforce users’s ACLs • We evaluate programmability and security by developing 4 applications and porting 4 existing ones ( 5 and6). on all applications: data is confined to its respective label. §§ • We evaluate performance with existing OS-level contain- ers [10, 61] and a HW-capability architecture [32, 66] single page the information from the appointments in differ- ( 7). ent data objects. Efficiency: applications cannot use a single § storage services like deduplication across data objects. In this paper we present the DATS system, which refac- 2. Motivation tors authentication and access controls outside of untrusted Many enterprises use web-based applications for security- web applications. DATS couples data containers in a novel sensitive data (e.g., a hospital). Currently, the TCB includes way to trivially enforce access controls at the container every application since an application-level exploit can put level, together with two new mechanisms to robustly declas- all data at risk. Such applications are thus built, certified, sify [76] information from multiple data objects. It lever- and audited for security first, with performance being a sec- ages the model-view-controller (MVC) pattern common in ondary concern [9]. This accrues large costs from highly many web applications, while maintaining application pro- skilled security-aware programmers, and long and costly grammability by presenting a familiar programming model penetration-testing and compliance-certification work be- to developers and supporting several existing web applica- fore the smallest changes can be pushed into production. tion frameworks and languages. This is clearly at odds with rapid application development First, DATS recovers usability by securely composing and deployment cycles and cost-efficiency; one cannot em- views from multiple data objects. Applications can provide ploy the vast majority of existing web developers, who are an untrusted view template to a trusted template processor not security-savvy, nor leverage existing applications and to aggregate information from each per-data object container development frameworks. We therefore want a systematic into a single page, like in many existing view templating lan- approach to provide security and cost-efficiency for such guages [16]. The declassifier transparently applies language security-sensitive applications. level IFC to prevent information leaks across data objects. Figure 1 shows a simplified setting where a doctor (Dave) Second, DATS improves efficiency by securely sharing shares folders (i.e., access control domains or security la- untrusted storage services across data objects. Applications bels) with patients Alice, Bob, and Eve, and uses untrusted can use a trusted storage declassifier that interposes between applications like “Messaging” and “Scheduling”. Access applications and untrusted shared model (e.g., for dedupli- control lists (ACLs) provide users a simple and intuitive cation, key-values stores, compression, etc.). The declassi- way to express data confidentiality expectations for many fier performs integrity checks on each data read operation applications; e.g., Dave explicitly decides to share folder “Fracture’13 ” with Alice in Figure 1. Our “folders” are • Integrity: We do not prevent untrusted applications from the “control domains” in the security literature, and folder mangling user data or destroying it. Systems such as ACLs serve as security labels for the data inside folders. Frientegrity [37] handle it orthogonally. Existing systems provide application-centric policies • Information leaks via timing or termination channels: We (top of Figure 1); they can isolate applications from each assume techniques that either randomize (e.g., fuzzing [65]) other, but a compromised application can access data from or normalize (e.g., deterministic execution [25] or pre- multiple access control domains, even if users correctly dictive mitigation [23]) the timing of outputs (e.g., on a set their folders’s ACLs. For example, a buggy or mali- storage app channel, possibly coupled with behav- cious “Scheduling” application can store events intended ioral/anomaly→ detection for termination channels). for folder “Fracture’13 ” into “Flu’15 ” when processing Dave’s appointments. Even if all applications restrict Eve to • Privacy-preserving data mixing: Cross-folder function- only access “Flu’15 ”, this folder now contains events exfil- ality such as analytics (e.g., clustering or training classi- trated from “Fracture’13 ”. In the worst case, data from all fiers) fundamentally violates the access control policies folders could be exfiltrated, violating all user confidentiality set by users. Complementary approaches such as differ- expectations. Instead, a data-centric MAC policy (bottom of ential privacy [34, 50, 51, 55, 56] or quasi-identifier based Figure 1) provides an intuitive alternative, where data from privacy [47, 49, 64] show that this functionality can di- different folders cannot interfere with each other. rectly integrate with DATS: the functions can be executed In this section, we describe the challenges in enforcing in isolation and only their perturbed output released (e.g., data-centric MAC over untrusted applications, and the op- GUPT [51]). Similar declassifiers can be built for adver- portunity inherent in the structure of MVC applications to tisement impressions [45] and for sending debugging out- refactor security out of the application requirements. put [27] back to developers.
2.1 Threat Model 2.2 Challenges in enforcing Data-centric MAC Our threat model for web applications has the client browser OS-level MAC: The simplest way to enforce data-centric and the server-side platform (i.e., the hardware, hypervisor MAC is to run an application process per folder inside an and DATS’s core components) as part of the TCB. The OS-level container using LinuX Containers [10], SELinux applications, their libraries and storage backends (such as MAC [61], capabilities [69], or IFC at the OS-level (OS- key-value stores) are hosted on the platform, but are outside IFC) [35, 44, 52, 77]. the TCB; this also includes application code running on This approach curtails crucial functionality. It cannot sup- the client’s browser (e.g., using JavaScript). DATS aims to port web pages that display data from multiple folders (i.e., prevent the following attacks by refactoring authorization cross-folder views), since the application has access to a sin- and access control out of the untrusted components: gle folder. For example, Dave will need to open each per- folder “Scheduling” application to manually find a free slot Code-driven folder interference: Untrusted code and de- for a meeting, a tedious and error-prone operation. velopers are considered an attacking subject — either di- A per-folder application instance can also be inefficient, rectly through malicious intention, or indirectly through since a single MVC model cannot optimize storage across buggy code — and must not be able to leak data across folders. For example, data deduplication has to work across any two folders (or arbitrary internet addresses). In in- all folders in order to find unencrypted data to consolidate. formation flow terms, the users’s requirement is non- Storage services such as in-memory key-value stores (e.g., interference [40] across folders. Redis, memcached) or distributed coding also work across User-driven folder interference: Users (authorized or oth- folders and will be inefficient if we run a separate instance on erwise) are considered an attacking subject and must be each folder. Furthermore, running multiple instances of an prevented from violating non-interference across unau- application can sometimes lead to poor resource utilization thorized folders. This includes exploiting the untrusted in the micro-architecture (i.e., multi-execution [26]). code through memory errors, malicious inputs, etc. or PL-level MAC: Programming-language (PL) level IFC [39, running arbitrary code to access unauthorized folders. 59, 75] can control the flow and aggregation of information We otherwise consider authorized users trusted; they inside an application (such as creating cross-folder views) fully delegate trust in handling sensitive data to other and enforce data-centric MAC policies. But it requires care- users with whom they share folders. We do not protect ful annotation of program inputs, intermediate variables, and against poor judgment when sharing a sensitive file with outputs to ensure information does not flow between inputs another user, who is free to manually communicate its and outputs with incompatible ACLs. This makes PL-MAC contents to another authorized folder or anywhere else. notoriously complex to use in practice, requires developers to have extensive security expertise, and constrains them to We limit the scope of our problem and list complemen- specific programming frameworks. Further, PL-MAC only tary techniques to handle other risks to user data: works as long as application developers are trusted [59], or when the trusted platform developers maintain the data ACLs are implemented by DATS – applications need not model for all third-party applications [39]. implement further ACL rules. Finally, optimizations such as deduplication cannot be A typical user flow will start with an application land- represented in a PL-MAC solution, since it compares data ing page such as a calendar overview across all their folders across folders and executes code based on this comparison. ( A and B in Figure 2). The user can then click on spe- cific appointments to get or set additional information ( C ), 2.3 Opportunities in MVC Applications and move in and out of calendar (cross-folder) and appoint- MVC frameworks are popular in web applications and re- ment (per-folder) views. Users can also set preferences used quire developers to write separate components and strict in- across folders, such as profile pictures, names, etc. Since this terfaces between views and controllers as well as controllers data is made explicitly public to all folders without using any and models. We can use these interfaces to transparently en- folder, we term such functionality as non-folder. force data-centric MAC over the entire web application. Based on this usage model, DATS starts an application in Views in MVC applications separate presentation from a non-folder container ( 1 ), which cannot access user data application logic using templating languages. These lan- from any folder (only sees the users’ public settings and guages are meant to arrange data in different ways instead application’s resources). DATS sets up a container to create of creating new information from data, so they allow us to cross-folder views ( 2a and 2b leading to B ), and then sets impose PL-level MAC without being undermined by point- up per-folder containers in 3 as the user traverses links out ers, reflection, and other features of full-featured languages. of cross-folder into per-folder views. We now describe the Storage (i.e., model) optimizations implement diverse developer’s view of application components on DATS. functionality in arbitrary languages, but they do not affect App components contain entire (untrusted) applications the ACLs of user data — i.e., storage components are in- and are instantiated multiple times. Each instance runs in an visible to users. Furthermore, several popular and complex OS-level container [4, 10, 60](app column in Figure 2) with web services expose variants of a simple put-get inter- a trivial data-centric MAC policy: it has exclusive access to a face, like deduplication, in-memory key-value stores (mem- single folder, and no other external resources. Containers get cached), and cloud-based storage services such as Amazon a standard system view, including system calls, libraries, and S3 and Google Drive. Interposing a transparent integrity- runtimes for any development framework, and also cover the checking proxy on this common interface enables untrusted client browser. This is key for programmability given the di- services to work with plain-text data. This is essential for versity in toolkits and languages for developing applications. services like deduplication (that will not work if data is en- This “data container” approach however forbids cross- crypted) and allows services to compress, index, or other- folder functionality, breaking the usability and efficiency of wise optimize storage across all folders. most applications. DATS thus provides two robust declassifi- cation [76] mechanisms for cross-folder functionality, guar- 3. Design of the DATS System anteeing that untrusted code cannot affect declassified data. Template files describe how to aggregate information DATS ensures that untrusted applications cannot mix infor- from multiple folders into a single cross-folder view, making mation across folders by executing a unique web-application applications usable. The template in Figure 2 is provided instance for each folder. In this section, we describe how by the non-folder app in 2a . A trusted Template Processor DATS enables untrusted applications to implement cross- inflates templates with data from each per-folder app in- folder views and storage without breaking this folder non- stance ( 2b ) through a simple form of PL-level IFC: it gen- interference policy. We also describe hardware-assisted OS erates HTML/JS by processing only one data element at a containers that help reduce the overhead of multi-execution time, and each output (e.g., link) can only send information in DATS. We begin in Figure 2 with a typical user work- back to the app instance that produced it (e.g., 3 ). flow, and walk through the key steps in the lifecycle of an Storage components (untrusted storage column in application on DATS. Figure 2) implement the application’s cross-folder models DATS exposes Data objects (called folders) to users, to make these efficient. DATS interposes a trusted Storage similar to platforms like Google Drive, Box, or Dropbox. Declassifier on the app–storage communication. The Stor- Users express their confidentiality policies (i.e., who can age Declassifier uses integrity checking to ensure that each access which folders) using simple per-folder ACLs. Every response value of a “get(key)” request from a folder is folder can hold arbitrary data, making them independent the same as the last “put(key, value)” for that folder. In- of application-specific constructs like messages, documents, terestingly, integrity checking the put-get interface and con- medical records, etc., and DATS enforces folder-level ACLs fining the storage services in a container enables these un- on untrusted third-party applications that attach to users’ trusted services to work with plain-text data. Drive/Box accounts. Folders are color-coded in the figure We start with the security invariants in DATS ( 3.1), (green, red or blue) to easily track information flow across followed by details about each component ( 3.2 to 3.6§ ). the system. Like Google Drive, users, folders, and their §§ Figure 2: Example web page flow from a user (“client-side”), DATS’s main components and an application’s app-template- storage components (and their relation to MVC). Application code & data and storage backends are untrusted (grayed areas), while DATS enforces folder non-interference. Application components run inside OS-level containers, which can very easily enforce per-folder MAC policies. Note that the client’s browser is allowed to run untrusted application code (e.g., JavaScript).
3.1 Security Invariants in DATS dressed using complementary techniques (see 2.1). DATS § DATS guarantees end-to-end folder non-interference, cover- Storage Declassifier and confinement together demonstrate ing apps and information flow-secure views and storage. a novel method of using an authenticated storage interface to (1) Each app instance runs in a confined container – enforce non-interference. conceptually, each container covers server and client devices DATS’s guarantees rely on a few fundamental primitives: – with access to only one folder. This ensures baseline folder containers on server and client, IFC in the Template Pro- non-interference for app instances. cessor, and integrity checking in the Storage Declassifier. (2) DATS’s Template Processor uses untrusted templates The Template Processor and Storage Declassifier provide from the application and untrusted results from many fold- robust declassification [76] for cross-folder functionality – ers to construct a view, but ensures that communication from i.e., guarantee that untrusted code or data in a folder can- the view back to an app instance only uses data from that not affect messages/data that is sent from a cross-folder con- same instance. The Template Processor prevents explicit in- tainer back to a different per-folder container. formation flows by ensuring each HTML element that can DATS extends containers into the client browser by us- send a request (e.g., a link) contains information from at ing one sub-domain per app instance (browser origin in Fig- most one folder, and points to the app instance that has ure 2). DATS then activates the Same-Origin Policy (SOP) access to it. It also prevents implicit information flows by and Content Security Policy (CSP) on the client browser to using a template language that does not allow predicates limit access to remote resources and confine untrusted client- and conditional loops over results from different folders. side code (e.g., JavaScript) within each sub-domain (con- Fortunately, view templating languages are already moving tainer). DATS also drops all cookies set for parent domains. towards such restrictions to minimize business logic inside Containers on the server can be implemented directly as ref- the presentation layer [12]. erence monitors (e.g., SELinux or LXC), or using capabili- (3) DATS’s Storage Declassifier ensures that a get value ties or information flow control – DATS deployers can pick returned to an app equals that last value that was put by one based on performance and compatibility constraints. the app – hence, the untrusted storage service can oper- Components interact with DATS abstractions using an ate on plain-text data across folders and yet be prevented authenticated RESTful interface. Therefore, trusted compo- from breaking folder non-interference. Integrity checking in nents are no different from the untrusted ones, except that Storage Declassifier not only prevents storage from explic- they are authorized to perform operations such as user au- itly copying Alice’s data into a get response for Bob, but thentication. Internally, each container is identified by the also prevents implicit leaks where storage returns Bob’s application it is running (e.g., Health), the user it is run- value X if Alice’s secret bit is 0 and Bob’s value Y if Al- ning on behalf of (e.g., Alice), and the folder it has ac- ice’s bit is 1. storage is confined to a container with no cess to (e.g., “Fracture’13”). As used throughout this sec- outputs other than to the Storage Declassifier, assuming that tion, the green container in Figure 2 would be identified as timing/termination channels from storage to app are ad-
Template endpoints are implemented by DATS. Application Container Container Container Container endpoints are implemented by untrusted apps. MySQL MongoDB Redis Dedup.
Many popular applications have models using (variants Figure 4: Implementation of DATS; colors denote untrusted of) put–get interfaces, where integrity checks are suffi- code, and italics show the mechanisms used. All DATS com- cient to ensure non-interference. The declassifier checks ponents run in containers. The trusted Login and Backend that a “get(key)” request returns the most recent value applications are not show for brevity. for “put(key, value)” (otherwise aborts the connection). The same approach can be transparently applied to other interfaces, like disk blocks or file systems [63]. MongoDB, Redis and a custom deduplication backend. We Finally, many existing large code-bases use trusted databases wrote 13 K lines of TCB code in Python, Node.js and C. The that have already gone through extensive audits (e.g., trusted TCB can be substantially reduced by running containers on developers assign roles to implement access policies). In this security-oriented OSs like seL4 [43] or HiStar [77]. Instead case the declassifier creates per-folder databases on a sin- of trusting the hypervisor, we could also use attestation and gle storage instance, and uses the existing access control trusted boot [42, 54] to bootstrap DATS on a remote cloud. mechanisms to limit each app instance to its corresponding MongoDB and Redis are not limited to put/get, but we folder’s data. The database should maintain data integrity, find this sufficient for our diverse applications (see 5). but that is not a requirement (e.g., IntegriDB [79]). Also, app programmers can always use a per-folder instance.§ The Proxy is a multi-process Flask [6] application run- 3.6 Application Instance Lifecycle and Available APIs ning behind Apache, with MySQL as a persistent database, Table 1 summarizes the API available to untrusted compo- Redis [15] as a short-term database and to implement dis- nents, whose lifecycle is managed by the Proxy. Even if not tributed locks, and Celery [2] to run cross-folder requests in shown in the figures for clarity, all containers have read-only parallel. API operations are authorized by inspecting the re- access to a folder that contains their code. Non-folder con- questor’s IP; this is the simplest mechanism that can monitor tainers also have read-write access to a folder that can be folder access grants (each container has a unique IP). used to store user-specific settings, and per-folder containers The Proxy authorizes access to container sub-domains get read-only access to it (ensuring folder non-interference). using a session cookie set by the trusted Login application, Per-folder instances cannot directly link back to a non-folder and also performs a simple form of caching of the per- or cross-folder view since that could be used to exfiltrate folder JSON results used to feed templates. Its API is information across folders. Instead, the Proxy intercepts re- not described due to space constraints, but follows concepts quests to /dats/quit and redirects the client to the cross- similar to existing web caching technologies. folder view that initiated a transition to that per-folder view. 4.1 Container Backends 4. Implementation of the DATS System Off-the-Shelf Container Techniques. LinuX Containers Figure 4 shows all the components described in 3 and (LXC) [10] provide lightweight OS virtualization; we did how they interact, with an emphasis on DATS’s§ TCB. It not try conventional VMs since LXC is more efficient [38, includes four Storage Declassifiers we wrote for MySQL, 57]. Containers are created as a “clone” of a base file-system with additional folders overlaid on top using AUFS [1], and The browser’s CSP (and the newer “Referrer-Policy”) isolated at the network level using iptables. ensures no data is leaked through the “Referrer” SELinux [48, 61] implements a flexible and fine-grained header (i.e., each view type is on a different origin). MAC for Linux. Each container gets a virtual network inter- 3. Leaks to third-party domains: face and a binary policy module with the necessary labels to access files and network ports. (a) The browser’s SOP forbids client-side code to access HW-Capabilities Based Thread Containers. When a other non-origin domains. Proxy thread “enters” a container (executes a per-folder 4. Leaks through URL guessing: request using the app code), we prevent it from sharing memory with other threads using the CODOMs capabil- (a) Randomizing container sub-domains ensures apps ity architecture [66]. The app code is loaded into a separate cannot exfiltrate information by generating a link or CODOMs protection domain that isolated threads have read- redirect to an arbitrary sub-domain/container. execute access to, each thread gets a read-only capability pointing to its input request, and two read-write capabilities 5. Programmability Evaluation that point to their private stack and heap pool, respectively. Developers can write or port applications to DATS with- To prevent sharing through the file system, we added a Linux out any security expertise, since authentication and access system call (used by the Proxy) that privatizes the thread’s control are offloaded to DATS. Instead, they need only take file descriptor table and SELinux label. When a thread re- functionality-based decisions: establishing a minimum unit turns from its app call, the Proxy restores the per-process of sharing ( 3.2), writing templates for cross-folder views file descriptor table and SELinux tag, and frees the thread’s ( 3.4), and§ deciding what storage components to use (if private memory pages (the private heap and stack). any;§ 3.5). We evaluate programmability in DATS by port- ing 4§ open-source applications and writing 4 applications 4.2 Enforcing Client-Side Non-Interference from scratch, all summarized in Table 2. They cover diverse (Extending Containers to Client-Side) use-cases, like messaging, voice/video chats, document edit- ing, software development, and electronic medical records. Template Processor DATS uses the and standardized browser We describe Mattermost and DATS Health in detail since security controls (configured by the Proxy on the headers of they stress user management and template creation tasks. the responses it serves to the client) to avoid: 5.1 Mattermost 1. Leaks through request URLs/contents: Mattermost (version 3.7) is a messaging application written using Go (server side), React [14] (client side), and MySQL (a) The trusted Template Processor knows about HTML for storage. It has the concepts of teams (user groups) and structure and the semantics of tags that trigger browser channels to organize conversations based on similar topics. requests (e.g., links and forms) and include untrusted We selected channels as the minimum unit of sharing, client-side code (which is forbidden in cross-folder since they are a natural choice. A user can thus choose to views). Each tag includes information from a single create multiple teams and channels on a single folder, or use DATS.results block, ensuring that request URLs only one channel per folder from the DATS trusted user in- and contents have information from a single folder terface (TUI). The developer only provides the functionality (i.e., a